1

I'm testing an RFC 3161 Timestamp Server, and I'm using Foxit Reader, Xolido Sign Desktop and Adobe Acrobat Pro DC to timestamp PDFs. I can make timestamps ok with Foxit Reader and Xolido, but Adobe Acrobat returns "Error durante la firma. El nombre TSA no coincide" which is something like "Signature error. TSA name doesn't match". I have searched and TSA server name in Adobe config is whichever you want, I have tested exactly with the subject of the certificate, just the common name, etc. The server returns certificate subject as TSA name in Timestamp Response, but it seems to be ok. I have no clue why Adobe says it and Foxit and Xolido are ok.

I added a FoxitReader Screen after validate the timestamp.

Foxit Reader dialog says "Signature valid. Signed by TimestampTest. Document was not modified since it was signed. The signature is a document timestamp from secure time etc."

PDF timestamp example with Foxit Reader

RobertGG
  • 75
  • 10
  • I would assume that there is an issue in the TSA signer certificate or a connection securing certificate. Please share samples to analyse. – mkl Sep 28 '17 at 21:26
  • Well I don't know what kind of samples you want. I'm just generating a lot of certificates with KeyStoreExplorer and PFX Certificate Generator. I have downloaded some TSA certificates and compare with mines, and update some fields but everything is the same. I have ExtendedKeyUsage="Timestamping" (Critical), KeyUsage="Digital Signature, Non repudiation" (Critical), Basic Constraints="Subject is not a CA, Path Length Constraint: None", Authority Key Id and Subject Key Id – RobertGG Sep 29 '17 at 19:55
  • In the subject I have {CN, O, C} just like other TSA certificates (e.g. http://timestamp.wosign.com). Maybe my server has a problem and is not the certificate, but I don't understand why foxit reader works ok. – RobertGG Sep 29 '17 at 19:59
  • *"I don't know what kind of samples you want."* - an example PDF with a timestamp for which the behavior you describe can be observed. – mkl Sep 29 '17 at 23:10
  • A screen shot does not help. Please share an example PDF with a timestamp for which the behavior you describe can be observed. – mkl Oct 01 '17 at 14:48
  • Ok, I added a link to a PDF timestamped with Foxit Reader and the server and authority certificates. I hope this will help you to help me ;-) I can't verify this PDF timestamp with Adobe Acrobat, but I can with Foxit Reader. Thanks for the help. – RobertGG Oct 02 '17 at 13:56
  • I'm looking into this. – mkl Oct 04 '17 at 10:17
  • I was comparing Foxit and Adobe packages with Wireshark, and can't see differences. I see just some TCP-protocol-ACKs, and 2 packages of protocol type PKIXTSP, one Query and one Reply. The reply of foxit is the same of adobe, both contains application/timestamp-reply with almost 2000 bytes, timestamptoken with signed info and server certificate, and TstInfo. I think is a problem whit "Adobe policies" of some kind, but can't see nothing. It just says "TSA name mismatch". I changed certificates, signature hash, ECC and RSA, and nothing. – RobertGG Oct 04 '17 at 15:25
  • Ok, I posted the solution, but thanks for your time. – RobertGG Oct 06 '17 at 15:52
  • Great! But could you create an answer with the solution instead of editing it into the question? – mkl Oct 06 '17 at 20:22
  • Ok sorry, I have no practice doing this, I think now is ok. – RobertGG Oct 09 '17 at 12:17
  • Great, upvoted. – mkl Oct 09 '17 at 13:13

1 Answers1

1

Well, I finally solved the problem. I found the same "tsa name mismatch" error using OpenSSL, and reading the OpenSSL source code I saw it was a local comparison between TSA name and certificate subject in the timestamp token. My server is using BouncyCastle, and when you create TSAName from X500 subject, because of "standard things", it reverses de Subject RDNs, (e.g. it swaps C=Foo, O=SomeOrg, etc), because TSA name is a GeneralName object and not an X500Name object.

I reverse the subject, then create the token TSA name and now both Openssl and Adobe validates ok.

In the server I have now:

tsTokenGen.setTSA(new GeneralName(reverseX500Name(new X500Name(tsuName))));

public static X500Name reverseX500Name(final X500Name name) {
    RDN[] orig = name.getRDNs();
    int n = orig.length;
    RDN[] _new = new RDN[n];
    for (int i = 0; i < n; i++) {
        _new[i] = orig[n - 1 - i];
    }
    return new X500Name(_new);
}

OpenSSL equivalent error is INT_TS_RESP_VERIFY_TOKEN, and it can throw de error in ts_rsp_verify.c line 459 (line relative to OpenSSL version).

RobertGG
  • 75
  • 10