File extensions for cryptographic certificates aren't really as standardized as you'd expect. Windows by default treats double-clicking a .crt
file as a request to import the certificate into the Windows Root Certificate store, but treats a .cer
file as a request just to view the certificate. So, they're different in the sense that Windows has some inherent different meaning for what happens when you double click each type of file.
But the way that Windows handles them when you double-click them is about the only difference between the two. Both extensions just represent that it contains a public certificate. You can rename a certificate file to use one extension in place of the other in any system or configuration file that I've seen. And on non-Windows platforms (and even on Windows), people aren't particularly careful about which extension they use, and treat them both interchangeably, as there's no difference between them as long as the contents of the file are correct.
Making things more confusing is that there are two standard ways of storing certificate data in a file: One is a "binary" X.509 encoding, and the other is a "text" base64 encoding that usually starts with "-----BEGIN CERTIFICATE-----
". These encode the same data but in different ways. Most systems accept both formats, but, if you need to, you can convert one to the other via openssl or other tools. The encoding within a certificate file is really independent of which extension somebody gave the file.
Your keys may already be in PEM format, but just named with .crt or .key.
If the file's content begins with -----BEGIN
and you can read it in a text editor:
The file uses base64, which is readable in ASCII, not binary format. The certificate is already in PEM format. Just change the extension to .pem.
If the file is in binary:
For the server.crt, you would use
openssl x509 -inform DER -outform PEM -in server.crt -out server.crt.pem
For server.key, use openssl rsa
in place of openssl x509
.
The server.key is likely your private key, and the .crt file is the returned, signed, x509 certificate.
If this is for a Web server and you cannot specify loading a separate private and public key:
You may need to concatenate the two files. For this use:
cat server.crt server.key > server.includesprivatekey.pem
I would recommend naming files with "includesprivatekey" to help you manage the permissions you keep with this file.
Best Answer
Is the private key in the certificate file? In other words, in there a section that starts with
in the file?
If not, then the private key is stored in a separate file.
In any case, to renew a certificate, you don't need a certificate, but a certificate signing request (CSR), which you will send to the CA, and you will receive the certificate in return (alternatively, in some cases the CA may generate a new certificate using the previous stored CSR).
You can generate a new key with:
then generate the CSR with:
You keep the key, send the CSR to the CA. On return, you get the certificate, which together with the intermediate certificates and the private key, should be provided to the software used. In some cases they need to be in separate files, in others you can just lump them up together in a single file.