What is server-chain.pem?
What is server-chain.pem?
server-chain.pem
is a filename convention for a file that typically contains an SSL/TLS certificate chain for a server, formatted in the PEM (Privacy Enhanced Mail) format.
Breaking it down…
server
- This indicates that the certificate(s) in this file are intended for use by a server (e.g., a web server like Apache or Nginx, an email server, etc.) to prove its identity to clients and enable encrypted communication (HTTPS, SMTPS, etc.).
chain
- This is the crucial part. SSL/TLS certificates operate on a
chain of trust.
- Server Certificate (End-entity certificate)
- This is the certificate issued specifically for your server’s domain name (e.g.,
www.example.com
).
- This is the certificate issued specifically for your server’s domain name (e.g.,
- Intermediate Certificate(s)
- To enhance security and manageability, Certificate Authorities (CAs) often don’t sign server certificates directly with their highly protected root certificate. Instead, they use one or more
intermediate
certificates. Your server certificate is signed by an intermediate CA, which might be signed by another intermediate CA, or directly by a root CA.
- To enhance security and manageability, Certificate Authorities (CAs) often don’t sign server certificates directly with their highly protected root certificate. Instead, they use one or more
- Root Certificate
- This is a certificate from a trusted Root CA (e.g., Let’s Encrypt, DigiCert, Sectigo). Root certificates are pre-installed in web browsers and operating systems’ trust stores.
- The
chain
is the sequence: Server Certificate -> Intermediate Certificate(s) -> (leading up to, but not usually including) Root Certificate. - The
server-chain.pem
file typically contains the server certificate plus all necessary intermediate certificates concatenated together. The client (e.g., a web browser) needs these intermediate certificates to verify the server’s certificate by tracing a path back to a root certificate it trusts.
- This is the crucial part. SSL/TLS certificates operate on a
.pem
(Privacy Enhanced Mail)- This is a common file format for storing cryptographic information, including X.509 certificates and private keys.
- It’s a base64 encoded representation of the DER (Distinguished Encoding Rules) encoded certificate data.
- PEM files are plain text and typically look like this (for a single certificate):
-----BEGIN CERTIFICATE----- MII... (lots of base64 encoded data) ...AAC -----END CERTIFICATE-----
- A `server-chain.pem` file will contain multiple such blocks concatenated:
-----BEGIN CERTIFICATE----- (Server Certificate data) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Intermediate Certificate 1 data) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Intermediate Certificate 2 data, if any) -----END CERTIFICATE-----
- The order usually matters: The server certificate should come first, followed by the intermediate that signed it, then the intermediate that signed the previous one, and so on.
Why is it needed?
When a client connects to your server over HTTPS, your server presents its certificate. If the server only sends its own certificate, but the client doesn’t directly trust the CA that signed it (and doesn’t have the intermediate certificate cached), the client won’t be able to verify the server’s identity.
By providing the server-chain.pem
(which includes the server certificate and the necessary intermediates), the server gives the client all the pieces it needs (except the root, which the client should already have) to build the chain of trust and validate the server’s identity.
Important Note
The server-chain.pem
file should NOT contain the private key. The private key (often named server.key
, private.key
, or domain.key
) must be kept separate and secure on the server. This chain file is public information.
In summary
server-chain.pem
is a file containing the server’s SSL/TLS certificate and the necessary intermediate CA certificates, all bundled together in PEM format. It’s used by servers to present their identity and enable clients to verify that identity during the TLS handshake.