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:
- the subject's public key is one of the fields in the CSR. Nothing is encrypted, just signed.
- 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.