(NOTES) CA, Server, Client Keys and Certs

Encryption: Public Key -> Encrypts, Public Key -> Decrypts Signing: Private Key -> Generates Signature, Public Key -> Verifies

CA: 1. Generates Private Key, 2. Public Key for Signing, 3. Signs its own Public key with Private key after combining it with metadata like CN,Organization.

Server: Generation: 1. Generates Private Key, 2. Public Key. 3. Sends a CSR request to CA, CA signs server’s public key with CA’s private key after including CA’s public key’s metadata, and generates the final certificate. Usecases: A Client uses server’s certificate to verify it’s talking to the right server. Because only the right server should have the private key, it should be private. And the CA should point out who the right server is. Client Verifying Server: 1. Client gets the server’s certificate. 2. From its list of trusted CA public keys, verifies the signature is valid and that the server is “certified” by the CA. 3. The signature is generated from the public key of the server, the expiration date, and the CA’s metadata like CN,Organization,etc. This verifies that someone did not tamper with the file or extend the expiration date 4. Certificates can be revoked earlier than expiration date if a CA wants. To know if a certificate is revoked, a client can optionally request for a CRL file from the CA, or use OSCP protocol to access the specific revocation info.

Client: Generation: Same as Server Usecases: For server to verify it’s talking to a correct, authorized client. And can prevent access otherwise. Useful for access control. Server Verifying Client: Same as how client verifies server, but other way around.

Fancy Terms and Stuffs: CSR (Certificate Signing Request): For locally self-signed certificate you do not need CSR, signing can be done through a tool like certtool or openssl only. But if you have a remote CA, you need to remotely request it to sign your public key, for which you send to generate a CSR file (starts with “PKCS #10 Certificate Request Information”, contains Version, Subject (metadata), Subject Public Key Algorithm (Algorithm type), Algorithm Security Level (number of bits), Modulus (the actual contents of public key) and a “BEGIN NEW CERTIFICATE REQUEST” fields) and sends it to a CA server. CRL (Certificate Revocation List): A certificate’s expiration date is included in the certificate file itself. But a CA might decide to “revoke” it early on. A CRL is a file that has lists of some certificate that have been revoked, cannot be used anymore, iffective immediately or to be revoked at some date in future. To know if a server certificate X signed by Y CA is revoked, a Client can retrieve the CRL file (which would be ridiculously huge) or send a query through OSCP protocol to know whether a certificate signed by a CA is still valid today or has it been revocated.

But, CRLs can also be used by server to revoke users (Like what ocserv does). Pretty neat!

And that’s IT :D