nginx serves whatever certificate is on disk. When a certificate renews, nothing happens automatically. You need to write the new files and reload the service, every 47 days. Running and possibly-failing on every server in your fleet.
CertKit centralizes certificate issuance and renewal, then pushes updated certificates to your nginx servers automatically via the CertKit Agent.
The pre-built nginx deployment template ships in your CertKit account. No scripting required.
The CertKit Agent writes the certificate and key files to disk automatically. Your deployment script handles one thing: telling nginx to reload. That is the entire integration.
The pre-built nginx template ships with your CertKit account. CertKit runs it on every renewal. No paths to manage. No hooks to wire up. No logs to watch.
The manual process, if you want to do it yourself:
ssl_certificate and ssl_certificate_key, with permissions
the worker can read.
nginx -t to validate the SSL configuration. A typo here takes the
site down on reload instead of serving the new certificate.
systemctl reload nginx, then confirm the served certificate actually
changed. nginx keeps serving the old one from memory until the reload lands.
Every one of these steps is manual, and nginx 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 server in the fleet. Miss one reload and it's an outage.
At 47 days, automation is the only sustainable way to run nginx certificates. Here's how CertKit does it.
Your nginx server CertKit ACME CA ┌───────────────────┐ ┌──────────────────┐ ┌─────────────┐ │ │ │ │ │ │ │ ┌───────────────┐ │ Issue & Renew │◄──►│ │ │ │ CertKit Agent │◄──┤ Certificates │ │ │ │ └─────────┬─┬───┘ │ ┌───┐ └─────────────┘ │ │ │ │ └───────────┬────│DNS│ │ Certificates ◄┘ │ │ │ └───┘ │ [x] Updated │ │ │ │ │ │ │ │ nginx ◄───┘ │ ◄───────────────┘ │ [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 nginx 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
Per-server ACME clients like Certbot require each server to prove domain ownership on every renewal. HTTP-01 validation requires port 80 open and reachable from the internet on every server. DNS-01 validation requires DNS provider credentials stored on the server itself. Neither is a good option in hardened or private environments, and both expose more attack surface than the certificate is worth.
When multiple nginx instances share a certificate, per-server ACME has no distribution mechanism. The common workaround is a shared folder with coordinated reload commands across servers. That shared folder is a dependency, and when it breaks, certificates stop renewing silently.
CertKit uses delegated DNS validation handled centrally, so no server needs port 80 open or DNS credentials on disk. It issues once and the agent handles distribution. There is no per-server ACME configuration to manage and no shared folder to maintain.
Most infrastructures have more than one place where certificates live: the Apache and Tomcat servers beside it, the GitLab instance with its bundled nginx, the FileZilla and CrushFTP servers moving files, and the load balancers out front. CertKit automates all of it from one account.
Free 90-day trial. No credit card required. Direct access to our engineering team to get you set up.