Installing an SSL certificate: steps for any server

The five steps

• 1. Generate a key and a request

  The 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, which is the step most often half-completed.

• 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. Doing the first without the second produces a server answering in plain text on the encrypted port, described on SSL_ERROR_RX_RECORD_TOO_LONG.

• 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.

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. This is the single most common installation fault, explained under 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 rather than assuming the defaults were right.

• 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 most frequent cause of "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. Most of the incidents that follow certificate work come from steps that were irreversible only because nobody kept the previous state.

Verifying properly

Three checks, from outside the server, in this order.

• 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.

• Whether the chain is complete

  An external checker reports it; your own browser does not, for the reasons on the chain page.

• Whether every name you serve is covered

  , including the bare domain and the www form, which is the mismatch described on ERR_CERT_COMMON_NAME_INVALID.

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.

Choose your server

The specifics of file locations, configuration syntax, and reloading are on the page for your software:

• Nginx
• Apache
• IIS

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.

What to do before you start

Two preparations save most of the time lost during installations.

• 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

  Most failed installations are not failures of the steps but of the inputs: 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.

A third preparation applies when replacing a working certificate. Keep the existing files until the replacement is verified, since the fastest recovery from a botched installation is putting back what was working, and that is only possible if it still exists.

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 certificate automation covers that path.

Install once, renew automatically with Bridge SSL

Bridge SSL issues certificates, serves them with their full chain, and renews them on a schedule, which removes steps 2 through 5 from your workflow entirely. The failure modes on this page (an incomplete chain, a configuration never reloaded, a renewal that arrived and was not deployed) are properties of manual installation rather than of certificates. See what the platform offers at Bridge CDN.

FAQ