When building a timestamp request with the certReq set to true, the whole certificate chain seems to be present and built correctly. But when certReq is set to false, the CN is "Demo Sub CA", the issuer's common name, the one which appears in the generated token.
Is this correct? Should not it display "Timestamp Certificate" instead?
But when certReq is set to false, the CN is "Demo Sub CA", the issuer's common name, the one which appears in the generated token.
What do you mean by that the "CN is Demo Sub CA". Which application and how are you doing to extract the CN from the token?
The reference of the signer certificate in the token is the TSA certificate serial number and the issuer DN. Maybe it is this DN that you saw?
Looking at the output as parsed by the timestamp client in SignServer (trunk):
$ bin/signclient timestamp -print -inrep /tmp/luis.1 now
Time-stamp response {
Status: 0
Status message: Operation Okay
Time-stamp token:
Info:
Accuracy: null
Gen Time: Mon Dec 0316:04:30 CET 2012
Gen Time Accuracy: null
Message imprint digest: 27f57cb359a8f86acf4af811c47a6380b4bb4209
Message imprint algorithm: 1.3.14.3.2.26
Nonce: (null)
Serial Number: 3efe1e1fb4c909a3
TSA: (null)
Policy: 1.3.6.1.4.1.19126.2.1.0.1
Signer ID:
Serial Number: 2
Issuer: C=ES,O=European Agency of Digital Trust (CIF B85626240),OU=Demo CA,CN=EADTrust Demo CA TSA1
Signer certificate:
Other certificates:
}
So if CN=EADTrust Demo CA TSA1 is the sub CA, which issued the TSA certificate I think everything is as it suppose to be.
Best regards,
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, that was a typo: I meant "CN=Demo CA TSA", which indeed is the sub CA which issued the TSA certificate. Was not very sure if a token without certReq should have the DN of the sub CA or the certificate itself, so indeed everything is as supposed to be. Thank you very much.
Congratulations for SignServer by the way: great tool!
Best regards,
Luis
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the idea is that the client should be able to identify the certificate which signed the token based on the certificate serial number and issuer DN and then verify the token using that certificate but from some other source.
Hello.
I'm using SignServer 3.2.3 to generate trusted timestamps.
I have set up my CA with the following structure:
- Root CA (selfsigned) CN=Demo CA
- Sub CA (signed by root) CN=Demo CA TSA
- TSA certificate (signed by sub CA) CN=Demo TSA
All certificates have been verified (the certificate chain has been validated, KeyUsage and ExtendedKeyUsage have the correct values…).
When entering "getstatus complete 1" I get the following information regarding the distinguished names:
When building a timestamp request with the certReq set to true, the whole certificate chain seems to be present and built correctly. But when certReq is set to false, the CN is "Demo Sub CA", the issuer's common name, the one which appears in the generated token.
Is this correct? Should not it display "Timestamp Certificate" instead?
Here is the offending token:
And a token with the whole certificate chain:
Please note I have trimmed the names in my post for readability, so they do not exactly match with the ones in the tokens.
Hope the information provided is enough and sufficiently clear; if anyone needs additional details I will happily provide them.
Regards,
Luis
Hello Luis,
What do you mean by that the "CN is Demo Sub CA". Which application and how are you doing to extract the CN from the token?
The reference of the signer certificate in the token is the TSA certificate serial number and the issuer DN. Maybe it is this DN that you saw?
Looking at the output as parsed by the timestamp client in SignServer (trunk):
So if CN=EADTrust Demo CA TSA1 is the sub CA, which issued the TSA certificate I think everything is as it suppose to be.
Best regards,
Markus
Hello Markus,
Sorry, that was a typo: I meant "CN=Demo CA TSA", which indeed is the sub CA which issued the TSA certificate. Was not very sure if a token without certReq should have the DN of the sub CA or the certificate itself, so indeed everything is as supposed to be. Thank you very much.
Congratulations for SignServer by the way: great tool!
Best regards,
Luis
Thank you Luis,
I think the idea is that the client should be able to identify the certificate which signed the token based on the certificate serial number and issuer DN and then verify the token using that certificate but from some other source.
http://www.primekey.se/Services/Support/
http://www.primekey.se/Services/Training/