Quick Links

• What Is a PEM File?

• PEM Files with SSL Certificates

• PEM Files with SSH

PEM is a container file format often used to store cryptographic keys. It's used for many different things, as it simply defines the structure and encoding type of the file used to store a bit of data.

What Is a PEM File?

PEM is just a standard; they contain text, and the format dictates that PEM files start with...

-----BEGIN <type>-----

...and end with:

-----END <type>-----

Everything in between is base64 encoded (uppercase and lowercase letters, digits, +, and /). This forms a block of data that can be used in other programs. A single PEM file can contain multiple blocks.

This can be used to represent all kinds of data, but it's commonly used to encode keyfiles, such as RSA keys used for SSH, and certificates used for SSL encryption. The PEM file will tell you what it's used for in the header; for example, you might see a PEM file start with...

-----BEGIN RSA PRIVATE KEY-----

...followed by a long string of data, which is the actual RSA private key.

PEM Files with SSL Certificates

PEM files are used to store SSL certificates and their associated private keys. Multiple certificates are in the full SSL chain, and they work in this order:

• The end-user certificate, which is assigned to your domain name by a certificate authority (CA). This is the file you use in nginx and Apache to encrypt HTTPS.
• Up to four optional intermediate certificates, given to smaller certificate authorities by higher authorities.
• The root certificate, the highest certificate on the chain, which is self-signed by the primary CA.

In practice, each certificate is listed in a PEM file, using seperate blocks:

-----BEGIN CERTIFICATE-----  
 //end-user
  
-----END CERTIFICATE-----
  
-----BEGIN CERTIFICATE-----
  
 //intermediate
  
-----END CERTIFICATE-----
  
-----BEGIN CERTIFICATE-----
  
 //root
  
-----END CERTIFICATE-----

You'll be given these files from your SSL provider for use in your web server. For example, LetsEncrypt's certbot generates the following certificates, placed in /etc/letsencrypt/live/your-domain-name/ :

cert.pem chain.pem fullchain.pem privkey.pem

• cert.pem is the end-user certificate.
• chain.pem is the rest of the chain; in this case, it's only LetsEncrypt's root certificate.
• fullchain.pem is cert.pem and chain.pem combined. This is the file passed to nginx with the ssl_certificate directive.
• privkey.pem is an RSA private key generated alongside the certificate.

These may also use the .crt extension; if you've self-signed a certificate with OpenSSL, you'll get a CRT file rather than PEM, though the contents will still be the same, and the usage will be the same.

To use your certificates, you'll have to pass them as parameters for your web server. For nginx, you'll want to specify the ssl_certificate (the full chain PEM file), and ssl_certificate_key (the RSA private key PEM file), after turning on SSL:

ssl_certificate /etc/letsencrypt/live/yourdomain/fullchain.pem;  
ssl_certificate_key /etc/letsencrypt/live/yourdomain/privkey.pem;

For Apache, setup is largely the same, but you'll need to use the SSLCertificateFile and SSLCertificateKeyFile directives:

SSLCertificateFile /etc/letsencrypt/live/yourdomain/fullchain.pem  
SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain/privkey.pem

PEM Files with SSH

PEM files are also used for SSH. If you've ever run ssh-keygen to use ssh without a password, your ~/.ssh/id_rsa is a PEM file, just without the extension.

Most notably, Amazon Web Services gives you a PEM file containing a private key whenever you create a new instance, and you must use this key to be able to SSH into new EC2 instances.

You'll have to use the -i flag with ssh to specify that you want to use this new key instead of id_rsa:

ssh -i keyfile.pem root@host

This will sign you in to the server as normal, but you'll have to specify this flag each time.

An easier method is to add the private key to your ssh-agent with ssh-add:

ssh-add keyfile.pem

However, this doesn't persist across reboots, so you'll need to run this command on startup or add it to your macOS keychain.

Of course, you could also always simply append your primary public key to the instance's ~/.ssh/authorized_keys after you've signed in once, but this method should work out of the box for any new instances going forward.

It's worth noting that you should still lock down your SSH server even if you're using keys yourself.

ncG1vNJzZmivp6x7qbvWraagnZWge6S7zGibnq6fpcBww8eaq2aho2KubrzEpmSfoZyaeqK6w2afqK9dmbxuxc6uZK6rlWK2tXs%3D