How do openvpn/easy-rsa generated keys map to RSA algorithm variables?

Question

I was reading up a little on openvpn and pki infra and am confused by some of the questions posed by my colleague. :) This answer did help me understand more: https://security.stackexchange.com/a/12369/66224

But I am still stuck with some questions. Searching hasn't helped much.

1.1. In the openvpn with pki process, we create the ca first, which gives us the ca.crt and ca.key; more importantly, we get a dh2048.pem and a crl.pem.

1.2. Then we go about creating files (.keys and .crts) for the entities (here, entity means openvpn client or server; basically, a 'client' for the ca)

PKI uses RSA which is as follows (copied from:http://docs-legacy.fortinet.com/fweb/admin_hlp/5-0-0/index.html#page/FortiWeb_Help/how_to_apply_PKI_client_auth.html)

2.1 n = pq; p,q = big primes

2.2 phi = (p-1)(q-1)

2.3 e < n, such that gcd(e,d) = 1

2.4 d = e^(-1) mod phi

2.5 (n,d) is the private key

2.6 (n,e) is the public key

I see that the ca.crt is a key, dh2048.pem is a key, client.crt is a text and client.key is again a key. How do these map to the algorithm variables above? Thanks.

EDIT1:

An addendum to the question.

The openvpn manual says that both the openvpn server and the openvpn client authenticate each other. I have also read that the CA can be completely offline for security purposes. So, how do they contact the CA if needed? Based on RSA (and since it involves computation) I am assuming that they never contact the CA. Then how does the solution work? Thanks.

EDIT2:

If RSA is what is followed in PKI, how is a trusted time service a requirement in PKI infra? Thanks.

Answer 1

Creating a Certificate Authority

When you create your Certificate Authority certificates you will get ca.crt and ca.key files. The .crt file is the self-signed public key, and the .key file is the private key file. It's not quite as simple as this. Both files are base64 encoded, and the data underneath is DER encoded. Since you are likely generating X.509 certificates.

Really all you need to understand is that you have a self-signed certificate whose public portion is stored in ca.crt and the private portion is stored in ca.key. Remember that you need to keep ca.key secret All of the big primes, GCD operations and what not is all taken care of by whatever you're using to generate the certificate.

The dh2048.pem is not a key, it is the Diffie Hellman parameters for the server. These have nothing to do with your RSA keys, and are only used for when Diffie Hellman is used to connect to your server rather than RSA. The difference between the two can be found in the Key Exchange section of How does SSL/TLS Work? These should have nothing to do with PKI.

The crl.pem is generated to be your Certificate Revocation List. Any certificates that you revoke that have been signed with your CA are added to this file. In your OpenSSL configuration (I'm assuming you're configuring OpenSSL, but the idea applies to any configuration) this CRL file will be pointed to. That way it will know where to check for revoked certificates.

---

Signing Certificates

Now that you have a Certificate Authority you can begin signing certificates of users for your system. Users do this by generating their own RSA keys client.crt and client.key. These keys should be generated whenever a new user is introduced to the system. Again, the .crt is the public portion of the key, and the .key is the private portion. The client.key must be kept secret by the new user..

To sign the certificate of a new user a Certificate Signing Request (CSR) is made. There is a command in OpenSSL to do this. The request contains the public key of the user to be added, and some other public information needed by the request. The client's certificate will be added to the appropriate authorized lists on the server, and a new signed certificate will be produced. This is what the user will have to import into their browser to visit PKI enabled pages.

There's a great tutorial about Public Key Infrastructure on OpenSSL's site for future reference.

---

Hopefully this clears some things up. Each variable you've mentioned in the RSA algorithm is generated when you create a certificate. Public certificates don't contain them all, but the private portions generally do. For implementation purposes you won't need to worry about them. Just remember that there is a public and private key pair.

To Answer your 1^st Edit

The exchange of CSRs and the resulting certificate is generally performed using some type of secure copy (scp). The server and client must be in communication with each other. The statement that "the client and server authenticate each other" is not really correct. The client wants to be a part of the infrastructure so it must prove its identity to the signing server. As the Certificate Authority, it is its responsibility to verify the identity of the client before processing the CSR. The CSR itself should have all the information needed to verify the identity of the client to be added.

To Answer your 2^nd Edit

RSA is only the public key algorithm used for key generation, encryption/decryption, and signing. Public Key Infrastructure is a collection of standards and services required to implement a secure infrastructure. A trusted timing service is most likely one of many requirements. Much like a Certificate Authority is a requirement.

Answer 2

I am posting this as an answer as it is too long to get in as a comment. :)

The following process described is with regards to openvpn & PKI.

Client has the following files: ca.crt, client.crt, client.key

Server has the following files: ca.crt, server.crt, server.key, dh2048.pem, crl.pem

The process as per my understanding:

1. Key exchange (reference): Server sends dh2048 to the client in the clear. Client selects a primitive root modulo relative to the dh2048 prime and they share a secret session key using Diffie-Hellman Key Exchange. They basically have secure communication channel now. However the server & the client are still 2 entities who decided to talk with each other. They have nothing in common (i.e. no trust). EDIT: Actually after reading https://wiki.mozilla.org/Security/Server_Side_TLS#Forward_Secrecy, I feel the dh2048 is not sent as plaintext. Also refer RFC5246.

2. CA makes them common. How do they verify that each of them come from the same CA? The primary role of the CA is to digitally sign and publish the public key bound to a given user. This is done using the CA's own private key, so that trust in the user key relies on one's trust in the validity of the CA's key (from wikipedia PKI article).

3. So they exchange their (signed/encrypted) public keys with each other. The other end has the CA public key and can decode the signed key to get the actual public key. This verifies that they had the same CA. Using the unsigned/actual public key now, they exchange their data (they start with a handshake and establish another session key, or increase the timeout for the earlier established session key; don't know this for sure).

4. Once they have come this far, they can encrypt messages using the (new/old) session key and the other end can decode it.

5. The extra step is that the sever in openvpn also checks for the clients entry in the crl.pem (which is just a list of signatures that have been revoked; and now that I think of it, I think it has the original unsigned/unencrypted key! Have to verify this though).

6. The ca.crt is plaintext and hence they cannot exchange public keys in plaintext and need a session key to do that, and hence the DHKE.