-
Notifications
You must be signed in to change notification settings - Fork 767
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x509 binary extracted from PKCS12 differs slightly from actual X.509 #650
Comments
I have run into the same issue, which leads to problems when using a certificate that doesn't originally come with the NULL parameter on the digest algorithm identifier. When re-extracting such a certificate using Forge, the "signature" field in "tbsCertificate" will differ from the certificate's "signatureAlgorithm" field ("signature" won't have the NULL whereas "signatureAlgorithm" will). This violates RFC 5280 (sec. 4.1.1.2), which states that these two fields must be identical, and leads to interoperability issues. For example, OpenSSL won't verify the exported certificate anymore. Max's fix would help avoid these issues, so I'd be really happy if you merged it! |
I have recently stumbled across a certificate, that when reencoded by node-forge results in a certificate that differs slightly from the actual certificate.
MCV sample (forge 0.8.0): https://jsfiddle.net/9m5v4ct7/3/
The problem appears to be an AlgorithmIdentifier that is PSS with exotic but technically valid Parameters (unfortunately used in some productive certificates from a large CA):
When encoding the certificate extracted from the PKCS#12, forge emits the following AlgorithmIdentifier in the unsigned parts of the certificate:
This is semantically equivalent, but not binary identical to the AlgId inside the TBSCertificate. There are actually two different issues here:
I will work on a patch that addresses these issues. Is there something I should look out for?
The text was updated successfully, but these errors were encountered: