How to Configure Apache to Use a Purchased SSL Certificate

Abdul Wahab Junaid

3 years ago

How to configure Apache to use a purchased SSL certificate

Buying an SSL certificate from a Certificate Authority is the easy part — clicking through a checkout page takes five minutes. Actually getting Apache to serve it correctly is where I see people get stuck, usually around the CSR generation or the chain file. I’ve installed purchased certificates on more servers than I can count, so let me walk you through the entire process from start to finish.

Why Buy an SSL Certificate Instead of Using Let’s Encrypt?

Free certificates from Let’s Encrypt are excellent for most use cases, but I still recommend purchased certificates in certain situations:

Extended Validation (EV) or Organization Validation (OV) certificates, which display verified business identity information and are sometimes required by compliance or brand trust standards.
Longer validity periods offered by some commercial CAs compared to Let’s Encrypt’s 90-day certificates (though industry trends are pushing shorter lifespans across the board).
Warranty/insurance coverage some CAs bundle with commercial certificates.
Dedicated support from the CA for enterprise environments.

Prerequisites

Apache 2.4+ with mod_ssl enabled.
Root or sudo access to the server.
A registered domain with DNS pointing to your server.
An account with your chosen Certificate Authority (DigiCert, Sectigo, GoDaddy, GlobalSign, etc.).

Step 1: Generate a Private Key and CSR

Before purchasing, most CAs require a Certificate Signing Request (CSR), which I generate locally on the server (or securely transfer the resulting files if generated elsewhere):

openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr

I’m prompted for details:

Country Name (2 letter code):        US
State or Province Name:              California
Locality Name:                       San Francisco
Organization Name:                   Your Company Inc.
Organizational Unit Name:            IT Department
Common Name:                         yourdomain.com
Email Address:                       admin@yourdomain.com

The Common Name must exactly match the domain you’re securing. For a wildcard certificate, I use *.yourdomain.com.

I keep yourdomain.key private and secure — this never gets shared with the CA or anyone else. Only the .csr file gets submitted.

Step 2: Submit the CSR to Your Certificate Authority

I log into the CA’s portal, paste the contents of yourdomain.csr:

cat yourdomain.csr

And follow their purchase/validation flow. Validation methods typically include:

Email validation — a confirmation link sent to an admin address on the domain (e.g., admin@yourdomain.com).
DNS validation — adding a specific TXT record to your domain’s DNS.
HTTP validation — uploading a specific file to your web root that the CA checks for.

I usually pick DNS or HTTP validation since they don’t depend on a specific mailbox existing.

Step 3: Download the Issued Certificate

Once validated and issued, the CA provides:

Your primary/server certificate (e.g., yourdomain.crt)
One or more intermediate certificates (e.g., intermediate.crt or a ca-bundle.crt)

Step 4: Build the Full Certificate Chain

I combine the server certificate with the intermediate(s), in the correct order (server cert first, intermediates after, root excluded):

cat yourdomain.crt intermediate.crt > yourdomain-fullchain.crt

For more detail on getting chain order right, I have a dedicated guide on setting up SSL certificate chain files — it’s worth a look if you hit trust warnings after installation.

Step 5: Move Files to Their Proper Locations

sudo mkdir -p /etc/ssl/private
sudo cp yourdomain-fullchain.crt /etc/ssl/certs/
sudo cp yourdomain.key /etc/ssl/private/
sudo chmod 600 /etc/ssl/private/yourdomain.key
sudo chown root:root /etc/ssl/private/yourdomain.key

Step 6: Configure the Apache Virtual Host

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

    SSLEngine on
    SSLCertificateFile    /etc/ssl/certs/yourdomain-fullchain.crt
    SSLCertificateKeyFile /etc/ssl/private/yourdomain.key

    <Directory /var/www/yourdomain>
        Options -Indexes
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

I also set up a redirect from HTTP to HTTPS so visitors aren’t left on an unencrypted connection:

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

Step 7: Enable Required Modules and the Site

sudo a2enmod ssl
sudo a2ensite yourdomain.conf
sudo apachectl configtest
sudo systemctl reload apache2

Step 8: Harden the SSL Configuration

Since I’m already touching the SSL config, I take the opportunity to add solid baseline hardening:

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder     on
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

I cover deeper hardening (weak cipher removal, Perfect Forward Secrecy, OCSP stapling) in their own dedicated guides, since each deserves a proper treatment.

Step 9: Verify the Installation

I confirm the certificate and key match:

openssl x509 -noout -modulus -in /etc/ssl/certs/yourdomain-fullchain.crt | openssl md5
openssl rsa -noout -modulus -in /etc/ssl/private/yourdomain.key | openssl md5

Both hashes should be identical.

Then I check the live server response:

curl -vI https://yourdomain.com

And run an external test via SSL Labs for independent confirmation that the certificate, chain, and configuration are all correct.

Choosing the Right Certificate Type Before You Buy

Before generating a CSR, I make sure I’ve picked the right certificate type for the situation, since this affects both the CSR details and the validation process:

Domain Validated (DV) — fastest to issue, confirms only domain ownership. Fine for most personal and small business sites.
Organization Validated (OV) — confirms domain ownership plus verified business details, taking a bit longer to issue.
Extended Validation (EV) — the most rigorous vetting process, historically used to display a company name prominently in some browser UIs (though most browsers have scaled back visual EV indicators in recent years).
Single-domain vs. wildcard vs. multi-domain (SAN) — single-domain covers exactly one hostname, wildcard covers all first-level subdomains of a domain, and SAN/multi-domain certificates cover an explicit list of distinct hostnames.

Getting this decision right before purchasing saves the hassle of reissuing or exchanging a certificate later if it turns out not to cover the domains you actually needed.

Common Mistakes I See

Losing the private key generated during CSR creation — if this happens, there’s no way to recover it; you have to generate a new CSR and go through validation again.
Submitting the wrong CSR — always double-check the Common Name matches exactly, including www vs. non-www if that distinction matters for your setup.
Forgetting the intermediate certificate, leading to inconsistent trust warnings depending on the browser.
Not redirecting HTTP to HTTPS, leaving visitors able to accidentally stay on an unencrypted connection.
Mismatched file permissions on the private key, which some security scanners flag even if functionally the site still works.

Security Best Practices

Never transmit your private key over email or unencrypted channels — generate it directly on the server, or transfer it via a secure method (SCP/SFTP with key-based auth) if generated elsewhere.
Set strict permissions on the private key file (chmod 600, owned by root).
Enable HSTS to prevent downgrade attacks once you’re confident HTTPS is fully working sitewide.
Set a renewal reminder well before the certificate’s expiration date — commercial certificates don’t auto-renew like Let’s Encrypt does unless you’ve specifically set up auto-renewal with your CA.

Performance Optimization Tips

Enable OCSP stapling to speed up certificate validation for visitors (see my dedicated guide).
Use HTTP/2, which requires HTTPS and offers substantial performance benefits once your certificate is properly configured:

Protocols h2 http/1.1

Keep your certificate chain as short and clean as possible to minimize handshake overhead.

Troubleshooting

Problem: “SSL certificate problem: unable to get local issuer certificate” Missing or incorrectly ordered intermediate certificate. Rebuild your fullchain file with the correct order.

Problem: Apache won’t start after installing the certificate Run apachectl configtest for the specific error — commonly a path typo or a key/certificate mismatch.

Problem: Browser shows the certificate as valid, but curl fails Browsers sometimes cache intermediates from other sites. Rely on curl or openssl s_client for a true test of your server’s own configuration.

FAQs

How long does it take to get a purchased SSL certificate issued? Domain-validated certificates are often issued within minutes to a few hours. Organization- or Extended-Validation certificates can take one to several business days due to manual verification.

Can I reuse my private key when renewing a purchased certificate? Technically yes, but I generally recommend generating a fresh key pair at renewal time for better security hygiene.

Do I need to buy a new certificate for each subdomain? Not necessarily — a wildcard certificate covers all first-level subdomains of a domain, or a SAN certificate can cover multiple specific domains/subdomains under one certificate.

Summary and Key Takeaways

Installing a purchased SSL certificate in Apache comes down to generating a proper CSR, completing CA validation, correctly assembling the certificate chain, and configuring your virtual host with the right paths. Getting each step right the first time avoids the inconsistent trust warnings and downtime that come from a rushed installation.

Key takeaways:

Generate your CSR directly on the server so the private key never has to be transferred.
Always combine the server certificate with the CA’s intermediate certificate(s) in the correct order.
Verify the private key and certificate match before considering the install complete.
Set up an HTTP-to-HTTPS redirect and basic TLS hardening as part of the same deployment.