# Questions about the certificate authority procedures

I am beginner in cryptography and now I try to understand certificate process.

The general procedure to issue certificates in a Public Key Infraestructure is moreless the following.

1) the client generates a key pair, private and public

2) the client generates a CSR (Certificate Signing Request) including attributes like Common Name and the Public key. Signs it with the private key and sends it to the server

3) The server builds the X509 Certificate with the CSR data, sins it with the CA private key and returns the X509 to client

4) the client stores the private key and the certificate in a KeyStore

1. It's not clear to me when client encrypt CSR (Certificate Signing Request) by client's private key and send to CA server ---> How the Server can read this CSR?
2. The CA server build X.509 and sign with CA private key. If I have client B, how client B get client A public key?
3. I wrote the code in Android to generate RSA key pair. Next step, what should I do to get certificate from CA server?
4. About CA server, I find two open source: OpenCA and EJBCA. What should I choose?

2) the client generates a CSR (Certificate Signing Request) including attributes like Common Name and the Public key. Signs it with the private key and sends it to the server

Notice that the client signs the CSR; the client does not encrypt the CSR. This leaves the data in the CSR (mostly, the public key and its attribute) in clear form, directly readable. The signature of the CSR can be verified against the public key in the CSR (this acts as a verification of consistency, and prevents an entity asserting that it generated the private key from pretending not having issued the CSR).

The CSR is defined in RFC 2986:

   CertificationRequest ::= SEQUENCE {
certificationRequestInfo CertificationRequestInfo,
signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},
signature          BIT STRING
}


The signature field is the RSA signature of the CertificationRequestInfo according to the AlgorithmIdentifier (which must be compatible with the type of key for which the certificate is requested from the CA). In the context of RSA, the big picture is that the CertificationRequestInfo is hashed, some padding is added (per RSASSA-PKCS1-v1_5 or RSASSA-PSS of PKCS#1), then the RSA private key function $x\to x^d\bmod N$ is applied to form the signature (with some conversions between integer and bytestring). Notice that signing uses the private key, which is usually kept private to the party asking for the certificate; and signature verification by the CA will use the public key for which it is asked the certificate, which is embedded in clear in CertificationRequestInfo. There is no encryption involved (RSA encryption uses a different padding, the public key for encryption, and the private key for decryption).

2. The usual way for client B to obtains A's public key is to

• obtain A's certificate (as issued to A by the CA server), usually from A, or from a public registry (not necessarily trusted).
• check that certificate using the CA server's public key, assumed authentic/trusted,
• extract A's public key from the certificate

3. See point 2) in reference, cited above. The hard part is convincing the CA to issue the certificate, which typically requires proof of control of the domain(s) in the Common Name field.

4. We don't do recommendations.

• Thank you for your answer. I have one point. I not very clearly about "sign" and "encrypt". What exactly the client do? – nistelrooy41001662 Jul 18 '17 at 7:19
• Encrypting the CSR would scramble it, leaving it unreadable. Signing means to compute the value of the digital signature, using the process fgrieu described above. Signing a document does not scramble the contents of the document! To validate a digital signature, the reader performs their own hash of the document, then performs the RSA computation using the public key on the hash value. The reader then matches the computed value to the signature published with the document. Only the corresponding private key could have been used to compute it, thus the signature is validated. – John Deters Jul 19 '17 at 4:17