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?

2 Answers 2


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

        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.

  • When a digital signing certificate is requested by a person for signing documents, is the same process followed, or is the private-public key generated via a blind process by the CA and then both are mailed to the requesting person? I ask this because ordinary people aren't likely to know how to generate a public-private key pair (maybe a CA-approved software helps them?)
    – Daud
    Jul 7, 2020 at 13:04
  • 1
    The same process is followed, ideally with clear instructions to generate your own key pair. The reason for this is to ensure that only the owner of the private key ever has access to it. Some CAs will generate a keypair for you and let you download the private key but this is not recommended.
    – Marc
    Jul 7, 2020 at 13:08
  • Most user-friendly OSes include a fairly clicky way to generate a CSR: Windows' certificate manager or macOS' Keychain Access, mainstream Linux distributions run GNOME which has Seahorse. Jul 7, 2020 at 13:36

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .