Does the CA create the public key or is it created by the requesting server and sent to the CA?

Question

This link says that the requesting server creates the public-private key pair and sends the public key to the CA inside the CSR. However, DigiCert says:

The CSR is submitted to a Certificate Authority (CA) which uses it to create a public key to match the private key without compromising the key itself.

I'm confused. Why would the CA create the public key when it receives it in the CSR?

Answer 1

The former is correct, as verified by RFC 2986: PKCS #10: Certification Request Syntax Specification:

The process by which a certification request is constructed involves
   the following steps:

        1. A CertificationRequestInfo value containing a subject
           distinguished name, a subject public key, and optionally a
           set of attributes is constructed by an entity requesting
           certification.

        2. The CertificationRequestInfo value is signed with the subject
           entity's private key.  (See Section 4.2.)

        3. The CertificationRequestInfo value, a signature algorithm
           identifier, and the entity's signature are collected together
           into a CertificationRequest value, defined below.

Paraphrasing: the public key of the subject (the requester of a certificate) is included verbatim in the CSR. It is not "computed" by the CA, but it is used to verify the signature of the CSR (to ensure that it was indeed requested by the holder of the key pair and not tampered with).

As for the DigiCert article: it goes on to state:

the SSL certificate itself is sometimes referred to as "the public key."

This would explain their use of "public key" instead of "certificate". As you noticed, this only brings confusion to an article supposed to explain the use of key pairs.

Answer 2

This sentence is technically correct, but confusing. The CSR contains the public key. The CA does “create” a public key as an intermediate step in generating the certificate, but all it does is to copy it from the CSR, and then embed it in the certificate.

It's true that the knowledge of the public key doesn't compromise the private key, but the CA never had access to the private key in the first place. The role of the CA and the fact that the public key can be used to “match the private key without compromising the key itself” are not directly related.

What happens is:

• The requesting server generates a private key and doesn't reveal it to anybody.
• The server calculates the public key for this private key. It can let everybody know the public key, because it's impossible to recover the private key from the public key.
• The public key is not very useful on its own, because it's just a number (or a bunch of numbers). It's only useful if it's associated with an identity such as a domain name. So the server wants the certificate authority to generate a certificate, which essentially says “www.example.com has the public key 1234, signed, the CA”.
• The server creates a certificate signing request (CSR), which essentially says “hey CA, my name is www.example.com and my public key is 1234, signed, 1234”. The signature mathematically guarantees that only the holder of the private key could create this CSR.
• The CA verifies through some other means that www.example.com has the public key 1234. If it's satisfied, it generates the certificate. Only the CA can generate a certificate because it's signed by the CA's private key.
• When the server wants to communicate with someone and prove that it's www.example.com, it sends the certificate, and signs its message with the private key. The other party verifies that the certificate is valid, which it can do because it knows the CA's public key. The other party also verifies that the signature of the message is correct given the public key contained in the certificate. Since the other party trusts the CA, it is satisfied that the message was signed by www.example.com.