Skip to content
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

Open
MaxFichtelmann opened this issue Feb 8, 2019 · 1 comment · May be fixed by #651
Open

x509 binary extracted from PKCS12 differs slightly from actual X.509 #650

MaxFichtelmann opened this issue Feb 8, 2019 · 1 comment · May be fixed by #651

Comments

@MaxFichtelmann
Copy link
Contributor

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

 SEQUENCE
  OBJECT            :rsassaPss
  SEQUENCE
   cont [ 0 ]
    SEQUENCE
     OBJECT            :sha256
   cont [ 1 ]
    SEQUENCE
     OBJECT            :mgf1
     SEQUENCE
      OBJECT            :sha256

When encoding the certificate extracted from the PKCS#12, forge emits the following AlgorithmIdentifier in the unsigned parts of the certificate:

 SEQUENCE
  OBJECT            :rsassaPss
  SEQUENCE
   cont [ 0 ]
    SEQUENCE
     OBJECT            :sha256
     NULL
   cont [ 1 ]
    SEQUENCE
     OBJECT            :mgf1
     SEQUENCE
      OBJECT            :sha256
      NULL
   cont [ 2 ]
    INTEGER           :14

This is semantically equivalent, but not binary identical to the AlgId inside the TBSCertificate. There are actually two different issues here:

  1. the usual NULL parameter is added to the digest algorithm identifiers, although not originally present
  2. the saltLength 20 (0x14) is emitted, but should not be included since it is the default value (although it should be 32 (0x20) when used with SHA-256, but technically ...)

I will work on a patch that addresses these issues. Is there something I should look out for?

@jneersoe
Copy link

jneersoe commented Jul 1, 2021

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants