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

Are you saying that a change in the *certificate* didn't require you to get it resigned? Or was the change only in the private key? — Neil Smithline, May 07 '15 at 18:24
@NeilSmithline - My nomenclature may be letting me down here. The command was `openssl pkcs12 -export -aes256 -CSP "Microsoft Enhanced RSA and AES Cryptographic Provider" -inkey priv.pem -in pub.crt -out priv.pfx`, where the `-CSP` parameter was pertinent to what I needed to do. I am not technically sure if that means I changed the private key, the certificate or neither. — jimbobmcgee, May 08 '15 at 16:04
Ahh. @WhiteWinterWolf's [answer](http://security.stackexchange.com/a/88743/10885) has it. You only changed the output of the command, nothing to do with the certificate itself. — Neil Smithline, May 08 '15 at 16:14

score 2 · Answer 1 · answered May 07 '15 at 19:33

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.

answered May 07 '15 at 19:33

WhiteWinterWolf

19,082
4
58
104

Does that mean that the Crypto Service Provider is part of the *container*, rather than the certificate? If so, what other common tuples are specific to the container, rather than the certificate? – jimbobmcgee May 08 '15 at 16:03
These properties are Microsoft specific, they do not exist out of Microsoft world. I did a quick search, and found (sadly in french) a [few more](http://blog.gentilkiwi.com/tag/microsoft-csp-name) information that such file may also store information regarding what Microsoft calls "Local Machine Keyset" and "Friendly Name" (to be not confused with certificate's standard "Common Name"), but since I am no Microsoft expert I can hardly provide further information on the topic... – WhiteWinterWolf May 08 '15 at 16:27

score 2 · Accepted Answer · answered May 07 '15 at 20:18

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.

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

2 Answers2