Using openssl to send request to TSA Server failed

[SaiGonTDC]

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]

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]

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]

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]

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]

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

[dnl50]

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

[SaiGonTDC]

Hi, it's me again
I tried changing my own keystore.p12 and tsa-server ran. But when I timestamped with tsa-server and executed 2 commands:

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

The certificatechain.pem file returned empty. Do you know what the error is?

[dnl50]

Does your query include the flag to include the certificate details in the response? This has to be requested explicitly by using the -cert flag as an option of the openssl ts -query command:

openssl ts -query -data document.txt -sha512 -cert -out request.tsq

[SaiGonTDC]

Thanks.
After adding the -cert flag, the tsa response has the certificate. But I still don't understand why when running the command
openssl ts -reply -in response.tsr -text
the response.tsr file still gives the result as TSA:unspecified

Accuracy: unspecified
Ordering: no
Nonce: 0x26B5DA898D4C2BEC
TSA: unspecified
Extensions:

[SaiGonTDC]

When I use the command:
openssl ts -verify -in response.tsr -data "document.txt" -CAfile certificate.pem

With: certificate.pem is the rootCA that signed the keystore.p12

I get the following error:

Using configuration from /usr/lib/ssl/openssl.cnf
Verification: FAILED
4077E126BE7F0000:error:17800064:time stamp routines:ts_verify_cert:certificate verify error:../crypto/ts/ts_rsp_verify.c:190:Verify error:unsupported certificate purpose

[dnl50]

Sorry for replying so late 😳

OpenSSL prints TSA: unspecified since Bouncy Castle (the underlying cryptography library) currently does not set the tsa field in the response. The RFC defines the field purpose as follows:

The purpose of the tsa field is to give a hint in identifying the
name of the TSA. If present, it MUST correspond to one of the
subject names included in the certificate that is to be used to
verify the token. However, the actual identification of the entity
that signed the response will always occur through the use of the
certificate identifier (ESSCertID Attribute) inside a
SigningCertificate attribute which is part of the signerInfo (See
Section 5 of [ESS]).

I will look into if Bouncy Castle supports setting the field.

The verification failure is most likely caused because the TSA certificate is self signed. OpenSSL verifies that the certificate passed to the -CAfile parameter has the keyCertSign extension (see https://docs.openssl.org/master/man1/openssl-verification-options/#key-usage), which is probably not set when you did not set it explicitly when issuing your certificate.

[SaiGonTDC]

hi you,
I have edited the CA cert to add the keyCertSign extension

But when authenticating the cert from the response.tsr file of tsa, it still cannot be authenticated:

openssl ts -verify -in response.tsr -data "document.txt" -CAfile /root/CA/myca.crt

Using configuration from /usr/lib/ssl/openssl.cnf
Verification: FAILED
40E794020C7F0000:error:17800064:time stamp routines:ts_verify_cert:certificate verify error:../crypto/ts/ts_rsp_verify.c:190:Verify error:unsupported certificate purpose

[SaiGonTDC]

I created the keystore.p12 file with the self-generated cert-key pair and used the following command to sign the cert for tsa-server

openssl x509 -req -in tsa-csr.pem -CA myca-02.crt -CAkey myca.key -CAcreateserial -out tsa.crt -days 365 -sha256 -extfile tsa.cnf -extensions v3_ca

after having the "tsa.crt" file, I executed the following command to convert the .p12 file

openssl pkcs12 -export -inkey tsa-private-key.pem -in tsa.crt -certfile myca-02.crt -out keystore.p12

then, mounted the .p12 file into the container and signed the document.
After that, I stopped using the CAfile myca-02.crt to authenticate and got the above error

[dnl50]

Hey there,

sorry for replying so late. I documented the commands necessary to issue a valid certificate in the README (see commit 298e6da).

With these certificates, I was able to verify the response using OpenSSL:

openssl ts -verify -in response.tsr -data document.txt -CAfile .\cert\cacert.pem
Using configuration from C:/Program Files/Git/mingw64/etc/ssl/openssl.cnf
Verification: OK