I've read a lot of articles on the PKI and digital certificate topics because it's very rare to find one article covers all the aspects; also the topic is confusing at the beginning, (this beautiful question is my last reading: How do certificates work in terms of encryption, hashing, and signing?).

I drew this graph from my understanding point: https://i.stack.imgur.com/sI7Od.png

I have 2 questions:

  1. I don't understand actually how the public key along with the ciphertext are "packaged" together (it's the best way I could think of to move on to the next step!), at the end the *.csr file is just a plain base64 text, are they encrypted together, so the order of the steps in the drawing is inaccurate?

  2. In order to verify the sender identity (from the web browser for example), it should have a copy of the CSR, but according to my understanding, the certificate only has the hash of it?


  1. This video might help to understand the ANS.1 encoding: https://www.youtube.com/watch?v=EccHushRhWs

  2. I corrected the diagram, following Marc's answer here, and here and the specs in IETF/Basic Certificate Fields:

enter image description here

  • The wiki on the subject has a breakdown for you: en.wikipedia.org/wiki/Certificate_signing_request
    – schroeder
    Aug 21, 2020 at 14:34
  • Your second question seems to suggest that the csr is sent to the client. It doesn't. Is that what you meant to say?
    – schroeder
    Aug 21, 2020 at 14:35
  • @schroeder I think the certificate has (among other data) the hashed CSR (?)
    – mshwf
    Aug 21, 2020 at 14:41
  • It does not, there's no reason to.
    – Marc
    Aug 21, 2020 at 14:44
  • So the CSR fields are copied (by somehow) into the certificate because when I open a certificate it includes all the data supplied to the CRT?
    – mshwf
    Aug 21, 2020 at 14:49

1 Answer 1


You have a few misconceptions in your diagram.

The most important is that both your encrypt boxes are wrong, they should say sign. Following from that, the CSR sent to the CA includes the various fields (including Subject) and the subject's public key, there is no ciphertext involved just plain data and a signature.

RFC2986: PKCS#10: Certification Request Syntax details the steps to build a CSR:

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.

The subject's (in your case: applicant) public key is included verbatim in the CSR, as is the subject information. This is signed using the subject's public key and everything sent over to the CA.

Not in diagram form, but here are the steps to build the CSR and which data is included: The correct steps to build the CSR (not in diagram form) are:

  • Build a CertificationRequestInfo using:
    • Subject Distinguished Name
    • Subject Public Key
    • Other attributes
  • Obtain Signature by signing the CertificationRequestInfo using Subject Public Key and a particular algorithm Signature Algorithm.
  • Construct a CSR object by including:
    • CertificationRequestInfo
    • Signature
    • Signature Algorithm
  • Send this CSR blob to the CA.

Note that the CSR still contains plaintext CertificationRequestInfo and Subject Public Key.

Upon receiving CSR, the CA will more or less do the following:

  • parse the CSR
  • verify that the signature matches the fields in the CSR by using the subject's public key
  • verify that the various fields match its requirements (eg: you can't ask for CN=google.com without proving that you own the domain)
  • craft a certificate using some fields from the CSR, some from itself
  • sign the certificate using its (the issuer) private key

The final certificate still contains the subject fields and the subject's public key.

To more specifically answer your two questions:

  1. the subject's public key is one of the fields in the CSR. Nothing is encrypted, just signed.
  2. The subject fields are copied into the final certificate, they are there for any client to see.

You can see list of certificate fields in RFC5280. There is no hash of the CSR because there's no need for it, all relevant information was copied into its own fields of the certificate.

  • The second box (dashed box) is signing operation already, but detailed: hash then encrypt.. isn't that what you mean?
    – mshwf
    Aug 21, 2020 at 15:13
  • Except it's not usually called encryption, and the result is not usually called ciphertext. The important part is that 1) the CSR includes the "subject fields" in plaintext (well, DER encoded, but definitely not encrypted) and 2) the subject info as well as the public key are part of the data that is signed.
    – Marc
    Aug 21, 2020 at 15:15
  • 1
    I've updated my answer to show exactly what data is in the CSR. Note that there is no ciphertext anywhere in a CSR or Certificate.
    – Marc
    Aug 21, 2020 at 15:28
  • The 3-steps process of creating a CSR says there are 3 distinct parts in the CSR: a readable value of the subject, signing value of the subject and the signature algorithm, but I only see a base64 text, this is really what confuses me
    – mshwf
    Aug 21, 2020 at 15:28
  • 1
    Typo, I think, in "This is signed using the subject's public key and everything sent over to the CA", private key, not public, to match what IETF recommends (2nd point)
    – mshwf
    Aug 22, 2020 at 10:54

You must log in to answer this question.

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