1
votes

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

1
I would assume that there is an issue in the TSA signer certificate or a connection securing certificate. Please share samples to analyse.mkl
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 IdRobertGG
In the subject I have {CN, O, C} just like other TSA certificates (e.g. 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
"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
A screen shot does not help. Please share an example PDF with a timestamp for which the behavior you describe can be observed.mkl

1 Answers

1
votes

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).