This post covers how to automate renewal for Java apps: first check whether the app loads the certificate at all, then the Tomcat and Spring Boot settings that matter, the three errors that most often break a certificate swap, and two ways to automate the whole thing: a Certbot hook you maintain yourself, or LapseZero as a hosted service.

Check where HTTPS terminates

Many Java apps sit behind Nginx, HAProxy or a cloud load balancer that handles TLS, while Tomcat listens on plain HTTP on port 8080. In that setup the certificate has nothing to do with Java. Renew it the way you would for Nginx or the load balancer and skip the keystore work.

To check: in Tomcat, look for a Connector with an SSLHostConfig in conf/server.xml. In Spring Boot, look for server.ssl in application.yml, application.properties or the startup arguments. If neither is there, the Java app usually doesn't load a certificate. The rest of this post assumes it does.

Tomcat

Since Tomcat 8.5 (including 9, 10 and 11), TLS settings go in an SSLHostConfig inside the Connector:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" SSLEnabled="true">
  <SSLHostConfig>
    <Certificate certificateKeystoreFile="/opt/tomcat/ssl/tomcat.p12"
                 certificateKeystorePassword="changeit"
                 certificateKeystoreType="PKCS12" />
  </SSLHostConfig>
</Connector>

For automation, four attributes on Certificate matter:

• certificateKeystoreFile is where the renewed keystore has to be written.
• certificateKeystorePassword has to match the password the new keystore is built with.
• certificateKeystoreType defaults to JKS when omitted. Use PKCS12 and set it explicitly.
• certificateKeyAlias is left out above. Without it, Tomcat uses the first key it reads from the keystore, which is the simplest option when the keystore holds a single certificate.

You can also skip keystores. Tomcat 8.5 and later read PEM files directly through certificateFile, certificateKeyFile and certificateChainFile. There is no need to switch an existing keystore setup to PEM just to automate it; both work.

Once the file is replaced, Tomcat has to load it. A restart is the simplest way, and HTTPS is down while it runs: on a small test VM, a normal Tomcat 10.1 restart took HTTPS offline for about 7 seconds. To avoid the gap, the Manager app has an sslReload command that re-reads the certificate and key files without re-parsing server.xml:

curl -fsS -u deployer:password "http://localhost:8080/manager/text/sslReload" | grep -q '^OK'

This needs the Manager app deployed and a user with the manager-script role. When the reload fails, Manager answers with text starting with FAIL and curl still exits 0, so the grep is what turns a failed reload into a non-zero exit code.

Spring Boot

Spring Boot runs an embedded Tomcat and reads the certificate from its own configuration:

server:
  port: 8443
  ssl:
    key-store: file:/opt/app/ssl/app.p12
    key-store-type: PKCS12
    key-store-password: changeit

This works the same in Spring Boot 2.7 and 3.x. Watch the file: prefix. A lot of tutorials use classpath:keystore.p12, which bundles the keystore into the jar. Then a new certificate means a new build and a new release, and nothing on the server can replace it. Move the keystore out of the jar and point key-store at an absolute file: path before automating anything.

Spring Boot also accepts PEM files: server.ssl.certificate for the chain and server.ssl.certificate-private-key for the key.

From Spring Boot 3.2 you can swap certificates without a restart. Define the certificate as an SSL bundle with reload-on-update enabled and Spring Boot watches the files in the background, reloading them when they change:

spring:
  ssl:
    bundle:
      jks:
        web:
          reload-on-update: true
          keystore:
            location: file:/opt/app/ssl/app.p12
            password: changeit
            type: PKCS12
server:
  ssl:
    bundle: web

The bundle type is called jks, but it holds PKCS12 files too; type decides. server.ssl.bundle can't be combined with server.ssl.key-store and the other keystore properties, so remove those when you switch. On versions before 3.2, a restart is the only option. Spring Boot also starts slower than plain Tomcat: on the same test VM, a minimal Spring Boot 3.5 app was unreachable over HTTPS for about 15 seconds during a restart, and real applications usually take longer.

Three errors that break a certificate swap

The alias doesn't match

Many Tomcat guides create the keystore with keytool -alias tomcat and set certificateKeyAlias="tomcat" (or server.ssl.key-alias: tomcat in Spring Boot). Build the renewed keystore with a different tool and the alias may change. On the next start the app fails with:

java.io.IOException: Alias name [tomcat] does not identify a key entry

You won't see this while the app is running, because it keeps the old certificate in memory. It shows up on the first restart after renewal, when the app refuses to start. Either build the new keystore with the same alias (openssl pkcs12 -export -name tomcat), or, if the keystore only ever holds one certificate, remove the alias from the config.

The password doesn't match

The new keystore's password has to equal certificateKeystorePassword or server.ssl.key-store-password. Otherwise startup fails with:

Failed PKCS12 integrity checking

A JKS file from a CA or cloud console sometimes has a key password that differs from the keystore password, which shows up as certificateKeyPassword in Tomcat or server.ssl.key-password in Spring Boot. In a generated PKCS12 file both passwords are the same, so remove that setting or set it to the keystore password.

The restart succeeds and the app is down

This is the one that slips through. Most systemd units for Java apps use Type=simple, where systemctl restart returns as soon as the process starts, long before Java loads the certificate. With a wrong alias or password, systemctl restart still exits with 0. Tomcat keeps running without its HTTPS connector; Spring Boot exits a few seconds later. Your deploy script sees a successful command and moves on while the service is down.

So the restart step should only succeed once HTTPS actually answers, and fail otherwise:

#!/bin/sh
# Usage: restart-and-wait.sh <service> <https-port>
set -eu
systemctl restart "$1"
for attempt in $(seq 1 30); do
  if curl --insecure --fail --silent --max-time 1 "https://127.0.0.1:$2/" >/dev/null; then
    exit 0
  fi
  sleep 1
done
echo "$1 did not become HTTPS-ready" >&2
exit 1

--insecure is only there because this is a local liveness check. Replace / with a path in your app that returns 200 without a login.

The first time you automate this, also check file permissions. The Java process usually runs as a non-root user, and it has to be able to read the newly written keystore.

Doing it yourself with a Certbot deploy hook

If Certbot issues the certificate on the same server, put the conversion, the swap and the restart in a deploy hook. Certbot runs it after each successful renewal and passes the certificate directory in RENEWED_LINEAGE:

#!/bin/sh
set -eu
openssl pkcs12 -export \
  -in "$RENEWED_LINEAGE/fullchain.pem" \
  -inkey "$RENEWED_LINEAGE/privkey.pem" \
  -name tomcat -passout file:/etc/tomcat/keystore.pass \
  -out /opt/tomcat/ssl/tomcat.p12.new
mv /opt/tomcat/ssl/tomcat.p12.new /opt/tomcat/ssl/tomcat.p12
/usr/local/bin/restart-and-wait.sh tomcat 8443

acme.sh doesn't set RENEWED_LINEAGE. Use --install-cert to choose where the full chain and private key are written, point the script at those paths, and run it through --reloadcmd.

For one app on one server, that's enough. With more servers and apps, a few things are left to you:

• Recovery: if the restart fails, the old keystore has already been overwritten. Keep a backup and restore it on failure, or the app stays down until someone fixes it.
• Distribution: the renewed certificate only exists on the machine where Certbot runs. For several servers you either run Certbot and the hook on each one, or copy the certificate over and run the same steps everywhere.
• Alerts: Certbot doesn't notify anyone by default. A failed hook only shows up in its log, so nobody knows unless someone reads it.

Deploying to Java apps with LapseZero

LapseZero is a hosted service that issues certificates, renews them before they expire and deploys them to servers and cloud services. The certificates are free DV certificates with wildcard support, validated over DNS with either a DNS provider API key or a single CNAME record. Nothing needs to be migrated: the first deployment writes the new certificate to your existing keystore path.

A Java server is set up once. Add a deployment target, choose Server, pick Tomcat or Spring Boot, and fill in three fields:

• Certificate Path: the keystore path from your config, without the file: prefix for Spring Boot.
• Keystore Password: the same password as in your config. If your config sets a key alias, enter that alias too.
• Post-deploy Command: the restart-and-wait.sh script above.

LapseZero connects over SSH or through a deployment agent that needs no inbound port. Private keys and passwords are stored encrypted.

From then on, every renewal builds a new PKCS12 file, writes it to the same path and runs your command, and the three errors above stop being your problem. The keystore is built with your password and alias, so they match. If the command fails, for example because the app isn't serving HTTPS within 30 seconds, LapseZero puts the old keystore back and runs the command again, so the app keeps the old certificate and the notification tells you it was rolled back. Add the app's HTTPS address under Live check and each deployment also confirms the new certificate is actually being served.

For an app on several servers, add one deployment target per server with the same settings. The Nginx, load balancer or cloud services in front of it get the same certificate from the same place, with no hook script to maintain on every machine.

The free plan covers 3 domains and 5 deployment targets with no time limit, enough to try it on one or two servers. One domain on six servers is past the free plan; Starter is $3/month for 10 domains and 20 deployment targets.

People who look for a Certbot alternative usually have more than one place to put the certificate: a second and third server, a CDN in front of the site, a load balancer that needs the certificate too, and a folder of deploy hooks that only one person understands.

This post compares Certbot, other self-hosted ACME clients and LapseZero on that case: which servers and cloud products each can deploy to, who maintains the deploy scripts, and how you find out a deployment failed. The last part covers moving from Certbot.

When Certbot is enough

Certbot is the right tool when:

• the certificate is used on one server;
• the Nginx or Apache plugin installs it and reloads the web server;
• nothing else (CDN, load balancer, another machine) needs a copy.

In that setup there is nothing to fix. Check that the renewal timer is active (systemctl list-timers on most distributions) and run certbot renew --dry-run once in a while. Moving to anything else adds a moving part without removing one.

Other self-hosted ACME clients

If you want to stay self-hosted but prefer a different style, these are the usual alternatives:

• acme.sh: a pure shell script, no Python, with a large set of DNS API integrations and deploy hooks.
• lego: a single Go binary, convenient in containers and CI.
• Caddy: a web server that obtains and renews certificates by itself, so there is no separate client at all.
• cert-manager: the standard choice inside Kubernetes.

Let's Encrypt keeps a longer list of ACME clients in its docs. For a broader comparison of scripts, self-hosted panels and hosted services, see my earlier post on choosing an SSL certificate automation tool.

acme.sh also ships deploy hooks for remote servers over SSH and for some cloud services. If those cover your targets and you are fine maintaining the setup yourself, it is a reasonable choice. The other clients, like Certbot, leave deployment beyond their own machine or cluster to you.

Deploying with Certbot hooks

Certbot can deploy beyond the local web server. --deploy-hook runs a command after each successful renewal, and that command can copy files to other servers or call a cloud API. Plenty of teams do exactly this.

The cost shows up later:

• every new server or cloud product means another hook to write and test;
• a hook that fails quietly leaves a server serving the old certificate while Certbot reports a successful renewal;
• if a hook fails halfway, putting the old files back is up to the hook;
• seeing which targets already have the new certificate means building that reporting yourself.

If that list sounds familiar, a hosted service that deploys as well as renews is a better fit.

LapseZero

LapseZero is a hosted service that issues SSL certificates, renews them, and deploys them to servers and cloud products. It also monitors HTTPS endpoints, including ones it does not deploy to.

How it covers the gaps above:

• Validation without a DNS key. Certificates are issued over DNS-01, wildcards included. You either give LapseZero a DNS API key or add one CNAME record once and keep your DNS credentials to yourself.
• Automatic renewal. A certificate is renewed when less than a third of its validity is left, about 30 days before expiry for a 90-day certificate.
• Servers. Over SSH, or through an open-source agent (lapsezero-agent on GitHub) that connects out over HTTPS, so you open no port and the platform stores no SSH key. 1Panel and Nginx Proxy Manager also work through the agent.
• Cloud products. AWS: CloudFront, ALB, NLB, API Gateway, ACM and Amplify. Google Cloud: Certificate Manager. Azure: Key Vault. Plus CDN, load balancer and storage products from Alibaba Cloud, Tencent Cloud, Huawei Cloud and others.
• Safe server updates. Files are replaced all or nothing. If writing a file or reloading fails, the previous certificate is put back and the notification says so.
• Status per target. Each target has its own record, and failures go out by email, Slack, Telegram or webhook. An optional check connects to the public HTTPS address and compares the certificate fingerprint. On agent targets it can also check on the server itself, which matters when a CDN sits in front: the CDN serving the new certificate says nothing about the origin behind it.

If one certificate has to reach several servers, a CDN or a load balancer, LapseZero is the better fit. It takes over issuance and renewal as well, so you cannot keep Certbot issuing and use LapseZero only to distribute.

Certbot and LapseZero side by side

What LapseZero stores, and how to leave

Moving a production certificate to a hosted service means trusting it with keys and access to your servers.

Private keys. LapseZero generates the key when it issues the certificate. Keys and certificates, along with DNS, cloud and SSH credentials, are stored encrypted with AES-256-GCM, and saved credentials are never shown again in the console or API. You can download any issued certificate with its key from the console. The security page on the LapseZero site lists what each feature needs.

Cloud permissions. When you add a cloud account, the console gives you a policy to paste into the provider's IAM console, limited to the certificate and resource actions LapseZero calls. You do not have to hand over an admin key.

The agent. It runs as root as a systemd service, because it writes certificate files and runs your reload command. The reload command is the one you configure, such as systemctl reload nginx. lapsezero-agent uninstall removes it.

Failures. A deployment that fails because a server is unreachable is retried automatically for a few minutes. If the server stays offline longer than that, the deployment is marked failed, you get a notification, and you retry it from the console once the server is back.

Leaving. The certificate files stay at the same paths on your server, so Nginx keeps working whether LapseZero is there or not. To go back to Certbot, move the renewal config you set aside back to /etc/letsencrypt/renewal/ and run certbot renew --cert-name example.com --force-renewal.

Moving from Certbot without breaking anything

The agent knows what a Certbot setup looks like, so you do not have to rebuild your Nginx config.

1. List your deploy hooks. Note which certificates have hooks that copy them to other servers or cloud products. Those destinations become deployment targets in LapseZero, and the hooks go away at the end.
2. Install the agent on the server with the one-line command from the console.
3. Scan the server. The agent runs nginx -T, which only reads the config, and lists each server block with its certificate paths. Paths under /etc/letsencrypt/live/ are marked as managed by Certbot. The scan does not read private key contents.
4. Take over the sites you want. LapseZero creates a deployment target that writes to the same paths and runs the same reload command. Nothing is deployed at this step.
5. Issue the certificate if LapseZero does not have one for the domain yet. It is deployed to the new target, and to any cloud targets you added, through the normal flow.
6. Check the result. Each target should show a successful deployment, and the live check should see the new fingerprint, both on the public address and on the server.
7. Stop Certbot renewing that certificate, and only that one: move /etc/letsencrypt/renewal/example.com.conf somewhere outside that directory. LapseZero reminds you but does not do this for you, and if both keep running they overwrite each other's files. Do not use certbot delete, which removes the files Nginx points to. Then remove the hooks from step 1.

Doing step 7 after step 6 means there is never a moment when nothing renews the certificate.

One case needs a small change first. LapseZero issues one certificate per domain you add: a single name (a root domain can include www), or a wildcard such as *.example.com, which also covers example.com. A server block that serves example.com and example.org together, or a.example.com and b.c.example.com, cannot be covered by one of those certificates, so split it into separate server blocks before taking it over.

Pricing

The free plan covers 3 domains, 5 deployment targets and 5 monitors, with no time limit. One domain deployed to two servers, a CDN and a load balancer uses four of the five targets. Paid plans start at $3/month (Starter: 10 domains, 20 targets); Pro is $8/month for 30 domains and 80 targets, and Team is $20/month for 100 domains and 200 targets. Yearly billing costs ten months' worth.

example.com
├── www.example.com
├── app.example.com
├── api.example.com
├── admin.example.com
└── docs.example.com

Each service needs HTTPS.

You can manage a separate certificate for every subdomain, but depending on your infrastructure, a wildcard SSL certificate may be a more convenient choice.

This guide covers wildcard matching, DNS validation, and the trade-offs of sharing a certificate across services.

1. Why Wildcard Certificates Are Useful

A standard certificate typically covers one or more explicitly listed hostnames.

A wildcard certificate uses an asterisk to match a single subdomain level.

For example:

*.example.com

matches:

app.example.com
api.example.com
admin.example.com
docs.example.com

That means you can deploy the same certificate to several services instead of requesting a separate certificate for each hostname.

There are two common misconceptions worth clearing up.

A wildcard doesn't automatically cover the root domain.

*.example.com and example.com are different names. If you need both, the certificate must include both.

A wildcard doesn't match every possible depth.

*.example.com does not cover api.dev.example.com.

For that hostname, you'd need explicit coverage or a wildcard such as *.dev.example.com.

2. You Don't Need a Running Web Server to Get a Certificate

One of the more useful aspects of wildcard certificates is their DNS-based validation process.

Instead of proving domain ownership by serving a file from your web server, you add a DNS record.

The validation system checks whether the expected TXT record exists for your domain.

For example:

_acme-challenge.example.com

This offers some practical advantages:

• Your web application doesn't need to be running.
• You don't need to expose port 80 for validation.
• Validation isn't dependent on your reverse proxy configuration.
• You can request certificates before deploying your application.

This is useful when you're preparing a staging environment, building infrastructure from scratch, or working with services behind a CDN.

3. Request a Free Wildcard Certificate from Your Browser

If you only need a certificate occasionally, setting up a full certificate automation environment may be unnecessary.

There's a browser-based option available at:

https://lapsezero.com/tools/free-ssl-certificate?utm_source=hashnode&utm_medium=community&utm_campaign=free-wildcard-ssl

The process is straightforward.

First, select the wildcard certificate option.

Enter your domain, such as example.com.

The tool includes both *.example.com and the root domain by default.

Next, complete DNS verification.

The page displays the TXT records needed to prove control of your domain. When both names are included, add both values as separate TXT records with the same name, then continue after they become available.

You can check the record using:

dig TXT _acme-challenge.example.com

Finally, download the certificate.

Once issuance succeeds, download the certificate and matching private key in the format appropriate for your server.

The tool doesn't require account registration or server-side installation.

The screenshots use my test domain ssl-guide.hxkit.com; replace it with your own domain.

4. Where Should the Private Key Be Generated?

This is worth thinking about whenever you use an online certificate tool.

TLS certificates rely on public-key cryptography.

The server needs a private key that matches the public key associated with its certificate.

If a third-party service generates and stores your private key, you need to trust that service's handling of sensitive cryptographic material.

A safer design for a browser-based certificate tool is to generate the key locally and only transmit the information required for certificate issuance.

That's the approach used by LapseZero's free certificate request tool.

The private key is generated in the browser and isn't uploaded to LapseZero.

This reduces private-key exposure during the request process.

Of course, local key generation isn't a substitute for securing your device, browser, downloaded files, or production infrastructure.

5. One Certificate Across Multiple Servers: Is That Always a Good Idea?

Not necessarily.

Suppose your services run on different machines:

Server A → app.example.com
Server B → api.example.com
Server C → docs.example.com

You could install the same wildcard certificate and private key on all three servers.

Functionally, that works.

But there's a security trade-off.

If one server is compromised and its private key is stolen, the attacker may be able to use that key with the shared certificate for any covered hostname, subject to control of the corresponding traffic or endpoint.

For a small personal project, sharing a wildcard certificate might be a reasonable trade-off.

For environments with stricter isolation requirements, separate certificates and private keys may be preferable.

6. Certificate Issuance Is Only Half the Problem

There's a difference between getting HTTPS working today and keeping it working reliably.

The certificate issued for this walkthrough is valid for about 90 days. Check the expiry date on your own certificate.

That means you need a renewal strategy.

For a single site, manually replacing the certificate might be manageable.

For multiple servers, CDNs, and cloud load balancers, renewal involves more than requesting a new certificate.

You also need to:

1. Obtain a replacement certificate before expiry.
2. Distribute it to the correct deployment targets.
3. Reload or update the relevant services.
4. Verify that the new certificate is actually being served.
5. Monitor for failures.

This is where automated certificate management becomes valuable.

If you already have Certbot, acme.sh, or your own deployment scripts working reliably, you may not need another tool.

But for teams managing certificates across multiple environments, combining issuance, deployment, and monitoring into one workflow can reduce operational work.

7. Choosing the Right Approach

Here's how I'd think about it.

I built the free browser-based certificate request tool as part of LapseZero, a project focused on simplifying SSL certificate issuance, renewal, deployment, and monitoring.

The free tool works without an account:

https://lapsezero.com/tools/free-ssl-certificate?utm_source=hashnode&utm_medium=community&utm_campaign=free-wildcard-ssl

If you're managing multiple subdomains, I'd be curious to know how you're currently handling certificate renewal and deployment.

Do you use wildcard certificates, individual certificates, or a fully automated setup?

When one certificate serves several listeners, it is easy to miss one listener or an additional domain binding. Here is where to update certificates on CLB and ALB, and how to automate those updates after renewal.

CLB: Check the Default Certificate and Extended Domains

Open the CLB instance's listener list, find the HTTPS listener, and use Manage Certificates to select the new default certificate.

Extended domains have their own certificate bindings. Updating only the default certificate may leave those domains serving the old one.

If several listeners or extended domains reference the same old certificate, Certificate Management → Replace Certificate can update its associated resources together. Check the affected resources before proceeding and schedule the replacement during a quiet period.

For example, a domain might be served by load balancers in both Shanghai and Singapore. Updating the Shanghai listener leaves Singapore unchanged. Check the instance, region, and listener port as well as the domain.

ALB: Update the Binding for the Right Domain

Prepare the certificate in Certificate Management Service, then open the ALB instance's listener list and choose Manage Certificates → Server Certificates. You can replace the default certificate or add an additional certificate there.

Suppose www.example.com uses the default certificate and api.example.net uses an additional certificate. Update the API's binding while preserving the website's certificate. Verify that the new certificate is live before removing the old binding, rather than replacing the listener's entire certificate list.

For listeners managed by Kubernetes ALB Ingress, update certificates through the cluster's configuration.

Automating Renewal and Deployment for Free Certificates

Alibaba Cloud offers hosting for paid certificates, with automatic renewal and deployment. If you already use it, keep doing so. Free personal test certificates last about three months and do not support hosting; you need to request and deploy replacements.

To keep using free certificates without replacing each listener's certificate by hand, you can use LapseZero. It issues and renews certificates through Let's Encrypt, then deploys them to connected targets such as CLB, ALB, CDN, and Nginx. This does not use Alibaba Cloud's free certificate quota or require deployment scripts.

Setup involves three tasks:

1. Add your domain and configure the CNAME records shown for DNS delegation. Future renewals reuse those records.
2. Connect an Alibaba Cloud RAM user and follow the console guide to grant deployment permissions. DNS write access is not required.
3. Select the HTTPS listeners to update and request the first certificate.

Future renewals deploy automatically to those listeners. If the same certificate is used elsewhere, add those targets too. You can also set a deployment window to keep changes outside busy hours.

Verify the Certificate Visitors Receive

After deployment, check the certificate using the site's hostname. If that hostname points to a CDN, you will see the CDN's certificate. To check the load balancer, use a hostname that points directly to it and is covered by the certificate.

Set that hostname as the target's live check address in LapseZero to verify it automatically after each deployment. If the check finds the old certificate still in use, a notification helps you identify the missed endpoint.

1. Automatic renewal. Let's Encrypt certificates expire after 90 days, and since March 2026 commercial certificates are capped at 200 days, so renewing by hand will eventually slip. All the tools here renew automatically; the certificate services built into cloud providers have limits, covered further down.

2. How the renewed certificate is deployed, and where it can go. If the certificate only lives on one or two servers, a reload after renewal is enough and any tool can do it. Once the same certificate also has to reach a CDN, object storage or load balancers, you need a ready-made integration for each of them, or you write scripts against the cloud provider's API yourself. Deploying to cloud services also needs access keys, and some companies have a rule on whether those may leave their own servers.

3. What happens when a deployment fails. You want an alert that says which location failed, and on servers, a switch back to the old certificate if writing the files or the reload fails. Harder to catch is a location that was never configured: every tool only updates the locations it was given, and a missing one never produces a failure alert.

Deployment is where it went wrong for us. We have one *.example.com wildcard certificate deployed to two Nginx servers, several domains on Alibaba Cloud's DCDN, and custom domains on OSS, their object storage, all of which used to be updated by hand in each product's console. The sites that got missed were usually not the important ones: our sites have tiers, the important ones are monitored and alert on certificate errors, and some low-tier sites have no monitoring at all, so we heard from a user or a colleague, usually after the certificate had already expired.

acme.sh plus scripts

acme.sh is a good fit when the certificate only lives on one or two servers. Issuance, renewal and a reload after renewal are mature, and notifications can go to Slack, Telegram and many other channels.

Cloud services are a different story. acme.sh ships deploy hooks for a handful of CDNs and panels, plus a generic ssh hook, but nothing for AWS. Importing into ACM and pointing CloudFront or a listener at the new certificate is your own script.

Even where a hook exists, a wildcard certificate needs every target domain spelled out in a variable. Alibaba Cloud DCDN, for example:

export DEPLOY_ALI_DCDN_DOMAIN="www.example.com static.example.com"
acme.sh --deploy -d example.com --deploy-hook ali_dcdn

The variable is saved and reused after each renewal. When a new domain is added later and nobody comes back to update it, you are back to the forgotten site, just moved from a console into a config file.

We never put a script on our servers for a different reason: if it replaced something wrongly one day, we would not know, and that is worse than doing it by hand.

Certimate

Certimate is a self-hosted certificate dashboard, MIT-licensed and free. It runs as a single binary or Docker container, and you set up issuance and deployment in a web UI. It covers far more cloud services than acme.sh hooks, including AWS, Kubernetes, CDNs, WAFs and load balancers. Windows and IIS shops tend to use Certify The Web instead.

The cost of self-hosting is that the dashboard becomes one more service to run. Every cloud access key is stored on that machine, so it needs hardening. If the dashboard goes down, renewals and failure alerts stop together, so monitor it from outside as well.

If company policy does not allow cloud credentials to go to a third party, self-host, and use Certimate.

Hosted services

A hosted service runs issuance, renewal, deployment and alerts on the provider's side, so there is no server or dashboard of yours to maintain. Cloud providers have something similar for their own products: AWS Certificate Manager renews public certificates for load balancers, CloudFront and API Gateway at no cost, but those certificates cannot be copied onto your Nginx servers, and exportable ones are charged at every renewal.

If the certificate has to reach several servers and several cloud services and you do not want to run a dashboard, a hosted service fits, for example LapseZero. It issues certificates from Let's Encrypt (wildcards included), renews them 30 days before expiry by default, and deploys them to every configured location:

• Cloud services: AWS CloudFront, ALB, NLB and API Gateway, plus Alibaba Cloud and Tencent Cloud CDN, load balancers and more.

• Servers: over SSH, or through an open-source deployment agent that pulls jobs, so the server does not need SSH exposed.

When you add a cloud location, LapseZero uses your access key to list the CDN distributions, load balancer listeners and similar resources in the account, and you tick the ones to deploy to. Sites nobody checks show up in that list too, so it does not all rely on memory. Domains added later are not picked up automatically; you come back and tick them as well.

Each location has its own result, and failures are sent by email, Slack, Telegram or webhook. On servers, the old files are backed up first, and if writing the files or the reload fails, the server is switched back to the old certificate and the alert says how the rollback went.

The main hesitation with any hosted service is handing over cloud access keys, and with a service you have never used, we would hesitate too. Use an IAM user limited to the services you deploy to, and start with one or two low-stakes sites.

The free plan covers 3 domains and 5 deployment targets; the two Nginx servers plus one CDN domain and one storage domain above make 4. Paid plans start at $3 a month.

Deployment checks and expiry monitoring

After replacing a certificate, you want to know that the site is serving the new one. LapseZero can check this automatically after deployment: set an HTTPS check address for a deployment location to see whether it serves the new certificate. When you deploy to Nginx through the agent, it can also check on the server itself that Nginx has loaded the new certificate. If the site sits behind a CDN or load balancer, the public check sees the certificate at that entry point; the agent can check the Nginx origin locally.

Keep expiry monitoring running too. Add every domain that uses the certificate, including sites without automatic deployment and the ones nobody looks at, so you get a reminder before their certificates expire. A monitor only connects to the public HTTPS address and needs no credentials. LapseZero's certificate monitoring includes 5 sites on the free plan, or run your domains through the SSL certificate expiry checker once to see whether anything has already been missed.

Since April 25, 2024, free certificates from Tencent Cloud's SSL Certificate Service have been valid for 3 months instead of 12, with a quota of 50 per account. They are single-domain DV certificates issued by TrustAsia, with no wildcard support. These rules come from the China site (cloud.tencent.com); the international site may differ.

The quota is generous. The number of replacements is what adds up. With a 90-day certificate replaced two or three weeks early, each domain needs a new certificate four or five times a year. For a domain on CDN, that means applying, waiting for validation, and swapping the certificate in the CDN console every time.

CDN and EdgeOne work differently, so they are covered separately below.

EdgeOne Only: Use Its Built-In Free Certificate

If your domain is already on EdgeOne, the simplest option is to choose "Apply for free certificate" in the domain's HTTPS settings. According to the official documentation, the certificate is issued by TrustAsia or Let's Encrypt, lasts 90 days, renews automatically 15 days before expiry, and deploys itself. There is nothing to maintain.

Its limits:

• The certificate cannot be downloaded and only works on EdgeOne. If your origin or load balancer needs a certificate for the same domain, you have to get one separately.
• Wildcard certificates require DNS delegation validation. After a site switches from NS access to CNAME access, its existing wildcard certificate cannot renew automatically.
• With CNAME access and automatic validation, the domain must point its CNAME to EdgeOne within an hour, and split-horizon (per-line) DNS is not allowed.
• No SLA. Certificates issued by Let's Encrypt do not support OCSP stapling.

If the certificate only ever lives on EdgeOne, none of this gets in your way. Use it and skip the rest of this article.

Tencent Cloud CDN: Certificate Hosting Only Handles Replacement

CDN has no one-click free certificate like EdgeOne. The usual flow is to get a certificate from the SSL Certificate Service and then deploy it to the CDN domain.

Tencent Cloud's certificate hosting covers half the work. Once enabled, when a new certificate is issued, it gets deployed at a time you choose to the cloud resources the old one was attached to, such as CDN and load balancers. Free certificates can be hosted too. The fully automatic setup in the docs is "auto-renewal plus hosting", and auto-renewal applies to paid certificates; the docs do not say that a free certificate will apply for its successor on its own. With free certificates, you still apply for a new one and complete validation every 90 days. Hosting only does the final swap.

Hosting has one more requirement: the old and new certificates must cover the same domains. Pick the wrong one and production is affected directly.

Writing Your Own Script

If you would rather not depend on the console, you can issue certificates yourself and deploy them through Tencent Cloud's API. Issuance is a solved problem: the dns_tencent plugin in acme.sh completes DNS validation through the DNSPod API and can get a wildcard certificate from Let's Encrypt.

Deployment is on you. The deploy directory in acme.sh has hooks for Alibaba Cloud CDN (ali_cdn.sh), Qiniu, and Baidu Cloud CDN, but none for Tencent Cloud. Calling the API yourself, you upload the certificate to the SSL Certificate Service to get a certificate ID, then bind it to CDN or EdgeOne:

# 1. Upload the certificate. With Repeatable=false, an identical certificate
#    is not uploaded twice; the existing ID is returned instead.
ssl.UploadCertificate
  CertificatePublicKey  = contents of fullchain.pem
  CertificatePrivateKey = contents of privkey.pem
  Repeatable            = false

# 2a. Tencent Cloud CDN: update only the certificate ID path
cdn.ModifyDomainConfig
  Domain = cdn.example.com
  Route  = Https.CertInfo.CertId
  Value  = {"update":"<certificate ID from step 1>"}

# 2b. EdgeOne: swap the certificate on the acceleration domain
teo.ModifyHostsCertificate
  ZoneId         = <zone ID>
  Hosts          = ["www.example.com"]
  Mode           = sslcert
  ServerCertInfo = [{"CertId":"<certificate ID>"}]

The CDN step is easy to get wrong. If you call UpdateDomainConfig with an Https object that contains only the certificate and private key, you run into this rule from the API documentation: for complex configuration items, "you must pass all properties of the object; properties not passed will use default values." In other words, HSTS, OCSP stapling, and TLS version restrictions that were enabled on the domain get reset to defaults on every renewal. ModifyDomainConfig updates a single path and leaves everything else unchanged, which makes it the safer call for swapping certificates.

Updating only Https.CertInfo.CertId assumes HTTPS is already enabled on the domain. If it is not, changing the certificate ID alone has no effect, and setting Https.Switch to on by itself is rejected because there is no certificate yet. In that case, set Route to Https and Value to {"update":{"Switch":"on","CertInfo":{"CertId":"<certificate ID>"}}}. Your script can check Https.Switch with DescribeDomainsConfig first and pick the right call.

Once the script works, you still need scheduling, retries, and alerting. Use a CAM sub-user for credentials, with permissions limited to DNSPod, SSL certificate upload, and CDN / EdgeOne configuration.

Ways to Stop Replacing Certificates by Hand

Certimate is an MIT-licensed open-source project. Once self-hosted, it issues certificates and deploys them to Tencent Cloud CDN, EdgeOne, CLB, COS, and more, along with Alibaba Cloud and other providers. Certificates, private keys, and cloud credentials stay on your own server; the trade-off is that you maintain that server and Certimate itself.

With only one or two CDN domains, replacing certificates by hand looks manageable. But four or five times a year, someone has to remember every time, and eventually nobody will. If you can automate it for free, it is worth setting up even for a few domains.

Auto-Renewing and Deploying to Tencent Cloud with LapseZero

LapseZero is a hosted certificate automation service. It issues certificates from Let's Encrypt, renews them before expiry, and deploys them to cloud products on Alibaba Cloud, Tencent Cloud, and AWS, or to your own servers. On Tencent Cloud it currently supports CDN, EdgeOne, and HTTPS listeners on CLB load balancers.

1. Add the domain. If DNS is on DNSPod, provide keys for a CAM sub-user with DNS permissions only, and the platform writes the validation records. If you would rather not hand over DNS access, use DNS delegation, which only needs CNAME records added once, when you add the domain. The differences are covered in HTTP-01 vs DNS-01 vs DNS delegation.
2. Issue the certificate. Wildcards are supported, and Tencent Cloud's 50-certificate quota is not touched.
3. Add deploy targets. The platform lists the CDN domains and EdgeOne acceleration domains in your account; select the ones that match the certificate. The same certificate can go to CDN, CLB, and your own servers at once.
4. Renew automatically. By default it renews 30 days before expiry and deploys to every target after issuance. Each target's result is recorded separately, and failures are sent to you by email, Slack, Telegram, or other channels.

Two things to know. A successful deployment means Tencent Cloud's API accepted the new certificate; the platform does not visit the domain afterwards to confirm it is live, and CDN edge nodes take time to pick it up, so check it a little later with the SSL certificate expiry checker. Your cloud credentials are stored by the platform, so use a CAM sub-user with minimal permissions. The free plan includes 3 domains and 5 deploy targets.

Certificate lifetimes keep shrinking: from March 15, 2027, every public certificate maxes out at 100 days, and 47 days from 2029, paid certificates included. See 47-day SSL certificates.

A certificate you used to replace once a year will need replacing at least 4 times a year in 2027 and roughly every month in 2029. Every replacement ends with a reload, and a reload is exactly the operation most people running servers would rather not do often.

The schedule

The CA/Browser Forum adopted Ballot SC-081v3 in April 2025. Every publicly trusted CA has to follow it, so paid certificates are affected too:

The third column gets less attention. Once a CA has validated that you control a domain, it can reuse that result for a while instead of validating again for the next certificate. By 2029 that window is 10 days, so almost every certificate will need fresh domain validation. If you still buy certificates and validate them by email or by uploading a file, you will be doing that every month.

When it was once a year, the problem was remembering

A yearly renewal is hard to schedule. Set a phone reminder for a year from now and there is a fair chance you will have a different phone by then. Calendars and ticket queues are not much better, since a year is long enough for the person who owned the task to move on.

If you relied on Let's Encrypt's expiry emails as a safety net, those stopped on June 4, 2025.

So expiry is often discovered by users. A pattern we ran into fairly often: customers on our mobile client reported a "network error" and nothing mentioned certificates. Native apps and embedded webviews often hide TLS failures behind a generic message like that. The server logs had no record of those requests at all, because the client gave up during the TLS handshake and never reached Nginx.

When a client reports network errors and your server logs show nothing, check the certificate first:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate

Or run the domain through the SSL certificate expiry checker without logging in to anything.

At 100 days, the problem is the reload

We used to run most certificates directly on cloud VMs and later moved many of them to a CDN. Swapping a certificate on a CDN is an upload. No SSH, no service restart.

On a server, the uncomfortable part is the reload, for two reasons:

1. You are not sure whether someone changed the Nginx config since the last reload. A broken config sits there quietly until the next reload, and that reload happens to be the one you ran to swap a certificate.
2. Some servers have not been touched in months. Reloading or restarting them out of the blue is the kind of thing that surfaces problems nobody knew about.

Once a year, you can live with that risk. At 100 days, every server faces it 4 or 5 times a year; at 47 days, every month. The CA/Browser Forum's reasoning is sound: revocation does not work well in practice, so a shorter lifetime limits how long a leaked key stays useful. For the people doing the swaps, it is still more work and more risk.

Why many admins still swap by hand

Plenty of people decide not to script it, and their reasons are specific:

• Servers and configs change over time. A script that was not updated along with them can do more damage than a manual swap.
• When you swap by hand, you know when it happened and you test it yourself afterwards. A script can fail at 3 a.m. when nobody is around to deal with it.

These concerns are fair. The tooling for issuance and renewal is mature: certbot and acme.sh renew on a schedule and can run a reload hook, Caddy handles certificates on its own, cert-manager renews them inside Kubernetes, and AWS Certificate Manager renews the certificates it issues for services like CloudFront and ALB. If everything you run fits one of these, you may not need anything else.

The gaps show up with a mix of servers and cloud services. certbot has no failure notifications, and acme.sh has notification hooks you have to configure yourself. Pushing a certificate to a CDN or load balancer outside those integrations usually means writing your own script against the provider's API, and that script is exactly the part that breaks when the environment changes.

Doing it by hand is a reasonable choice today. At 100 days the number of manual swaps stops being manageable, so automation has to win the same trust the manual process has.

The bar for automation: it can fail, but it must not touch production

The standard we hold automation to is a single rule: it can fail, but it must never take production down. Either the swap succeeds completely, or nothing changes.

A failed issuance or a failed deploy is fine. If certificates renew 30 days before expiry, a failure leaves weeks to fix it, and a failure at 3 a.m. is just a message to read in the morning. What is not fine is a half-finished swap that breaks the live service.

Services only reread certificate files on reload or restart. That means a deploy cannot hurt production as long as you do the following:

1. Before replacing anything, confirm the new certificate and private key match.
2. Back up the old files, then overwrite in place. Writing with cat > keeps the file's owner, permissions, and symlinks; writing a temp file and mv-ing it over the original replaces all three.
3. Run nginx -t before reloading. If the check fails, restore the old files and skip the reload.
4. Make sure a failure reaches a person.

If you swap certificates on your own servers, this script is a starting point:

#!/usr/bin/env bash
set -euo pipefail

CERT=/etc/nginx/ssl/example.com.pem
KEY=/etc/nginx/ssl/example.com.key
NEW_CERT=$1
NEW_KEY=$2

# The certificate and the key must share the same public key
if [ "$(openssl x509 -noout -pubkey -in "$NEW_CERT" | openssl sha256)" != \
     "$(openssl pkey -pubout -in "$NEW_KEY" | openssl sha256)" ]; then
  echo "Certificate and key do not match, nothing changed" >&2
  exit 1
fi

cp -a "$CERT" "$CERT.bak"
cp -a "$KEY" "$KEY.bak"

if cat "$NEW_CERT" > "$CERT" && cat "$NEW_KEY" > "$KEY" \
   && nginx -t && systemctl reload nginx; then
  echo "Replaced"
else
  cat "$CERT.bak" > "$CERT"
  cat "$KEY.bak" > "$KEY"
  echo "Replacement failed, old certificate restored" >&2
  exit 1
fi

The script exits non-zero on failure. Pair it with cron's MAILTO, or post to a Slack or Telegram webhook in the else branch, and someone will hear about it. For services that need a restart, such as Tomcat, restart again after restoring the old files, or the service stays down.

Managed services are simpler. On CloudFront, for example, the new certificate is imported into ACM first, and the distribution switches to it in a single update call. If that call fails, the distribution keeps serving the old certificate, so there is no half-swapped state.

If you would rather not maintain the script

You can hand it to LapseZero. It issues certificates from free CAs such as Let's Encrypt, renews them before they expire, and deploys them to your servers or to AWS, Alibaba Cloud, and Tencent Cloud services such as CDNs and load balancers.

On servers, it does roughly what the script above does: back up the existing files, write everything before running the post-deploy command, and restore the old files if a write fails. If the post-deploy command fails, it restores the files and runs the command once more to bring the service back on the old certificate, then tells you "rolled back, the old certificate is still live" and waits for you to check the cause before retrying. Including nginx -t in the post-deploy command is recommended here as well.