Automated SSL certificate renewal for Apache HTTP Server

Apache won't reload a new certificate on its own. CertKit will.

Apache serves whatever certificate is on disk at the paths your virtual hosts reference. When a certificate renews, nothing happens until someone writes the new files and reloads the server, every 47 days. On every Apache server in your fleet.

CertKit centralizes certificate issuance and renewal, then pushes updated certificates to your Apache servers automatically via the CertKit Agent.

Start free trial Watch demo

Built for Apache

The pre-built Apache deployment template ships in your CertKit account. No scripting required.

The CertKit Agent writes the certificate and key files to disk, validates the configuration with apachectl configtest, and reloads Apache gracefully. Existing connections finish, new ones get the new certificate, and a config problem stops the reload instead of taking the site down.

The pre-built Apache template ships with your CertKit account, and the agent's certificate inventory recognizes Apache and httpd configs it finds on the server. CertKit runs the deployment on every renewal.

How to install an SSL certificate on Apache

The manual process, if you want to do it yourself:

Get the renewed certificate and key. From your CA, or from an ACME client running somewhere with validation access. A wildcard SSL certificate works the same way: one chain, one key.
Build the full chain. Since Apache 2.4.8, SSLCertificateFile takes the leaf and intermediates in one file (SSLCertificateChainFile is deprecated). A missing intermediate works in your browser and fails on someone else's.
Write the files to the configured location. Wherever your virtual host's SSLCertificateFile and SSLCertificateKeyFile directives point. Every vhost that references the old files needs the update.
Test the configuration. Run apachectl configtest. A typo takes every site on the server down at reload instead of serving the new certificate.
Reload and verify. apachectl graceful on Linux, or restart the Apache service on Windows. Then confirm the served certificate actually changed, and repeat on every server.

Every one of these steps is manual, and Apache won't repeat any of them for you when the certificate renews. With lifetimes shrinking to 47 days, installation stops being an annual chore and becomes a recurring task: eight times a year, on every virtual host, on every server in the fleet. Miss one reload and it's an outage.

At 47 days, automation is the only sustainable way to run Apache certificates. Here's how CertKit does it.

How it works

 Your Apache server        CertKit                 ACME CA
┌───────────────────┐     ┌──────────────────┐    ┌─────────────┐
│                   │     │                  │    │             │
│     ┌───────────────┐   │  Issue & Renew   │◄──►│             │
│     │ CertKit Agent │◄──┤   Certificates   │    │             │
│     └─────────┬─┬───┘   │                ┌───┐  └─────────────┘
│               │ │ │     └───────────┬────│DNS│
│ Certificates ◄┘ │ │                 │    └───┘
│ [x] Updated     │ │                 │
│                 │ │                 │
│ Apache      ◄───┘ │ ◄───────────────┘
│ [x] Reloaded      │       Verify
└───────────────────┘

CertKit manages issuance and renewal centrally using delegated DNS validation. You create a one-time CNAME record; CertKit handles every ACME challenge after that. Your Apache servers do not run ACME, no open ports, no DNS credentials. They just run the agent.

Using CertKit to manage our public-facing SSL certificates has been an excellent decision. The platform is user-friendly, certificates are easy to deploy, and the automation agent streamlines the entire certificate lifecycle, eliminating concerns around shortening certificate validity periods.

Chris Austin, IT Engineer, Buckman

What CertKit handles

Issue certificates via ACME, centrally. Your Apache servers have no ACME configuration, no open ports, no credentials to manage. One CNAME record is all they contribute.
Renew automatically before expiry. That one-time CNAME covers every renewal challenge going forward. No intervention required on any server.
Write the cert and key to disk, chain included. The CertKit Agent writes the files where your SSLCertificateFile and SSLCertificateKeyFile directives point, on every renewal.
Validate before reloading. The deployment runs apachectl configtest first, so a configuration problem stops the deployment and raises an alert instead of taking every site on the server down.
Reload gracefully. apachectl graceful finishes in-flight requests while new connections get the renewed certificate. On Windows, the agent restarts the Apache service.
Verify the deployment, not just the script. After each renewal, CertKit connects to your server and confirms the new certificate is actually being served. It checks the serial number, SANs, and expiry. If something is wrong, you find out before your users do.
Alert on failure. Config test failures, reload errors, verification mismatches, and upcoming expirations all generate alerts before they become incidents.
Audit every change. Every issuance, renewal, and deployment is logged with timestamp, certificate, and server. With certificate lifetimes heading to 47 days, that log is your compliance record.

Setup takes about ten minutes

Connect your domain. Add a one-time CNAME record to delegate DNS validation to CertKit. Every renewal challenge after that is automatic.
Install the CertKit Agent. One command on your Apache server, Linux or Windows. The agent runs as a background service and needs no inbound firewall rules.
Add the Apache deployment script. The pre-built template is in your account. Set the file paths your vhosts reference and save. CertKit runs it on every renewal.

See the full architecture →

Why not certbot on every server?

Certbot's Apache plugin is a fine answer for one internet-facing server. It gets awkward at fleet scale: HTTP-01 needs port 80 open and reachable on every server, DNS-01 needs DNS provider credentials stored on each one, and certbot --apache edits your virtual host configuration to suit itself. When several servers share a certificate, per-server ACME has no distribution mechanism, and the usual workaround, a shared folder with coordinated reloads, fails silently when it breaks.

CertKit uses delegated DNS validation handled centrally, so no server needs port 80 open or DNS credentials on disk, and your vhost configs stay exactly as you wrote them. It issues once and the agent handles distribution. There is no per-server ACME configuration to manage and no shared folder to maintain.

Apache is just one part of your stack

Most infrastructures have more than one place where certificates live: the Tomcat instances behind Apache, nginx on the newer boxes, self-hosted apps like GitLab, and the load balancers out front. CertKit automates all of it from one account.

See all integrations

Start automating Apache certificates today

Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.

Start free trial See pricing