Automated SSL certificate renewal for Apache Tomcat

Tomcat won't pick up a renewed certificate on its own. CertKit will.

Tomcat loads its TLS certificate from the keystore referenced by the HTTPS connector in server.xml, read once at startup. When a certificate renews, the keystore on disk is stale and Tomcat keeps serving the old certificate until someone rebuilds the keystore and restarts the service. Every 47 days. On every Tomcat instance you run.

CertKit centralizes certificate issuance and renewal, then writes the updated Java KeyStore to the path Tomcat already reads and restarts the service automatically via the CertKit Agent.

Start free trial Watch demo

Built for Tomcat

The pre-built Java KeyStore template and restart script ship in your CertKit account. No keytool required.

The CertKit Agent writes the renewed certificate, private key, and intermediate chain into a Java KeyStore at the path you set, under the alias and password your connector expects, then restarts the Tomcat service so it loads the new certificate.

You point the HTTPS connector at that keystore file once in server.xml. After that, CertKit overwrites the same file on every renewal and restarts the service. There is nothing to reconfigure in Tomcat again.

How to install an SSL certificate on Tomcat

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

Get the renewed certificate, private key, and chain. Skip the keytool -genkey tutorials. That path makes a self-signed certificate every browser warns about. You want one from a trusted CA.
Package it as a keystore. Bundle the certificate, key, and intermediates into a PKCS12 with openssl, then keytool -importkeystore it into the keystore Tomcat reads. The alias and passwords have to match what the connector expects, and the error messages when they don't are famously unhelpful.
Reference it in server.xml. The HTTPS connector's certificateKeystoreFile in the SSLHostConfig block on Tomcat 8.5 and later, or keystoreFile on older versions.
Restart Tomcat. The keystore is read at startup, so the old certificate stays live until the restart lands.
Verify. Confirm the connector serves the new certificate, then repeat on every Tomcat instance behind every hostname.

Every one of these steps is manual, and Tomcat 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 instance. Miss one and the application behind it starts throwing certificate errors.

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

How it works

 Your Tomcat server        CertKit                 ACME CA
┌───────────────────┐     ┌──────────────────┐    ┌─────────────┐
│                   │     │                  │    │             │
│     ┌───────────────┐   │  Issue & Renew   │◄──►│             │
│     │ CertKit Agent │◄──┤   Certificates   │    │             │
│     └─────────┬─┬───┘   │                ┌───┐  └─────────────┘
│               │ │ │     └───────────┬────│DNS│
│ .jks file  ◄──┘ │ │                 │    └───┘
│ [x] Written     │ │                 │
│                 │ │                 │
│ Tomcat      ◄───┘ │ ◄───────────────┘
│ [x] Restarted     │       Verify
└───────────────────┘

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

CertKit makes what many companies struggle with much easier to manage while at the same time providing great value compared to the traditional vendors in the space.

Ben Story, Managed Services Director, RedEye Network Solutions

What CertKit handles

Issue certificates via ACME, centrally. Your Tomcat 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 a complete Java KeyStore. The CertKit Agent builds the keystore with the certificate, its private key, and the full intermediate chain, under the alias and password you set, at the path the connector reads. No keytool, no PKCS12 conversion step.
Restart Tomcat to load the new certificate. The deployment script restarts the Tomcat service, on Windows or Linux, so the renewed certificate is live before the renewal is marked complete.
Deploy in a window you control. The restart briefly interrupts the applications Tomcat hosts. Schedule a deployment window per server so renewals land at 2am Sunday, not during business hours.
Verify the deployment, not just the script. After each renewal, CertKit connects to your Tomcat TLS listener 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. Keystore write failures, restart 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 Tomcat server, Linux or Windows. The agent runs as a background service and needs no inbound firewall rules.
Add the Java KeyStore deployment script. Pick the Java KeyStore template, set the keystore path, password, alias, and the Tomcat service to restart. CertKit runs it on every renewal.
Point the connector at the keystore once. In server.xml, set the HTTPS connector's keystore to the file CertKit writes. This is the only change you make inside Tomcat, and you only make it once.

See the full architecture →

Why not script keytool yourself?

The usual DIY chain is an ACME client fetching PEM files, an openssl conversion to PKCS12, a keytool -importkeystore into the live keystore, and a service restart, wired together with cron. Every link has a failure mode: keystore and key passwords drifting apart, the alias not matching the connector, JKS versus PKCS12 confusion between Tomcat versions, and a chain that breaks silently until the certificate expires. And Java has no native ACME story, so the ACME client itself needs port 80 open or DNS credentials on the server.

CertKit issues the certificate centrally via delegated DNS validation, then the agent writes the keystore and restarts the service as one verified step, with no ACME client on the server and no keytool to run by hand.

Tomcat is just one part of your stack

Most environments have more than one place where TLS certificates live: Apache or nginx in front of Tomcat, and other keystore-based servers like CrushFTP. CertKit automates all of it from one account.

See all integrations

Start automating Tomcat 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