Let’s Encrypt Certificate Files Explained: cert.pem, chain.pem, fullchain.pem, and privkey.pem

Overview

A Let’s Encrypt certificate deployment normally involves two different kinds of material: a public certificate and a private key. The public certificate identifies your domain and is safe to serve to clients. The private key proves that your server controls the certificate and must remain confidential.

Certbot commonly stores certificate-related files beneath /etc/letsencrypt/live/<your-domain>/. The files in this directory are usually symbolic links to versioned files in /etc/letsencrypt/archive/. That arrangement allows Certbot to update the live paths during renewal while server software continues using the same configured filenames.

The most important distinction is between cert.pem and fullchain.pem. The first contains only the certificate for your domain. The second contains your domain certificate followed by the intermediate certificate needed by clients to build a trusted chain. Most web servers should use fullchain.pem for the public certificate setting.

How to compare options

Before changing a TLS configuration, identify what the receiving software expects. Certificate settings are not named consistently across products. One interface may ask for a “certificate,” another for a “public certificate,” and another for a “PEM bundle.” These labels describe roles, not necessarily the Let’s Encrypt filename.

1. Find the public certificate field. Use fullchain.pem when the software expects one bundled PEM file. If it has separate fields for the certificate and intermediate chain, use cert.pem and chain.pem respectively.
2. Find the private-key field. Use privkey.pem. Never substitute a public certificate file for the private key, and do not paste the private key into a certificate-chain field.
3. Check the accepted format. Let’s Encrypt files are PEM text files. A provider may instead request a combined PEM bundle, a different filename, or a certificate and key uploaded separately.
4. Confirm the deployment location. A load balancer, CDN, container, and origin server can each have a separate TLS configuration. Installing the files on the origin does not automatically install them on a proxy or load balancer.
5. Test after reloading. A configuration file can be syntactically valid while the wrong certificate is being served for a hostname. Test the actual public endpoint after the service reloads.

For a broader deployment sequence, use this Let’s Encrypt Certbot setup guide. If the certificate is being moved with a site or server, the website migration checklist can help separate certificate work from DNS and application migration tasks.

Feature-by-feature breakdown

cert.pem: the leaf certificate

cert.pem is the certificate issued for your domain or domains. It contains identity information and the public key, but not the private key. It is useful when software has a dedicated field for the leaf certificate and another field for intermediate certificates. By itself, however, it may not give every client the chain it needs.

chain.pem: the intermediate certificates

chain.pem contains the intermediate certificate material that connects the domain certificate to a trusted root. It does not identify your domain on its own and it cannot replace the leaf certificate. Use it only when the server or appliance explicitly provides a separate chain or intermediate-certificate setting.

fullchain.pem: the usual server certificate file

fullchain.pem combines the leaf certificate and intermediate chain in the order generally expected by TLS servers: the domain certificate first, followed by the intermediate certificate or certificates. This is why it is normally the correct choice for an Nginx certificate directive, an Apache certificate file directive, or a reverse proxy that accepts one certificate bundle.

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

For Apache, the exact directives depend on the installed Apache version and configuration style, but the roles remain the same:

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
</VirtualHost>

Some older or specialized Apache configurations expose a separate chain directive. In that case, consult the software documentation and use cert.pem for the certificate, chain.pem for the chain, and privkey.pem for the key. Avoid adding a separate chain file when the certificate field already expects fullchain.pem, because duplicating chain material can create confusing configuration errors.

privkey.pem: the private key

privkey.pem must be protected more carefully than the other files. Anyone who obtains the private key may be able to impersonate the certificate’s subject until the certificate is replaced and the key is no longer trusted by your deployment. Keep it on the server or secret store that needs it, restrict access to the service account, and do not commit it to source control, send it through chat, or publish it in a diagnostic archive.

File permissions must balance security with service operation. The web server process needs permission to read the key at startup or reload, either directly or through group membership. The exact owner and mode depend on the operating system and service model. Rather than applying a broad permission such as world-readable access, identify the service account and grant the narrowest access that permits a controlled reload.

How Certbot paths behave during renewal

Configure services to use the stable paths under /etc/letsencrypt/live/, not a numbered file under archive/. Certbot can update the symbolic links when it obtains a replacement certificate. Your renewal process must still reload or restart the service so it reads the new certificate. A successful renewal on disk does not necessarily mean that the running process is serving the renewed certificate.

After changing a configuration, validate it before reloading. For example, use the relevant Nginx or Apache configuration-test command, then reload the service only if the test succeeds. This reduces the risk of replacing a working TLS configuration with one containing a path, syntax, or permission error.

Best fit by scenario

• Nginx: Use fullchain.pem with privkey.pem in the TLS server block. This is the common answer to “which Let’s Encrypt files does Nginx need?”
• Apache: Use fullchain.pem and privkey.pem when the configuration provides one certificate-file directive. Use separate cert.pem and chain.pem only when the configuration explicitly separates those roles.
• Load balancer or CDN: Follow the product’s upload fields. If it asks for a certificate bundle and private key, provide the full chain and key separately. Verify whether the service expects the private key in PEM format and whether it retains or encrypts uploaded secrets.
• Application server: Check the application’s TLS documentation. Some applications accept PEM paths, while others require a keystore or a combined file. Do not assume that a file suitable for Nginx can be passed directly to every runtime.
• Separate certificate and chain fields: Use cert.pem as the certificate, chain.pem as the intermediate chain, and privkey.pem as the private key.

If clients report an incomplete chain, first check whether the endpoint is serving cert.pem where fullchain.pem is required. If the wrong domain appears, inspect the selected virtual host, SNI configuration, and certificate names. If the service will not start, check the key permissions, file paths, PEM formatting, and whether the certificate and private key match.

For related certificate failures, redirects, and renewal issues, see the HTTPS troubleshooting checklist. Certificate files solve only the certificate portion of HTTPS; redirects, security headers, DNS, and application mixed-content issues require separate checks.

When to revisit

Revisit this reference whenever a certificate is reissued, a server is rebuilt, a domain is migrated, or a TLS-terminating proxy is introduced. It is also worth checking after changing Certbot plugins, operating-system packages, hosting panels, container images, or load-balancer configuration, because those changes may alter where files are stored or which fields are available.

Make the review part of every certificate change:

1. List the hostnames covered by the new certificate and confirm they match the endpoint being served.
2. Confirm that the public certificate setting uses fullchain.pem, unless separate certificate and chain fields are explicitly required.
3. Confirm that the private-key setting uses the matching privkey.pem and that its permissions are restricted.
4. Run the server’s configuration test before reloading it.
5. Reload the TLS-terminating service and inspect the public endpoint, not only the files on disk.
6. Verify that renewal automation includes a service reload and that failures are visible through logs or monitoring.

Keeping these checks in a migration or renewal runbook prevents a familiar filename from becoming an assumption. The practical rule is simple: use fullchain.pem for the public certificate bundle in most web-server configurations, use privkey.pem for the matching secret key, and use cert.pem plus chain.pem only when the receiving software asks for them separately.