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 that sense, at least, 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 file or use one 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. But the encoding within a certificate file is really independent of which extension somebody gave the file. If you have specific questions about difficulty using a particular type of file with a particular program, it'd be best to post a separate question describing what kind of file you have and what your application is expecting.
More that file extensions of keys aren't really as standardized as they are for other types of files. Certificates can be text-base-64-encoded or binary-X.509-encoded, and most systems will read both formats. Windows will treat double-clicking a.crt as a request to add a root certificate, but double-clicking a.cer as a request to view the certificate, but it's treated the same whether text or binary.
That's why I suggested it'd be more helpful to post questions on specific issues using a specific file, since the extension doesn't change the contents of the file. – Oct 3 '14 at 18:50. I assume that you have a.cer file containing PKCS#7-encoded certificate data and you want to convert it to PEM-encoded certificate data (typically a.crt or.pem file). For instance, a.cer file containing PKCS#7-encoded data looks like this: -BEGIN PKCS7- MIIW4gYJKoZIhvcNAQcCoIIW0zCCFs8CAQExADALBgkqhkiG9w0BBwGggha1MIIH. POI9n9cd2cNgQ4xYDiKWL2KjLB+6rQXvqzJ4h6BUcxm1XAX5Uj5tLUUL9wqT6u0G +bKhADEA -END PKCS7- PEM certificate data looks like this: -BEGIN CERTIFICATE- MIIHNjCCBh6gAwIBAgIQAlBxtqKazsxUSR9QdWWxaDANBgkqhkiG9w0BAQUFADBm. Nv72c/OV4nlyrvBLPoaS5JFUJvFUG8RfAEY= -END CERTIFICATE- There is an OpenSSL command that will convert.cer files (with PKCS#7 data) to the PEM data you may be expecting to encounter (the BEGIN CERTIFICATE block in the example above). You can coerce PKCS#7 data into PEM format by this command on a file we'll call certfile.cer: openssl pkcs7 -text -in certfile.cer -printcerts -outform PEM -out certfile.pem Note that a.cer or.pem file might contain one or more certificates (possibly the entire certificate chain).
The.cer and.crt file should be interchangable as far as importing them into a keystore. Take a look at the contents of the.cer file. Erase anything before the -BEGIN CERTIFICATE- line and after the -END CERTIFICATE- line. You'll be left with the BEGIN/END lines with a bunch of Base64-encoded stuff between them.BEGIN CERTIFICATE- MIIDQTCCAqqgAwIBAgIJALQea21f1bVjMA0GCSqGSIb3DQEBBQUAMIG1MQswCQYD. PfDACIDHTrwCk5OefMwArfEkSBo/ -END CERTIFICATE- Then just import it into your keyfile using keytool.
Keytool -import -alias myalias -keystore my.keystore -trustcacerts -file mycert.cer.