What data Certificate Authority encrypt for CSR?

Question

I have been searching for a detailed explanation but can’t seem to find a low level one.

1) When CA sign the data with its private key, the encrypted data is APPENED to the csr or the whole cert itself is the encrypted version? Does the encrypted data include contain public key or the whole CSR is encrypted?

2) if it is appended, why do we still need to keep original data in the cert? To check that data has not been altered when signature is unlocked by CA public key? Why can’t we just unlock CA signature and use the data inside there?

3)if it is replaced, how do we know which CA does this certificate belongs to?

4) does the client rely on IssueBy field to know which CA public key to use or they just try all the public

Answer 1

In the X.509/PKIX certificates used for SSL/TLS as tagged, but not necessarily for (many) other types of certificates:

1. A CA doesn't encrypt anything; it signs certificates. Signing is not encryption, although some people are confused by the fact that for one algorithm (RSA) one part of signing is similar mathematically to one part of encryption. The certificate is not the same as the CSR and a certificate is not a signed CSR, although the certificate includes some important data from the CSR: always the public key and often the subject name and sometimes some extensions.

2. A party who uses a cert (in SSL/TLS usually the client using the server's cert) validates it partly by verifying the cert's signature using the CA's public key (for which the CA usually has and provides another cert, the CA cert). I'm not sure I understand the rest of your question; we need to validate any cert to be sure it's valid and not faked, and an SSL/TLS client needs to validate the server's cert in order to be sure it's communicating with the correct server and not an imposter.

3. "if it is replaced" -- what is "it"? Do you mean a 'Man-in-the-middle' changing the handshake to include some other cert (or chain) instead of the server's cert (or chain)? If so, see #2.

4. Yes, the certificate contains a field Issuer which identifies the CA that issued (signed) the cert, and the Issuer field is used to locate the CA cert containing the CA public key used to verify the cert. However, there are other related values that can be and usually are in the cert as well:

   • AuthorityKeyID (AKI) extension identifies either the signing key (by copying its SubjectKeyID/SKI) or the signing cert (by its issuer and serial)
   • CRLDistributionPoint extension identifies where the CA, or an agent of the CA, issues Certificate Revocation Lists (CRLs)
   • AuthorityInfoAccess.OCSP (Online Cert Status Protocol) extension identifies where the CA, or an agent of the CA, provides revocation information online
   • AuthorityInfoAccess.CAIssuer extension identifies where the CA cert is available online (although in SSL/TLS the prover = server is required to send it so this normally shouldn't be needed)

Answer 2

1. The main function of a CA is not encrypting data, but acting as third-party endorser of the ownership of public keys transmitted in the CSR. The CA is endorsing (signing) this Public Key belongs to this domain.

2. Data isn't "unlocked" by the CA's key. When the client connects to https://crypto.stackexchange.com it is sent stackexchange's cert containing a public key endorsed by the CA which is used to setup the symmetrical session keys with the client. Upon receipt of stackexchange's cert the client validates the signature from the trusted CA certs that ship with all web browsers. Satisfied that a trusted third-party CA has vouched for the Public key it's been passed actually belongs to stackexchange.com, the client will then use it to encrypt key material used to create symmetrical session keys ensuring the data is not compromised during the return journey to stackexchange.com. So THAT is the purpose of stackexchange having their Public Key signed by Digicert Inc: to setup the symmetrical key encrypted session.. There is only a single public key used, its' stackecxchange's and once the symmetrically encrypted session is setup the public key is no longer used.

3. (and part of .2) You appear to be asking about interception or Man-In-The-Middle. Since the symmetrically encrypted session between the client and stackexchange.com is built using stackexchange's Public Key, M-I-T-M isn't possible- unless I guess stackexchange's secret key has somehow been fatally compromised.

4. How the webbrowser validates the cert: Browsers check a certification path starting with a trusted CA and working through intermediate CA's. So it's not about just checking a cert, it's about validating a chain of trust. And that is why self-signed certs raise red flags: they cannot be found in that chain of trust. That's not to say self-signed certs are all compromised, it just means that no trusted third-party has endorsed that the Public key in the cert actually belongs to the domain it purports to be from.