Open SaiGonTDC opened 3 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
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
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?
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.
Currently my signing timestamp does not match the real time. How do I adjust it in the docker-compose file?
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
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...