client SSL authentication .pem file and .crt files

Question

So I have minimal knowledge of security really but I'm a primary developer on an application which handles some sensitive data that we want to be secure. The application communicates with one other server (the other server is the front end, my server is basically the backend). Our security expert (who is not currently available) has explained that we need mutual SSL authentication for the connection between the servers. Our sysadmin has setup client side authentication and given me a .pem file and now if anyone tries to access the application they get an SSL error because they are not passing client SSL authentication. I need to give 1 other developer who is in another state the ability to access the application. Can I just send him the .pem file (say via email)? Do I need to make a .crt file and send that to him? Basically what information do I need to give the other developer so that he has all the necessary information to access the application. What is in a .pem file? Just the public key or more than that?

Answer 1

PEM means Privacy Enhanced Mail, but the acronym has been long outlived by the file format. The "PEM" format is a method to encode binary data into text, so that the data may survive the transport through a medium which is text-based and not very careful with the data (typically emails).

Basically, PEM begins with some header:

-----BEGIN FOOBAR-----

followed by Base64 encoding of the binary data, and a footer line which marks the end of the element:

-----END FOOBAR-----

Therefore, PEM format is quite generic, and you have to look at the header to know what you actually have in the file.

---

In your case, you must make a distinction between the certificate and the private key. The certificate is the public part; it is something that SSL client and server send to each other during the initial handshake. Certificates can travel by email; since they contain only public data and are moreover signed, they don't need any extra protection.

Private keys are quite another business. In the SSL handshake, the client sends to the server a copy of the certificate (so that the server may learn what is the client's public key), and then the client demonstrates its mastery of the corresponding private key (internally, a signature is computed over a challenge from the server). The private key is what makes the client "special": the attacker does not know it. If the attacker knew the private key, then he could impersonate the client, and that's exactly what you want to avoid.

Therefore, sending a private key "as is" by email should really not happen.

However, in your situation, you want the client ("the developer in another state") to obtain both the certificate and the private key. You thus need a way to convey both the certificate and the private key to that client. The usual method uses the PKCS#12 format, which allows for password-based encryption:

• Wrap both the certificate and its private key into a PKCS#12 file protected with a huge, fat, very random password.
• Send the resulting file (conventionally called ".p12" or ".pfx") to the recipient.
• Phone the recipient to give him the password, so that he may decrypt the package and thus obtain the certificate and private key.

---

If there is nobody available in your organization, who knows what a certificate or a private key is, then you have a problem. Namely, that you are using cryptography without understanding it. You had a "security expert" at some point: get him back. Security does not tolerate improvisation well.

Answer 2

If all you have is one .pem file to access the system then it sounds like the file contains both the certificate and the associated private key. You can verify this by opening up the file in a text editor and seeing that it contains both a "BEGIN CERTIFICATE" and a "BEGIN RSA PRIVATE KEY" section.

Ideally in this situation you would have your sysadmin generate a new certificate for the other developer. This would allow you both to access the system without sharing credentials.