Setting Up SSL Auto-Renewal with Different ACME Clients: Step-by-Step Guide
SSL/TLS certificates are critical for running secure communications between websites, applications, and users. At the same time, certificates have a short period of validity; thus, they should be renewed before expiration or invalidity.
Manual certificate renewal is a simple undertaking for only one website. However, manual certificate renewal becomes more complicated when one needs to manually renew certificates for different websites, domains, servers, cloud environments, and containerized applications.
Therefore, missing certificate renewal could end up either in security alerts in a web browser, emergency situations, or loss of customers’ trust.
That’s when the ACME-based certificate automation solution is needed.
What ACME is?
ACME stands for Automated Certificate Management Environment and it makes it possible for special clients to renew SSL/TLS certificates in an automated manner. Due to the large number of ACME-compatible clients like Certbot, acme.sh, Caddy, Traefik, and cert-manager, it is possible to automate entire certificate lifecycle.
In this article, we will explain how to set up automatic certificate renewal using different ACME-enabled clients and platforms, which will include checking renewal functions, implementing automation hooks for deploying renewals, and monitoring operations.
How ACME Certificate Auto-Renewal Works?
Although there are various types of ACME clients, the operation remains almost the same in every case.
- The ACME client determines when the certificate will expire.
- When the certificate approaches its renewal point, the ACME client initiates renewal.
- The ACME client performs the domain validation procedure that is required.
- After the Certificate Authority issues a new certificate, it is stored in the correct place.
- There must be implemented a deployment or renewal hook that will reload a web server or application in question.
Thus, a properly automated solution implies:
Certificate Monitoring → Renewal → Validation → Certificate Issuance → Deployment → Service Reload → Verification
The timing of the renewal process can differ depending on ACME client and its settings. It is not recommended to depend on a standard universal timing; instead, it is better to follow the instructions provided by the particular ACME client. Although there are various types of ACME clients, the operation remains almost the same in every case.
Also Read: Complete Guide to ACME External Account Binding (EAB)
How to Configure Automatic SSL Renewal with Certbot?
Certbot is one of the most popular ACME clients and provides certificates by Let’s Encrypt, Sectigo and DigiCert.
This client can be used to obtain certificates, automate renewals, and work together with various web servers including Apache and Nginx.
Step 1: Install Certbot
On Ubuntu or Debian-based systems, Certbot can be installed using the appropriate package manager or the recommended installation method for your operating system.
For Example:
sudo apt update
sudo apt install certbot
If you need Certbot to automatically configure Nginx or Apache, install the appropriate plugin as well.
For Nginx:
sudo apt install python3-certbot-nginx
For Apache:
sudo apt install python3-certbot-apache
Step 2: Obtain an SSL Certificate
For a standalone server, you can request a certificate using:
sudo certbot certonly --standalone -d example.com -d www.example.com
Replace example.com with your actual domain name.
For an Nginx server, you may use:
sudo certbot --nginx -d example.com -d www.example.com
For Apache:
sudo certbot --apache -d example.com -d www.example.com
Certbot will complete the required validation process and install or store the certificate.
Step 3: Check the Automatic Renewal Schedule
On many modern Linux installations, Certbot may use a systemd timer or another scheduled mechanism for automatic renewal.
Check the timer with:
systemctl list-timers | grep certbot
If your installation already has a working renewal timer, you usually do not need to create an additional cron job.
Step 4: Test Certificate Renewal
Before relying on automation, always perform a dry run:
sudo certbot renew --dry-run
This allows you to verify that the renewal process is working without relying on a production certificate renewal event.
Step 5: Add a Deployment Hook
Renewing a certificate does not always mean that the running web server immediately begins using the new certificate.
A deployment hook can reload the service after a successful renewal.
For Nginx:
sudo certbot renew --deploy-hook "systemctl reload nginx"
For Apache:
sudo certbot renew --deploy-hook "systemctl reload apache2"
The deployment hook gets executed as soon as the certificate is successfully renewed.
Step 6: Optional Cron Configuration
As long as you don’t use a systemd timer or any other automatic renewal technology, you may opt for cron to set up a schedule for the use of Certbot.
For example:
0 3,15 * * * /usr/bin/certbot renew --quiet --deploy-hook "systemctl reload nginx"
The command specifies checking for renewal twice a day.
Do not implement cron jobs if there is already a working systemd timer for Certbot.
How to Configure Automatic SSL Renewal Using acme.sh?
acme.sh is a lightweight ACME client implemented in the form of a shell script.
It is particularly popular for:
- DNS-based validation
- Wildcard certificates
- Multi-domain environments
- Servers with minimal dependencies
- Automating the process in the various hosting ecosystems
Step 1: Install acme.sh
Refer to the site’s official guidelines for installing acme.sh.
One of the popular ways of installing it can be using the following command:
curl https://get.acme.sh | sh
Bear in mind though that scripts downloaded from the internet must always be checked for the original source and installation instructions.
Once acme.sh is installed, refresh your shell config as required.
Step 2: Configure Domain Validation
acme.sh supports multiple validation methods.
For a standard HTTP-based certificate:
acme.sh --issue -d example.com -w /var/www/html
For wildcard certificates, DNS-01 validation is required.
For DNS-01 Validation:
acme.sh --issue --dns dns_cf -d example.com -d '*.example.com'
The particular DNS provider settings depend on the provider and its integration with acme.sh DNS API.
Make sure you use the API key that has minimum privileges to alter DNS settings.
Step 3: Install the Certificate to Your Server Location
After getting the certificate, install it in the specific location of your web server:
acme.sh --install-cert -d example.com \
--key-file /etc/nginx/ssl/example.com.key \
--fullchain-file /etc/nginx/ssl/example.com.crt \
--reloadcmd "systemctl reload nginx"
The –reloadcmd command ensures that Nginx reloads after a successful certificate update.
Step 4: Verify the Renewal Schedule
acme.sh typically installs its own scheduled renewal process.
You can check the current user’s cron jobs with:
crontab -l
Look for an acme.sh renewal entry.
The scheduled process periodically checks whether certificates need renewal and performs the required renewal workflow.
Step 5: Test the Setup
Check the Certificate Status:
acme.sh --list
You should also verify that the deployed certificate is actually being served by the website after renewal.
Also Read: How to Install an ACME SSL Certificate on LiteSpeed Using acme.sh?
How to Set Up Auto-Renewal with Caddy?
Caddy is capable of automatically managing HTTPS and certificate renewals.
Unlike other types of web servers that demand manual configuration of the renewal scheduler or ACME client, Caddy does that automatically.
Simple Configuration Example is:
example.com {
reverse_proxy localhost:3000
}
With correct DNS configuration and proper networking done, Caddy will automatically manage certificates.
Basic Setup Steps
- Install Caddy according to its suggested installation.
- Update the DNS settings so that they point to your server.
- Make sure ports 80 and 443 are opened.
- Add your domain to the Caddy configuration.
- Start Caddy or reload it.
- Check for HTTPS availability.
The advantage of Caddy is that it does certificate renewals automatically which is a desired quality for ones who have to manage certificates.
How to Configure Auto-Renewal with Traefik?
Traefik is widely utilized as a reverse proxy and load balancer for new applications and containerized environments.
Moreover, it has the ability to use ACME to automatically request and renew certificates.
In order to have an essential installation, an ACME certificate resolver is needed.
For example:
certificatesResolvers:
letsencrypt:
acme:
email: [email protected]
storage: /letsencrypt/acme.json
httpChallenge:
entryPoint: web
You can then associate the certificate resolver with the relevant router.
For example:
labels:
- "traefik.http.routers.myapp.tls=true"
- "traefik.http.routers.myapp.tls.certresolver=letsencrypt"
Basic Setup Steps
- Setting up Traefik entry points.
- Configuring an ACME solver for issuing certificates.
- Providing an email address for admin purposes.
- Setting up non-volatile storage for issuing certificates and accounts.
- Choosing between HTTP-01 and DNS-01 validate methods.
- Binding the solver to your HTTPS routers or services.
- Starting Traefik and checking if the certificate has been issued by the ACME authority.
Traefik will handle the renewal process by itself due to the integration with ACME.
The acme.json file keeps sensitive certificate and account data inside, so it must be secured.
How to Set Up Auto-Renewal with cert-manager in Kubernetes?
Because of Kubernetes, cert-manager is the most common solution to automate the issuing of the certificates.
The tool can work with ACME-compatible Certificate Authorities and control certificate resources in the Kubernetes cluster without any efforts on users.
Step 1: Install cert-manager
Make the installation process for cert-manager according to the needed method.
After installation, it is required to check if all cert-manager processes are running.
Step 2: Create a ClusterIssuer
A ClusterIssuer defines how certificates should be requested.
Example Configuration:
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: [email protected]
privateKeySecretRef:
name: letsencrypt-account-key
solvers:
- http01:
ingress:
ingressClassName: nginx
For DNS-based validation, configure a supported DNS provider instead.
Step 3: Create a Certificate Resource
Example:
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: example-com-tls
spec:
secretName: example-com-tls
issuerRef:
name: letsencrypt-prod
kind: ClusterIssuer
dnsNames:
- example.com
- www.example.com
cert-manager stores the resulting certificate and private key in the specified Kubernetes Secret.
Also Read: How to Install an ACME SSL Certificate in Kubernetes Using Cert-Manager?
Step 4: Reference the Certificate in an Ingress
For example:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
spec:
tls:
- hosts:
- example.com
- www.example.com
secretName: example-com-tls
cert-manager handles renewal according to its certificate lifecycle management process.
Step 5: Monitor Certificate Status
Check certificate resources with:
kubectl get certificates
For additional details:
kubectl describe certificate example-com-tls
You can also inspect CertificateRequests, Orders, and Challenges when troubleshooting failed ACME validation.
Choosing the Right ACME Client
Different environments require different automation approaches.
| Environment | Recommended Approach | Best Use Case |
| Traditional Linux server | Certbot | Simple Nginx or Apache deployments |
| DNS automation and wildcard certificates | acme.sh | Flexible DNS-01 automation |
| Integrated web server automation | Caddy | Minimal certificate management overhead |
| Reverse proxy and containers | Traefik | Docker and microservice environments |
| Kubernetes | cert-manager | Kubernetes-native certificate lifecycle management |
| Large multi-domain environments | Centralized certificate management platform | Visibility, inventory, monitoring, and governance |
Depending on the infrastructure, need for validation, and number of certificates, the choice may vary.
Important: Configure Deployment After Renewal
Certificate renewal is only one part of the process.
After a new certificate is issued, the running application must be able to access and use it.
For Nginx:
systemctl reload nginx
For Apache:
systemctl reload apache2
For HAProxy:
systemctl reload haproxy
Normally preferred over unnecessary restarting, provided the service can handle it, reloads are handled by the containers, load balancers, or complex applications by some added automation for deploying certificates.
Test Your Auto-Renewal Configuration
Don’t wait until you get too close to your certificate expiration date to find out that your renewal operation isn’t properly set up.
For Certbot:
sudo certbot renew --dry-run
Moreover, use the testing recommendations made by the relevant CA and client when working with other ACME clients.
Testing should verify:
- Renewal of the certificate
- Validation of the domain
- Implementation of the certificate
- Reloading of the service
- Availability of the application
Monitor Certificate Expiration Independently
Automation reduces manual work, but it shouldn’t eliminate the need for monitoring.
A good certificate management process should involve
Automated Renewal + Automated Deployment + Independent Monitoring + Failure Alerts
You can check the certificate served by a public website using OpenSSL:
echo | openssl s_client -servername example.com \
-connect example.com:443 2>/dev/null \
| openssl x509 -noout -dates
You can also check whether a certificate expires within a specific period:
openssl s_client -connect example.com:443 \
-servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -checkend 604800
In this example, 604800 represents seven days.
To track certificates effectively in production environments, you might want to use an external monitoring mechanism, besides local monitoring of certificates. With an external monitoring system, you are able to prevent instances when a certificate was successfully renewed and saved to the disk but was not deployed properly to the public service.
Common Auto-Renewal Problems
Even automated certificate management can fail.
DNS Validation Failure
DNS-01 renewal may fail because of:
- Expired API credentials
- Insufficient permissions
- DNS provider changes
- Incorrect DNS configuration
Review your DNS credentials and ensure that the ACME client has only the permissions required for validation.
HTTP Validation Failure
HTTP-01 validation can fail when:
- Port 80 is blocked
- DNS records point to the wrong server
- Reverse proxies block the ACME challenge
- Firewall rules prevent access
Verify that the Certificate Authority can reach the required challenge endpoint.
Certificate Renewed but Not Active
A certificate may be successfully renewed but the website may still serve the old certificate.
This usually indicates a deployment problem.
Check:
- Certificate file paths
- Web server configuration
- Deployment hooks
- Service reload status
- Load balancer configuration
Scheduled Renewal Is Not Running
Check the configured automation mechanism.
For example:
systemctl list-timers
or:
crontab -l
Also review the ACME client’s logs for failed renewal attempts.
Best Practices for Reliable SSL Auto-Renewal
The following practices can help you minimize the risk of certificate expiry:
- Only use one certificate renewal method. Don’t use unnecessary cron jobs or timers.
- Test your renewal before relying on it. If you can, use the test mode or staging environment to check your renewal method.
- Automate certificate installation. You should make sure your application is able to reload the renewed certificate or otherwise recognize it.
- Monitor independently. You need to monitor the certificate served to users, not just the certificate on your server.
- Keep private keys and API credentials safe. You need to make sure that you apply correct permissions and secret management.
- The DNS API tokens should be given the least possible privilege, and only offer the permissions required for ACME validation.
- Configuring alerts for failures is also essential. The administrator needs to be informed about failed validation, renewal, and deployment.
- Maintaining inventory of certificates is important. It should include important information regarding certificates, domains, expiry dates, owners, and locations of deployment.
- Staging environment should be used for testing. This will minimize unnecessary requests for certificates in production when automating the process.
- Keeping automation tools up to date is a good practice. ACME clients and software should be regularly updated a well.
Conclusion
The automated SSL certificate renewal is becoming increasingly relevant due to the growing number of domains, services, cloud platforms, containers, and short-lived certificates.
The use of Certbot, acme.sh, Caddy, Traefik, or cert-manager for successful execution does not change the fact that the aim is the same regardless of the method: reducing manual management of certificates while ensuring reliable TLS protection.
In reality, authentic certificate automation goes beyond just scheduling the renewal process.
A solid certificate lifecycle should encompass:
Renewal Automation → Validation Automation → Deployment of the Certificate → Restarting the Service → Monitoring → Alerts About Failures
The main rule of thumb is this: automate, but do not forget to monitor the result. A certificate management system can be trusted only if you know that the certificate that has been renewed is not only stored on the server, but is active and serving the users.