(DC) Certificate Parts and Chain

(DC) Certificate Parts and Chain

Understanding SSL/TLS Certificate Files: A Guide to What's in Your ZIP

What Is an SSL/TLS Certificate, and Why Does It Exist?

When your browser connects to a website over HTTPS, it needs to do two things:

  1. Verify that the server it is talking to is actually who it claims to be, not an imposter.

  2. Encrypt the data flowing between the browser and the server so no one can eavesdrop.

SSL and TLS are often used interchangeably, but TLS is the modern protocol. SSL is the older name that people still commonly use. Certificates are part of what makes HTTPS possible: they identify the server, provide the server's public key, and connect that identity to a trusted Certificate Authority.

Think of a certificate like a notarized ID card. It contains the server's identity and cryptographic information, and it has been signed by a trusted authority to prove it is legitimate.

image-20260730-203517.png

Files in the downloaded ZIP file

The file name can and usually is: order_id.zip

File

What it is

Purpose

File

What it is

Purpose

01_EndEntity_cns-fms-03.austin.utexas.edu.cer

Server certificate

Identifies the web server and contains its public key.

02_SubCA_InCommon Intermediate CA - OVG2C.cer

Intermediate CA certificate

Helps link the server certificate to a trusted CA.

03_CA_emSign Root TLS CA - G1.cer

Intermediate / CA certificate

Another link in the chain between the InCommon intermediate and the root.

04_RootCA_emSign Root CA - G1.cer

Root CA certificate

The top-level trust anchor. Usually trusted by the client, not installed as the server certificate.

8131396184_fullchain.pem

Full chain file

Bundled server certificate plus the required intermediate certificates.

The Building Blocks: What Each Part Does

The Part

 

The Part

 

Private Key

The private key is a secret cryptographic key that lives only on your server. It should never be shared, emailed, uploaded to a ticket, or stored somewhere insecure.

The private key pairs with the public key inside the certificate. During a TLS connection, the server uses the private key to prove that it is the rightful owner of the certificate. If someone steals the private key, they may be able to impersonate the server.

  • If generating a certificate via CSR using the CERTInext portal, then the private is usually generated on the server when the CSR is generated and is not include in the zip file you download.

  • If generating a certificate via a script, then all parts are generated for you: Private Key, Certificates, CSR, and Full Chain.

NEVER send or transmit the private key via email or ticket. Always use a University approved tool to send sensitive information, such as the private key. If the private key were ever to be compromised, you need to start over, else all communication using the certificate/private key bundle can be intercepted.

CSR
Certificate Signing Request

A CSR, or Certificate Signing Request, is created when requesting a new certificate. It contains information such as the server name and organization details, plus the server's public key.

The CSR is sent to a Certificate Authority, often abbreviated as CA. The CA validates the request and uses the CSR to issue the final certificate. After the certificate is issued, the CSR is no longer needed for normal web server operation.

Certificate
technically called an “End-Entity Certificate”

The certificate is the certificate issued specifically for the server. It is sometimes called the server certificate, leaf certificate, or site certificate.

In this ZIP file, the certificate is: 01_EndEntity_xxxxxx.austin.utexas.edu.cer

This certificate identifies the server xxxxxx.austin.utexas.edu. It includes the server's public key, the server names covered by the certificate, an expiration date, and a digital signature from the issuing CA.

Intermediate Certificate / SubCA

An intermediate certificate is a CA certificate that sits between the server certificate and the root certificate. It may also be called a SubCA, short for subordinate Certificate Authority.

Certificate Authorities generally do not sign individual server certificates directly with their most trusted root certificate. Instead, they use one or more intermediate CAs. This is safer because an intermediate CA can be replaced or revoked without replacing the root CA that many systems already trust.

In this ZIP file, one intermediate certificate is: 02_SubCA_InCommon Intermediate CA - OVG2C.cer

Root Certificate

The root certificate is the trust anchor at the top of the chain. Root certificates are usually pre-installed in operating systems, browsers, and device trust stores.

Root certificates are self-signed, meaning the root CA signs its own certificate. Browsers and operating systems trust the root because it has already been added to their trusted root store.

In this ZIP file, the root certificate is: 04_RootCA_emSign Root CA - G1.cer

Certificate Chain / Full Chain

A certificate chain is the ordered set of certificates that connects the server certificate back to a trusted root. Each certificate is signed by the certificate above it.

The full chain file bundles the server certificate and the necessary intermediate certificates together into one file. In this ZIP file, that file is:

8131396184_fullchain.pem

A PEM file is a text-based certificate format. If you open it in a text editor, you will see one or more blocks that begin with -----BEGIN CERTIFICATE----- and end with -----END CERTIFICATE-----.

How the Certificates Relate: Signing and Trust

The certificates in this ZIP form a chain of trust. Each lower certificate is signed by the certificate above it.

A browser verifies the server certificate by walking up the chain:

  1. The browser receives the server certificate.

  2. It checks which CA signed that certificate.

  3. It checks the intermediate certificate that signed it.

  4. It continues upward until it reaches a root certificate that the browser or operating system already trusts.

If the chain is complete and every signature is valid, the certificate is trusted. If one of the intermediate certificates is missing, clients may show a certificate warning even if the server certificate itself is valid.

image-20260730-204520.png

What Files Do You Need on a Web Server?

Best Practice: Install the Full Chain

The current best practice is to configure the web server with the full chain, not just the individual server certificate. This helps ensure that clients can validate the certificate even if they cannot download missing intermediate certificates from the internet.

For this ZIP file, the recommended certificate file to install on the web server is: 8131396184_fullchain.pem

You will also need the matching private key that was created when the CSR was generated. The private key is not listed in the ZIP contents above, so it should already be on the server or in the secure location where the CSR was created.

Web Server with Internet Access

Some clients can retrieve missing intermediate certificates from the internet using information embedded in the certificate. This mechanism is called AIA, or Authority Information Access.

However, relying on AIA is not recommended. It can fail due to firewall rules, client limitations, DNS issues, network restrictions, or outages.

Key Takeaways

  • The private key stays secret and remains on the server.

  • The CSR is used to request the certificate and is not normally used after issuance.

  • The end-entity certificate identifies the specific server.

  • Intermediate certificates connect the server certificate to a trusted root.

  • The root certificate is the trust anchor already trusted by clients, or distributed to clients when necessary.

  • The full chain bundles the server certificate and intermediates together.

  • Modern practice is to install the full chain on the web server.

Glossary

Term

Meaning

Term

Meaning

SSL

Secure Sockets Layer. The older name people still use for encrypted web connections.

TLS

Transport Layer Security. The modern protocol used for HTTPS encryption.

HTTPS

HTTP over TLS. The secure version of web traffic.

Certificate

A digital document that binds an identity to a public key and is signed by a CA.

CA

Certificate Authority. An organization trusted to issue and sign certificates.

Private key

The secret key that proves the server owns the certificate. It must be protected.

Public key

The non-secret key included in the certificate and used by clients during TLS setup.

CSR

Certificate Signing Request. The request file sent to a CA to obtain a certificate.

End-entity certificate

The certificate issued for the actual server or website.

Intermediate certificate

A CA certificate that links the server certificate to a trusted root.

Root certificate

The top-level trusted certificate in a certificate chain.

Full chain

A file containing the server certificate and intermediate certificates in order.

PEM

A text-based file format commonly used for certificates and keys.

AIA

Authority Information Access. Certificate metadata that can point clients to missing intermediate certificates.