How much of a certificate is actually covered by the CA's signature?

Question

One of my devs recently had an issue with the compatability of a certificate, and we rooted around for a bit until we came across a a similar problem on SO.

Once I understood the developer's initial problem (the original certificate was generated with a CNG provider, rather than the Legacy one), I was expecting to have to re-create the CSR with the compatable parameter, and send it to the CA for re-signing.

However, the Linked Questions list led me to an unaccepted answer on another question, which suggested openssl could be used to split the existing PFX to a PEM pair, change the CSP parameter of the PEM private file to one that was compatable with the application, then recreate the PFX.

PFX-PEM-PFX conversion aside, I was skeptical that changing the private key file would work, because I thought that would cause the signature to change, and so would no longer validate. However, to my surprise, it appears to have worked and the dev was able to continue without further issues.

This got me wondering, how much of the certificate is actually covered by the signature process? What's to stop someone using the same tool (or similar) to change the expiry date, add another subject alternate name, or remove the CRL or OSCP information (for example)?

Answer 1

RFC 5280 section 4.1.1.3 talks about the scope of the signature

4.1.1.3. signatureValue

   The signatureValue field contains a digital signature computed upon
   the ASN.1 DER encoded tbsCertificate.  The ASN.1 DER encoded
   tbsCertificate is used as the input to the signature function.  This
   signature value is encoded as a BIT STRING and included in the
   signature field.  The details of this process are specified for each
   of the algorithms listed in [RFC3279], [RFC4055], and [RFC4491].

   By generating this signature, a CA certifies the validity of the
   information in the tbsCertificate field.  In particular, the CA
   certifies the binding between the public key material and the subject
   of the certificate.

The tbsCertificate field is defined as

 TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT Version DEFAULT v1,
        serialNumber         CertificateSerialNumber,
        signature            AlgorithmIdentifier,
        issuer               Name,
        validity             Validity,
        subject              Name,
        subjectPublicKeyInfo SubjectPublicKeyInfo,
        issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        extensions      [3]  EXPLICIT Extensions OPTIONAL
                             -- If present, version MUST be v3
        }

So no, you can't really update much from the certificate itself.

Note that

I was skeptical that changing the private key file would work, because I thought that would cause the signature to change

The private key is not part of the certificate. However, the public key is part of the certificate, and the public and private keys are dual -- one undoes what the other does. So if you change the private key, it will necessitate a change to the public key, and the cert will not be useful.

Answer 2

Actually you do not modify the certificate itself.

As explained here, the pfx file is container containing the certificate plus several other objects, including the certificate.

What you do in the given procedure is get the certificate out of this container, then put it in another container associated to different objects.

The certificate itself remains the same.