Clarification needed on CSR signing process

Question

There doesn't seem to be a lot of in-depth information on the certificate signing process other than:

• Key Management Interoperability Protocol Usage Guide Version 1.2 (PDF)

• RFC 2986 - PKCS #10: Certification Request Syntax Specification, Version 1.7

Here is an example CSR I created:

-----BEGIN CERTIFICATE REQUEST-----
MIIC3zCCAccCAQAwaTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRQwEgYDVQQH
EwtMb3MgQW5nZWxlczEQMA4GA1UEChMHRXhhbXBsZTELMAkGA1UECxMCQ0ExGDAW
BgNVBAMTD2Nzci5leGFtcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBALsbtWr46Mx8Loal+tKuAFzKHDmzBNr1DG1XlKuO32oVekJW8rkSXdIt
i90g2Bpl9yS8ndFt9djI+Jx0YZp2BnErAbriX7PXXLY13tj3OmO0f8JEAv/5HOaL
qYl79Mr03prhjyTZrlxSPsFuuXfy+arErNet7sqkOua7iexpC6Vx0CTL/YGjzEG3
PA3zAdqKMWnHruSzyAExf/NocLTJ8OdvvAIh2MP79ga8MRtXdM/nEIs6xgnd9B1c
I2mkS0gK7yFCKISZpeSusLJB9SplaOLiH0FBAzslek5WkMVs4AiEahieOMOFtyYR
8v3rKSNvSQW0y29M71AjQq9CA69VrVUCAwEAAaAxMC8GCSqGSIb3DQEJDjEiMCAw
CQYDVR0TBAIwADATBgNVHSUEDDAKBggrBgEFBQcDATANBgkqhkiG9w0BAQUFAAOC
AQEAGRIzq4nE7KhNZ5vt85gfw6BLM887G/W2A679cXzH7nSjL0Hmr7dii891ak8v
AzgwLKYn6sRBA+cN1bidExcb49v8G7TMOIBxhZjlEewgouBRBZMtNxSJFhD7TSrr
uj7r/tudnztqIjfYL9cXo+MuoGHsGJcXoBSQBIE8jheEUdaAA2LFVaLL+3lQgylL
14iCuY6DR1bF51lZP0zSqdba+mFvAVpspZfcrVClYqsf/xfkiHH7Rx1pz4sDCKTt
WV/7YHDxGXwIjIxkhEwuMX+zz3rO++jy+iBTXnFVwfPogcbLDmcFM/j4JPxuVz4a
nx5Y3pWKymuKNQ58BAguzF+tmA==
-----END CERTIFICATE REQUEST-----

I pasted the above in certlogik.com and had a look at the output.

If I understand it correctly, 4 components will make up CertificationRequestInfo:

1. Version
2. Subject
3. Public Key Info
4. Attributes

I am assuming that using SHA1 or SHA2, the CertificationRequestInfo is then hashed and that hash output is encrypted using the private key of the computer that is creating the CSR.

When it arrives at the CA, the CA takes the CertificationRequestInfo and runs a hash on it. It then also takes the encrypted value and tries to decrypt it using the public key in the CSR. If the hash output and the decrypted hash output match, then the CA will sign the CSR.

Please correct me if I am wrong with the above. At this point I'm confused regarding to what data the CA actually signs (what data the CA hashes and then encrypts that hash).

Answer 1

The CSR is checked for validity. If it is valid, then the old signature is stripped out and a new certificate is built.

The ingredients for the new certificate are as follows:

• Info from CSR (Plus some fields added/changed/removed. Whatever your CA feels is best.)
• Typically some basic constraints (Such as the statement: "What I'm signing here is (or is not) supposed to be a CA itself." )
• Info about who is signing.
• And then the signature itself.

All the pieces that are To Be Signed make up a set. This set is called "TBSCertificate".
And TBSCertificate + signature-parts make up what is then called "Certificate".

RFC 5280 breaks this down like so:

Certificate  ::=  SEQUENCE  {
    tbsCertificate       TBSCertificate,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue       BIT STRING  }

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
    }

There is an excellent blog post that goes into more depth about what is and what isn't actually inside a certificate: Morgan Simonsen, 2013-04-16, Understanding X.509 digital certificate thumbprints (Archived here)