Install an SSL certificate on Apache

The steps common to every server are on installing a certificate.

Before you start

• The certificate, its chain, and the private key.
• Confirmation that the encryption module is enabled. Apache serves

encrypted connections through a module, and a virtual host configured without it produces startup errors about unknown directives rather than anything about certificates.

• The virtual host file that serves this site, since a server with

several sites has several, and editing the wrong one is the most common way to spend an hour on nothing.

• Access to test the configuration and restart the service.

The chain: one file or two

This is the Apache-specific fork.

Older versions used a separate directive for the chain file, keeping the certificate and the intermediates apart. Current versions read the chain from the certificate file itself, in the same combined form other servers expect, and the separate directive is deprecated.

The practical rule: if your Apache accepts the combined form, use it, and if you are following documentation that specifies the separate directive, check whether your version still honours it. Both approaches work on versions that support them, and mixing them, by supplying a combined file and also pointing the old directive at an intermediate, is where confusion starts.

To combine, place your certificate first and the intermediates after it:

$ cat example.com.crt intermediate.crt > example.com.chained.crt

Omitting the intermediates produces the selective trust failure on ERR_CERT_AUTHORITY_INVALID, which works for whoever installed it and fails for fresh visitors.

Place the files

Outside the document root, with the key restricted.

$ chmod 600 example.com.key
$ chown root:root example.com.key

Configure the virtual host

The encrypted site lives in its own virtual host on the encrypted port, with encryption switched on explicitly.

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com

    SSLEngine on
    SSLCertificateFile    /etc/ssl/example.com.chained.crt
    SSLCertificateKeyFile /etc/ssl/example.com.key

    # ... the rest of the site configuration
</VirtualHost>

SSLEngine on is the directive that actually enables encryption. A virtual host on the encrypted port without it answers in plain text, which is the fault behind SSL_ERROR_RX_RECORD_TOO_LONG.

ServerName and ServerAlias must between them list every hostname this site serves, and the certificate must cover all of them, or visitors to the uncovered name see the mismatch described on ERR_CERT_COMMON_NAME_INVALID.

Redirect the unencrypted version

A separate virtual host on the unencrypted port sends visitors across.

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    Redirect permanent / https://example.com/
</VirtualHost>

The redirect runs after the connection is established, so it cannot rescue a name the certificate does not cover. Both names still need to be on the certificate.

Test and restart

Apache validates its configuration on demand, and doing so before restarting turns a possible outage into a message.

$ apachectl configtest
$ apachectl graceful

A graceful restart applies the new configuration while letting existing connections finish, which is preferable to a hard restart on a live server.

If the test complains about unknown directives, the encryption module is not enabled, which is the case worth checking first because the message does not say so plainly.

Verify from outside

Confirm the certificate presented, the completeness of the chain, and the coverage of every name in ServerName and ServerAlias. An external checker reports all three; your own browser reports the first reliably and the second not at all.

Run this after every certificate change rather than only when something is reported broken. On Apache in particular, a virtual host that fails to load silently leaves the previous configuration in place, so a restart that appeared to succeed can be serving the old certificate.

Several sites on one server

Apache selects a virtual host by the requested name. If none matches, the first virtual host defined for that port serves the request, along with its certificate.

That default behaviour produces two recognisable symptoms. A new site whose virtual host was never created receives another site's certificate. And a site whose virtual host failed to load, because of a syntax error elsewhere in the file, falls back the same way while appearing to be configured.

Where several names share a certificate, one virtual host can serve them all. Where they have separate certificates, each needs its own virtual host, since a virtual host holds one certificate.

When the site is behind something else

This decides whether the page applies at all, and it is settled before anything is installed.

If a load balancer, a reverse proxy, or a delivery layer terminates connections in front of Apache, the certificate visitors see belongs there, not here. Installing one on Apache in that arrangement changes nothing they experience, and time spent debugging it is time spent on the wrong machine.

Apache may still need its own certificate in that arrangement, for the connection between the front end and itself. That certificate serves a different purpose and often has different requirements: it is not seen by visitors, and depending on the configuration it may not need to be issued by a public authority at all.

Establishing which of the two you are configuring takes one question, and asking it first avoids the most frustrating variety of certificate work, where everything is correct and nothing changes.

Common mistakes on Apache

• The encryption module is not enabled

  Directives are rejected as unknown, and the message points at syntax rather than at the module.

• The chain is missing or supplied twice

  Either the intermediates are absent, or they are both in the combined file and pointed at by the deprecated directive.

The configuration was tested and the service not restarted. Testing validates; restarting applies.

A syntax error elsewhere prevented the virtual host from loading Everything looks configured, and the site is served by the default host.

Automate this with Bridge SSL

Bridge SSL issues certificates and serves them with their full chain, so the combination step, the version-dependent chain directive, and the restart all disappear from the process. Renewal happens on a schedule rather than as work on the server, which removes the case where a certificate is renewed correctly and the service never picks it up. See what the platform offers at Bridge CDN.

FAQ