dnl50 / tsa

Java implementation of a RFC3161 Time Stamp Authority
MIT License
20 stars 3 forks source link

Using openssl to send request to TSA Server failed #6

Open SaiGonTDC opened 3 days ago

SaiGonTDC commented 3 days ago

I use command: openssl dgst -sha256 -binary document.txt > document.hash openssl ts -query -data document.hash -sha256 -out request.tsq curl -X POST --data-binary @request.tsq http://localhost:8080 -o response.tsr But I read the response.tsr file, I get the error message as follows "{"status":500,"message":"The content-type header value did not match the value in @Consumes"}" Help me please...

dnl50 commented 2 days ago

Hi there,

you also have to set the Content-Type header to application/timestamp-query and use the /sign endpoint so the request can be matched correctly:

curl -X POST --data-binary @request.tsq --header "Content-Type: application/timestamp-query" http://localhost:8080/sign -o response.tsr

I will nevertheless update the endpoint so the Content-Type header does not strictly have to be set to application/timestamp-query. I also found a bug thanks to your question 😄

PS: The openssl ts -query -data document.hash -sha256 -out request.tsq command seems to hash the document twice. The OpenSSL manpage has some examples where they pass the plain path to the -data parameter: https://docs.openssl.org/master/man1/openssl-ts/#timestamp-request

SaiGonTDC commented 2 days ago

Thanks for your reply on the above issue. Now I have encountered another problem, which is in the deployment of tsa-server. When I change the keystore.p12, the container cannot be started, only when using the keystore.p12 available in your git repo located at "https://github.com/dnl50/tsa/tree/develop/app/src/main/resources/keystore" can it run. But when I send a timestamp request to tsa-server, I receive the following information:

Using configuration from /usr/lib/ssl/openssl.cnf Status info: Status: Granted. Status description: Operation Okay Failure info: unspecified

TST info: Version: 1 Policy OID: ISO Member Body Hash Algorithm: sha256 Message data: 0000 - e4 9a 89 7a ac 4c 98 19-21 27 0a 3f 79 e4 68 85 ...z.L..!'.?y.h. 0010 - c9 95 2f c5 ba 1a b4 c0-cd ef 38 0b e7 73 74 81 ../.......8..st. Serial number: 0x16EC11CC87D99A4B Time stamp: Nov 20 07:00:11 2024 GMT Accuracy: unspecified Ordering: no Nonce: 0x0317CB1901830A06 TSA: unspecified Extensions:

Am I deploying wrong or misunderstanding the problem. I hope you can respond to me soon

dnl50 commented 1 day ago

The openssl ts -reply -in response.tsr -text command only seems to print the TSTInfo structure as defined in RFC3161 (Page 7). The certificate itself is only contained in the TimestampToken, which is a CMS ContentInfo structure.

You can extract the certificate chain by extracting the Timestamp Token first and then extracting the certificate chain:

openssl ts -reply -in response.tsr -out response_token.der -token_out
openssl pkcs7 -inform DER -in response_token.der -print_certs -outform PEM -out certificatechain.pem

What does the application log say when you use your own .p12 file?

SaiGonTDC commented 1 day ago

I saw the certificate after running the 2 commands you gave.

When I changed my certificate, it seems that my .p12 file did not satisfy the tsa-server's requirements, so it reported an error.

. 2024-11-21 16:03:13,789 ERROR [io.qua.run.Application] (main) Failed to start application: java.lang.RuntimeException: Failed to start quarkus at io.quarkus.runner.ApplicationImpl.doStart(Unknown Source) at io.quarkus.runtime.Application.start(Application.java:101) at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:119) at io.quarkus.runtime.Quarkus.run(Quarkus.java:71) at io.quarkus.runtime.Quarkus.run(Quarkus.java:44) at io.quarkus.runtime.Quarkus.run(Quarkus.java:124) at io.quarkus.runner.GeneratedMain.main(Unknown Source) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at io.quarkus.bootstrap.runner.QuarkusEntryPoint.doRun(QuarkusEntryPoint.java:62) at io.quarkus.bootstrap.runner.QuarkusEntryPoint.main(QuarkusEntryPoint.java:33) Caused by: dev.mieser.tsa.signing.api.exception.TsaInitializationException: Could not initialize TSA. at dev.mieser.tsa.signing.impl.BounceCastleTimeStampAuthority.initialize(BouncyCastleTimeStampAuthority.java:115) at dev.mieser.tsa.signing.api.TsaConfiguration_ProducerMethod_timeStampAuthority_Gdi3NUpRGvLvaKEfS-6G4Rqu1p0_ClientProxy.initialize(Unknown Source) at dev.mieser.tsa.signing.config.TsaInitializer.onStartup(TsaInitializer.java:21) at dev.mieser.tsa.signing.config.TsaInitializer_Observer_onStartup_uvjaZHP8x_ZE1Ywmb8mz-qOcLd0.notify(Unknown Source) at io.quarkus.arc.impl.EventImpl$Notifier.notifyObservers(EventImpl.java:351) at io.quarkus.arc.impl.EventImpl$Notifier.notify(EventImpl.java:333) at io.quarkus.arc.impl.EventImpl.fire(EventImpl.java:80) at io.quarkus.arc.runtime.ArcRecorder.fireLifecycleEvent(ArcRecorder.java:156) at io.quarkus.arc.runtime.ArcRecorder.handleLifecycleEvents(ArcRecorder.java:107) at io.quarkus.deployment.steps.LifecycleEventsBuildStep$startupEvent1144526294.deploy_0(Unknown Source) at io.quarkus.deployment.steps.LifecycleEventsBuildStep$startupEvent1144526294.deploy(Unknown Source) ... 11 more Caused by: org.bouncycastle.tsp.TSPValidationException: Certificate must have an ExtendedKeyUsage extension marked as critical. at org.bouncycastle.tsp.TSPUtil.validateCertificate(Unknown Source) at org.bouncycastle.tsp.TimeStampTokenGenerator.(Unknown Source) at org.bouncycastle.tsp.TimeStampTokenGenerator.(Unknown Source) at dev.mieser.tsa.signing.impl.BounceCastleTimeStampAuthority.initialize(BouncyCastleTimeStampAuthority.java:105)

SaiGonTDC commented 1 day ago

Currently my signing timestamp does not match the real time. How do I adjust it in the docker-compose file?

dnl50 commented 1 day ago

Your certificat is missing the extendedKeyUsage Extension (see README).

To set the correct timezone, you have to set the TZ environment variable to your timezone:

services:
  tsa:
    image: "dnl50/tsa-server:3.3.0"
    environment:
      - TZ=Asia/Bangkok
    volumes:
      - /path/to/keystore.p12:/work/keystore.p12:ro

OpenSSL will still show the timestamp in UTC since it is stored using UTC, but the timestamp should then match your current time when adjusting for your timezone's offset to UTC