fullchain.pem vs cert.pem vs chain.pem: Which File Should Your Server Use?

One of the most common certificate-deployment mistakes is using the right certificate in the wrong file format or path.

That mistake often hides behind symptoms like:

• some browsers trust the site and others do not
• SSL checkers report an incomplete chain
• renewal succeeds but the site still looks misconfigured

The root cause is often confusion between cert.pem, chain.pem, and fullchain.pem.

The short answer

Current Certbot documentation explains the distinction clearly:

• cert.pem is the server certificate by itself
• chain.pem contains the intermediate certificate or certificates
• fullchain.pem contains the server certificate plus the intermediate chain

For NGINX, Certbot documents that ssl_certificate should normally point to fullchain.pem and ssl_certificate_key should point to privkey.pem.

If you point NGINX at only cert.pem, the server may present the leaf certificate without the intermediate chain that many clients need.

Why this matters so much

Browsers and TLS clients do not all behave identically when the server omits intermediates.

Current Certbot documentation warns that if you provide only cert.pem or only chain.pem where the server really needs both, some browsers can show untrusted-connection errors some of the time.

That "some of the time" behavior is exactly why this problem is confusing in production.

It can look like:

• a browser-specific issue
• a stale cache problem
• a random monitoring false positive

when the real issue is just an incomplete certificate presentation.

What each file actually means

cert.pem

This is the end-entity certificate for your hostname.

It proves the hostname identity, but by itself it is usually not enough for a normal NGINX certificate presentation.

chain.pem

This contains the intermediate certificates that bridge trust between your server certificate and a trusted root.

It is an important part of the trust path, but by itself it is not the server certificate.

fullchain.pem

This combines the leaf certificate and the intermediate certificates in the order the server needs to present them to clients.

That is why it is usually the correct file for ssl_certificate in NGINX.

Why incomplete-chain issues appear after renewal

Renewal can work perfectly and still leave the site misconfigured if:

• the server points to cert.pem instead of fullchain.pem
• the deployment copied an old PEM bundle into a custom location
• the wrong certificate path is active in one virtual host but not another

This is why a renewal success message is not enough to prove that the public certificate chain is healthy.

Why this belongs in the domain/TLS workflow

Domain lookup helps you understand whether the hostname terminates on:

• a direct NGINX host
• a reverse proxy
• a load balancer
• an edge layer or CDN

That matters because the chain problem might not be on the origin where Certbot ran. It may be on the public TLS terminator that is still pointing at the wrong bundle.

The NGINX-side detail that matters

Current NGINX HTTPS documentation says that the server certificate must appear first in the combined file, followed by the intermediate certificates.

That file ordering matters. A valid set of certificates in the wrong order can still break client trust.

So this is not only about "having the right files." It is also about presenting them in the right combined structure.

When to suspect the wrong file immediately

Suspect this problem when:

• Certbot renewed successfully
• the hostname still shows trust or chain warnings
• one environment works and another does not
• the web server config references cert.pem directly
• a copied PEM file is used instead of the live Certbot path

The clean operational rule

For standard Certbot and NGINX setups:

• point ssl_certificate to fullchain.pem
• point ssl_certificate_key to privkey.pem
• avoid copying certificates into ad hoc locations unless you also automate that step correctly

If the system needs a converted or exported format for another proxy or appliance, treat that as a deployment pipeline and automate it explicitly.

Common misunderstandings

"cert.pem is the certificate, so that must be enough"

Not for normal browser trust in many deployments.

The leaf certificate alone does not necessarily provide the intermediate chain clients need.

"If one browser trusts it, the chain must be correct"

No.

Some clients can build trust from cached or locally available intermediates while others cannot.

"Renewal fixed the certificate, so the chain warning must be unrelated"

Not necessarily.

Renewal and correct public chain presentation are different operational steps.

FAQ

Which file should NGINX usually use for ssl_certificate?

Current Certbot documentation says fullchain.pem is the normal choice for ssl_certificate.

What is the difference between cert.pem and chain.pem?

cert.pem is the leaf certificate for the hostname, while chain.pem contains the intermediate certificates needed to build trust.

Why does an incomplete-chain issue affect only some clients?

Because different clients may have different cached intermediates or different trust-path behavior, so a missing intermediate does not fail identically everywhere.

Can the certificate order inside the file matter?

Yes. Current NGINX documentation says the server certificate should come first, followed by the intermediate certificates.