How is public key included in the CSR?

Question

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?

Edits:

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:

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
           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.

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.