My point was that the -text output would *show* you if the missing certs were included in the time stamp response somewhere, and where. If they are indeed inside the response, then the question would be why the "openssl ts -verify" command didn't find them automatically. If they are not inside the response, then the question would be why Symantec didn't include them like other tsa-s do. On 08/04/2016 22:36, Alex Samad wrote: > Hi > > Yep I have tried the output to text. but does that verify the signature. > > So what I think I have now is > > my data to be signed > I make a request > send the request to the tsa > the tsa signs it adds signature > I have response. > > Now I need to verify it > > openssl ts -verify -data SHA.sha -in SHA.sha.tsr > > but it seems to fail, I presume (newbie), because I don't have the > intermediary certs . > > I presume symantec have signed it with a cert thats rooted in one of > their main CA's and I presume for me to verify I need the > intermediaries or atleast the sign cert's ca. > > > I have looked on symantecs site to no available > > and I am working on guess work here > > > > > > On 8 April 2016 at 16:26, Jakob Bohm <jb-openssl at wisemo.com> wrote: >> Try something like >> >> $OPENSSL ts -reply -in ${FL}.tsr -text -noout >> >> (Not sure if it accepts the -noout option or not). >> >> >> On 08/04/2016 08:01, Alex Samad wrote: >>> Okay, how do I dump the intermediaries then ? >>> >>> >>> >>> On 8 April 2016 at 15:49, Jakob Bohm <jb-openssl at wisemo.com> wrote: >>>> On 08/04/2016 07:39, Alex Samad wrote: >>>>> Hi >>>>> >>>>> I am trying to use a rfc3161 timestamp service to record timestamps. >>>>> >>>>> >>>>> Basically I have a sha of some files and I would like to sign the file. >>>>> >>>>> basically I am using something like this >>>>> >>>>> # Generate Query and send >>>>> $OPENSSL ts -query -data "$FL" -sha256 | $CURL -s -H >>>>> "Content-Type:application/timestamp-query" --data-binary "@-" $TSA > >>>>> "${FL}.tsr" >>>>> >>>>> $OPENSSL ts -reply -in "${FL}.tsr" -text > "${FL}.ts.txt" >>>>> >>>>> >>>>> where FL = is file. >>>>> >>>>> What I want to be able to do is verify the .tsr file >>>>> >>>>> testing that with >>>>> >>>>> openssl ts -verify -data SHA.sha -in SHA.sha.tsr >>>>> >>>>> >>>>> where SHA.sha is the original FL >>>>> >>>>> but I get >>>>> >>>>> Verification: FAILED >>>>> 140221656393544:error:2107C080:PKCS7 >>>>> routines:PKCS7_get0_signers:signer certificate not >>>>> found:pk7_smime.c:476: >>>>> >>>>> from the text output >>>>> cat *.txt >>>>> Status info: >>>>> Status: Granted. >>>>> Status description: unspecified >>>>> Failure info: unspecified >>>>> >>>>> TST info: >>>>> Version: 1 >>>>> Policy OID: 2.16.840.1.113733.1.7.23.3 >>>>> Hash Algorithm: sha256 >>>>> Message data: >>>>> 0000 - 8c 6d 95 5b e0 cd 8b c9-df 8c ab 57 45 c4 69 e6 >>>>> .m.[.......WE.i. >>>>> 0010 - 7a b9 ce cb 14 8f 55 25-91 2e 57 37 3e 5c b8 d5 >>>>> z.....U%..W7>\.. >>>>> Serial number: 0xBEAF663E1CD2F0D029C1A641AD2F9137A5F097C9 >>>>> Time stamp: Apr 8 04:58:08 2016 GMT >>>>> Accuracy: 0x1E seconds, unspecified millis, unspecified micros >>>>> Ordering: no >>>>> Nonce: 0x8E67A9941BCB2570 >>>>> TSA: DirName:/C=US/O=Symantec Corporation/OU=Symantec Trust >>>>> Network/CN=Symantec SHA256 TimeStamping Signer - G1 >>>>> Extensions: >>>> I think this certificate is the end entity certificate >>>> for the Symantec time stamping server that responded to >>>> your request. >>>> >>>> If you dump the full contents of the TSR it should include >>>> that certificate somewhere, plus a chain leading to a >>>> public root which is hopefully in your list of trusted >>>> certificates or at least available via some other secure >>>> method. >>>> Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160412/4b3fd0dd/attachment.html>