Questions about the certificate authority procedures I am beginner in cryptography and now I try to understand certificate process.

I read this answer and have some questions about the enrollment 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





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? 
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?
I wrote the code in Android to generate RSA key pair. Next step, what should I do to get certificate from CA server? 
About CA server, I find two open source: OpenCA and EJBCA. What should I choose?


I am not clear about this. Thanks in advance.
&nbsp;1. The answer cited states


  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&nbsp;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).



&nbsp;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




&nbsp;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.



&nbsp;4. We don't do recommendations.