Installing an SSL certificate: steps for any server

Installation differs between servers in syntax and in where files live, and not at all in what has to happen. The same five steps apply everywhere, and when an installation fails, the useful question is which of the five was left incomplete.

To install an SSL certificate, the server needs three things that belong together: the certificate, the private key it was issued for, and the intermediate certificates linking it to a root that browsers trust. Paths, directives and reload commands are covered per server: installing an SSL certificate on Apache, nginx SSL certificate installation, and an SSL certificate on IIS, where the certificate is imported into the Windows store rather than read from a file.

Sent by the server

its own certificate first, then the intermediates; the root can be left out ^[1][2]

Port

443, the default for https:// addresses ^[3]

Names checked

the DNS names in the certificate's Subject Alternative Name entries ^[4]

Installed where

wherever TLS terminates: the server, or a load balancer or CDN in front of it

Finished when

all three checks pass from outside the server

The five steps

To install an SSL certificate on any server, go through these five steps in order.

1. Generate a key and a request

   The private key stays on the server; the request goes to the authority. Covered on certificate signing requests.

2. Obtain the certificate and its chain

   The authority returns your certificate and the intermediates connecting it to a trusted root. Both are needed, and the chain is the part left behind when only the certificate file gets copied.

3. Place the files where the server expects them

   Location and permissions, with the key readable only by the account that serves it.

4. Point the configuration at them and enable encryption on the port

   Two distinct things: telling the server where the files are, and telling it to encrypt on the port, 443 for HTTPS ^[3]. Doing the first without the second produces a server answering in plain text on the encrypted port, which Firefox reports as SSL_ERROR_RX_RECORD_TOO_LONG ^[11].

5. Reload and verify from outside

   Installation is not service. A configuration written and never reloaded changes nothing, and a verification performed from the same machine proves less than one performed from elsewhere.

What you need: certificate, key and chain

Whatever the server, you install the same three inputs, and they only work as a set.

• The SSL certificate

  Issued for the names you serve. It contains the public half of a key pair and nothing secret.

• The private key

  The other half, generated together with the signing request. It never leaves the server, and it has to be the key this certificate was issued for, not one from an earlier request.

• The chain

  The intermediate certificates, sent after yours so that a client can connect your certificate to a root it already holds. The root itself stays out: clients have their own copy, and TLS lets the server omit it ^[1][2].

Before touching any configuration, compare the public key inside the certificate with the one derived from the private key. Each command prints a hash; the two must be identical.

$ openssl x509 -in example.com.crt -noout -pubkey | openssl sha256
$ openssl pkey -in example.com.key -pubout | openssl sha256

Different hashes mean the key belongs to another certificate, and no configuration will make that pair work.

Two preparations

• Know which configuration is actually in use

  A server with several sites, or one that has been reconfigured over the years, commonly has files that look authoritative and are not loaded. Editing one of those produces changes that have no effect, and the time goes to disbelief rather than to diagnosis.

• Have the current certificate and chain together before you begin

  An installation can fail on its inputs even when every step is done right: downloading the certificate and forgetting the chain, or taking last renewal's chain because it was already on the server. Assembling the inputs first turns installation into a short mechanical task.

Where each step goes wrong

Knowing the failure mode of each step turns diagnosis into elimination.

• Step 2, the chain

  Serving your certificate without the intermediates produces trust errors for some visitors and not others, and works fine for whoever installed it. That makes it the fault least visible to the person who made it, explained under SSL certificates, where chains have a page of their own.

• Step 3, permissions

  A key readable by more accounts than necessary is an exposure; a key unreadable by the serving account is an outage. Both are worth checking explicitly.

• Step 4, encryption not enabled

  The port is open, the files are configured, and nothing encrypts. The error is unmistakable once you know it, and baffling before.

• Step 5, not reloaded

  The first thing to check when "I installed it and nothing changed". The old certificate keeps being served until the process picks up the new configuration.

Why the order of the steps matters

The five steps are not interchangeable, and two orderings in particular cause avoidable outages.

• Do not point the configuration at files that are not there yet

  A server told to load a certificate it cannot read will refuse to start or refuse to reload, depending on the software, and on a live machine that turns a routine change into an interruption. Place the files first, then edit the configuration.

• Do not remove the old certificate until the new one is verified

  The old files cost nothing to keep for a day, and they are the fastest recovery available if the replacement turns out to be wrong.

The wider point is that installation on a live server is a change with a rollback, and treating it that way costs one extra minute. A step becomes irreversible only when nobody kept the previous state.

Verifying properly

Once you install an SSL certificate, verification is three checks, from outside the server, in this order.

1. What certificate is actually presented, by its dates and names rather than by what is on disk. This catches steps 3 and 5 at once.

2. Whether the chain is complete. An external checker reports missing intermediate certificates; your own browser does not, as the FAQ below explains.

3. Whether every name you serve is covered, including the bare domain and the www form, which is where a name mismatch error, ERR_CERT_COMMON_NAME_INVALID in Chrome, comes from ^[10].

A checker performs all three at once, which is why it belongs at the end of every installation rather than only when something is wrong. From another machine, OpenSSL shows what HTTPS visitors receive:

$ openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -ext subjectAltName
$ openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null

The first prints the certificate's dates and names. The second lists, under Certificate chain, what the server sent, yours as 0; a list ending at 0 means no intermediates were sent. Verify return code: 0 (ok) means OpenSSL built a path to a root it trusts. Keep -servername: a server hosting several sites needs it to pick the certificate ^[9].

Choose your server

The specifics of file locations, configuration syntax, and reloading are on the page for your software. What differs first is the form in which each server takes the three inputs:

When the certificate request is generated in IIS Manager, IIS keeps the matching key in the store until the certificate arrives. Moving a certificate to another server means taking that key along: on IIS, an export to a PFX file and a certificate import on the other machine.

If you use a control panel or a managed platform, the five steps still apply and most of them are performed for you. What remains yours is verifying the result, which the panel's success message does not do.

Where installation is not the answer

If a delivery layer or load balancer terminates connections in front of your servers, the certificate belongs there, and installing one on the origin changes nothing visitors experience. Installing in both places is sometimes correct and is a deliberate decision rather than a default.

And where certificates are issued and deployed automatically, none of this is manual work at all. The automation performs these steps, which is the point of it, and the material on ACME certificate automation covers that path.

Who performs the installation decides how much of this page stays yours:

• You, by hand

  All five steps, and the check from outside.

• An ACME client on your server

  It obtains and renews the certificate over the ACME protocol (RFC 8555) ^[12] and performs the steps described here. The check from outside remains with you.

• A platform that terminates TLS for you

  For example, Bridge SSL is the certificate layer of Bridge CDN: the platform issues a certificate through ACME when a hostname needs one, serves it and renews it, so there is no certificate file of yours to install there. Checking the result from outside applies here as on every other path.

FAQ

Steps and where the certificate goes

Chains, roots and reloads

Sources

1. RFC 8446, TLS 1.3, section 4.4.2 — sender's certificate first; a trust anchor may be omitted.

2. RFC 5246, TLS 1.2, section 7.4.2 — the same order; the root may be omitted.

3. RFC 9110, HTTP Semantics, section 4.2.2 — port 443 is the https default.

4. RFC 9525, Service Identity in TLS — DNS names are checked through subjectAltName.

5. nginx documentation, ngx_http_ssl_module, ssl_certificate.

6. Apache HTTP Server 2.4 documentation, mod_ssl, SSLCertificateFile and SSLCertificateChainFile.

7. Microsoft Learn, How to Set Up SSL on IIS 7 or later.

8. RFC 7292, PKCS #12 — the format behind PFX files.

9. RFC 6066, section 3 — Server Name Indication.

10. Chromium source, net_error_list.h — CERT_COMMON_NAME_INVALID.

11. NSS source, SSLerrs.h — SSL_ERROR_RX_RECORD_TOO_LONG.

12. RFC 8555, Automatic Certificate Management Environment (ACME).

13. Certbot documentation, User Guide, Getting certificates (and choosing plugins) — authenticators and installers; the apache, nginx, webroot and standalone plugins.