0

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.

  • Why the downvotes? – krish7919 Jan 13 '15 at 10:39
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 1st 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 2nd 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.

  • Thanks, @raz. I will read more on this and comment again. You have given me some fodder to ruminate on. :) – krish7919 Jan 14 '15 at 4:07
0

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.

  • I'm not exactly sure what process you're describing. – RoraΖ Mar 13 '15 at 12:05
  • I am describing how the files generated during openvpn setup are actually used for ensuring security. I had asked " How do these map to the algorithm variables above?" – krish7919 Mar 15 '15 at 8:47
  • Is this the correct workflow? – krish7919 Apr 15 '16 at 10:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.