How to Install an SSL Certificate on Apache From Scratch

The Apache equivalent of a from-scratch Nginx setup: enabling the SSL module, configuring a VirtualHost for HTTPS, and adding the redirect — with Apache's own specific directive names and a couple of Apache-specific gotchas.

1. Enable the SSL module

sudo a2enmod ssl
sudo systemctl restart apache2

On Debian/Ubuntu-based systems, Apache's modules are enabled individually this way; other distributions may have mod_ssl compiled in by default or require a different enabling mechanism — check your specific distribution's Apache documentation if a2enmod isn't available.

2. The HTTPS VirtualHost

<VirtualHost *:443>
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com
    DocumentRoot /var/www/yourdomain

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/cert.pem
    SSLCertificateKeyFile /etc/apache2/ssl/privkey.pem
    SSLCertificateChainFile /etc/apache2/ssl/chain.pem
</VirtualHost>

Unlike Nginx (which typically expects a single concatenated full-chain file), Apache traditionally uses a separate SSLCertificateChainFile directive for the intermediate bundle — though newer Apache/mod_ssl versions also support a combined file via SSLCertificateFile alone. Check your specific Apache version's documentation, since using the wrong pattern for your version is a common source of chain-related trust errors.

3. The HTTP redirect VirtualHost

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

As with Nginx, this needs to be a separate VirtualHost bound to port 80 — Apache selects which VirtualHost handles a request partly based on the port it's listening on, so redirect logic belongs in the port-80 block exactly.

4. Enable the site and reload

sudo a2ensite yourdomain-ssl.conf
sudo apachectl configtest && sudo systemctl reload apache2

As with Nginx's -t flag, apachectl configtest validates syntax before reloading — always run this first, since a broken configuration can otherwise take the site down on reload rather than being caught beforehand.

5. Confirm listening ports

Check that Apache's ports.conf (or equivalent) includes Listen 443 — a surprisingly common oversight when adding HTTPS to a server that was previously HTTP-only, since Apache won't automatically start listening on a new port just because a VirtualHost references it.

6. Basic hardening

SSLProtocol -all +TLSv1.2 +TLSv1.3
Header always set Strict-Transport-Security "max-age=31536000"

The Header directive requires mod_headers to be enabled (a2enmod headers) if it isn't already — another module-enabling step specific to Apache's architecture that Nginx doesn't require for the equivalent functionality.

Common first-time mistakes to check for

• Forgetting to enable mod_ssl or mod_headers before referencing directives that depend on them, which produces a startup error rather than a silent failure
• Using SSLCertificateChainFile on a newer Apache version that expects the chain concatenated into SSLCertificateFile instead, or vice versa on an older version
• A VirtualHost with no matching Listen directive for its port, meaning Apache never in practice opens that port at all

What mod_ssl version differences mean for available configuration directives

Newer mod_ssl versions support additional directives and consolidated certificate file handling (a single SSLCertificateFile rather than requiring a separate SSLCertificateChainFile) — checking your specific Apache and mod_ssl version against current documentation avoids using outdated directive patterns from an older tutorial.

How to verify your certificate chain is complete before considering the install finished

Running `openssl s_client -connect yourdomain.com:443 -showcerts` after installation confirms your server presents the complete chain, your certificate followed by intermediates, rather than assuming installation succeeded just because the server started without errors.

Why keeping a tested, working configuration template speeds up future installations

Saving a working, tested configuration as a reference template for future sites means each subsequent installation starts from a known-good baseline rather than being written from scratch, reducing both setup time and the risk of reintroducing a previously-fixed mistake.

What separates a working configuration from a genuinely production-ready one

A working configuration successfully serves HTTPS; a production-ready one additionally includes OCSP stapling, a current, hardened cipher suite list, HSTS, and session caching — the difference between technically functional and in fact well-configured, which an SSL scan tool will clearly distinguish with its overall grade.

How to handle the transition period while DNS propagates for a brand new domain

For a brand new domain not yet resolving everywhere, testing your server configuration against its IP address (using curl's --resolve flag to simulate the eventual DNS) lets you verify everything works correctly before DNS has fully propagated, rather than waiting on propagation before starting any verification.

Why documenting your specific configuration choices helps whoever maintains this server next

Brief comments directly in your server configuration file explaining any non-default choices, why a specific cipher suite list was chosen, why a particular directive was added, save considerable time for whoever next needs to modify or troubleshoot the configuration, including a future version of yourself who's forgotten the original reasoning.

What a complete, annotated example configuration file looks like put together

Assembling every piece covered in this guide, the redirect block, the HTTPS server block with certificate paths, modern cipher configuration, OCSP stapling, and HSTS, into one complete, commented reference file gives you a single, tested starting point for any future server rather than reassembling the pieces from memory each time.

How to add basic rate limiting alongside your new HTTPS configuration for additional hardening

Basic request rate limiting, configured alongside your HTTPS setup, adds a meaningful layer of protection against brute-force login attempts or basic abuse — most web servers support this natively through built-in modules, worth adding as a complementary hardening step while you're already reviewing your server's security configuration.

Why testing configuration changes with apachectl configtest before every reload becomes second nature

Making a habit of running apachectl configtest before every single reload, not just when troubleshooting a suspected issue, catches a typo or syntax error before it can take down an otherwise working configuration — a small, consistent habit that prevents an entirely avoidable category of self-inflicted downtime.

What a quick closing checklist for a from-scratch Apache install looks like

Before considering the installation complete, confirm: the certificate and full chain are installed correctly, HTTP redirects to HTTPS with a 301, an SSL scan tool reports a strong grade, and OCSP stapling is confirmed active via a direct OpenSSL check.

Why building this from scratch once makes every future managed-platform shortcut easier to appreciate

Having manually configured every piece of a working HTTPS setup at least once gives you a genuine mental model for what a managed platform like Vercel or Cloudflare is doing automatically behind the scenes — a foundation that makes troubleshooting an issue on a managed platform considerably less mysterious when something does need attention.

What HTTP/2 configuration to add alongside your new HTTPS setup

Adding http2 to your listen directive (Nginx) or enabling mod_http2 (Apache) alongside your HTTPS configuration is a straightforward addition that provides a genuine performance benefit for multi-resource pages, a free upgrade once HTTPS is already correctly configured, since HTTP/2 requires HTTPS in every major browser.

How to handle a server also needing to support older TLS 1.0 clients temporarily

If you have specific, confirmed evidence some portion of your audience still requires TLS 1.0 or 1.1, Mozilla's SSL Configuration Generator offers an old compatibility preset explicitly for this scenario — worth treating as a deliberate, temporary compromise with a plan to remove it once the legacy client population is confirmed gone, not a permanent default.

Why a staged rollout, testing on a subdomain first, reduces risk for a critical server

Testing your complete configuration on a lower-stakes subdomain first, before applying identical settings to your primary domain, catches a configuration mistake in a context where it causes minimal disruption rather than affecting your most important, highest-traffic property immediately.