I generated a RFC 3161 TimeStampResp out of a RFC 3161 TimeStampReq using openSSL. Therefore I used a self signed CA cert and a TSA cert issued by the self-signed CA using this command:
openssl ts -reply -queryfile request.tsq -signer TSAcert.pem -out response.tsr
The response was created.
openssl ts -reply -text -in response.tsr
genereated the following output:
Status info:
Status: Granted.
Status description: unspecified
Failure info: unspecified
TST info:
Version: 1
Policy OID: tsa_policy1
Hash Algorithm: sha256
Message data:
0000 - 43 2c bb 03 28 48 42 06-c0 c8 95 ee d8 32 9d 29 C,..(HB......2.)
0010 - 09 7c 10 be 68 2a 77 f6-6e 96 61 7c bf 8f e2 cd .|..h*w.n.a|....
Serial number: 0x01
Time stamp: Aug 1 13:40:03 2018 GMT
Accuracy: 0x01 seconds, 0x01F4 millis, 0x64 micros
Ordering: yes
Nonce: unspecified
TSA: DirName:/C=stuff/ST=Some-State/L=stuff/O=stuff/CN=stuff
Extensions:
As I try to verify the TimeStampResp against the TimeStampReq using this command:
openssl ts -verify -queryfile request.tsq -in response.tsr -CAfile CAcert.pem -untrusted TSAcert.pem
I get a error message stating, that my CAcert is self signed (which is actually true)
Verification: FAILED
139727615005120:error:2F06D064:time stamp routines:ts_verify_cert:certificate verify error:../crypto/ts/ts_rsp_verify.c:182:Verify error:self signed certificate
Is there any way to skip the certificate validation or to tell openSSL that this CA can be trusted?
First, this isn't really a programming or development question, and probalby belongs instead on superuser, unix.SX, or maybe security.SX .
Second, it works for me (verifies okay) if I reconstruct the situation you describe with 'obvious' defaults for the information you omitted or redacted, on all recent releases (1.0.0-2,1.1.0). All I can suggest is, look carefully at exactly what's in your certs. One obvious possibility: did you make the TSA name (cert Subject) the same as the CA name? That makes chaining fail, resulting in the type of verify error you got.
Third, there is no option in openssl ts -verify to do other than the normal verification sequence. But a successful TimeStampResp is just a SEQUENCE containing a simple header (a sub-SEQUENCE containing INTEGER 0) and a CMS SignedData which is the Timestamp Token. You can extract the CMS SignedData part -- manually with openssl asn1parse -inform d to find its offset which is usually 9 and then adding -strparse 9 -out signedtst or just something simple like tail -c +10 <tsresp >signedtst (added) or more easily with an option I somehow missed before: openssl ts -reply -in response -token_out -out signedtst -- then use
openssl cms -verify -noverify -certfile signercert -inform der -in signedtst -binary -out tstinfo
(yes -verify -noverify!) to verify the signature on the signed data by the cert (i.e. by the TSA) but not verify the cert itself (against a chain ending in the truststore, and the required ExtKeyUsage, plus OpenSSL's -purpose timestampsign also constrains KeyUsage although I don't see this in the standard) and also extract the signed body which you can then manually parse with
openssl asn1parse -inform der -in tstinfo [-i]
although that's not as convenient as having it labelled and formatted for you.
ADDED: There are some added options in 1.1.0 that I apparently missed; see https://stackoverflow.com/a/52134401/2868801
来源：https://stackoverflow.com/questions/51637771/openssl-verify-rfc-3161-timestampresp-signed-with-self-signed-certificate