How to Automate SSL Certificates and HTTPS Renewals Across Cloud Hosting Platforms

Managing SSL certificates by hand is a frequent challenge for teams operating production workloads. If you currently rely on Let’s Encrypt with cron jobs on virtual servers, you may already know how frustrating expiration warnings, unsuccessful renewals, and continuous maintenance can be.

This tutorial explains how to automate SSL certificates and HTTPS renewals across a cloud environment by using fully managed SSL on load balancers and application platforms, without manually running certbot on servers.

You will also learn how to enable automatic HTTPS on a cloud platform, how automated HTTPS certificate handling works for both load balancers and managed application platforms, and when it makes sense to choose managed SSL instead of Let’s Encrypt on individual virtual machines. By the end, you will know how to avoid certificate renewal failures and lower operational effort.

Why Automate SSL Certificates?

Manually renewing SSL/TLS certificates can lead to the following problems:

• Expired server certificates, which trigger browser security warnings and may cause downtime.
• A higher chance of service disruptions caused by missed renewals.

Automating SSL certificate renewals provides several advantages:

• Automatic SSL and TLS certificate renewal, including X.509 certificates, keeps certificates updated before they expire.
• There is no need to run certbot or maintain cron jobs, because managed load balancer certificate handling and platform-as-a-service SSL automation take care of provisioning and renewal.
• Certificate renewal for container platforms and managed application SSL certificates becomes easier through cloud platform HTTPS automation, offering zero-configuration certificate provisioning and auto-renewal.

This tutorial shows how to automate SSL on both load balancers and application platforms with minimal effort.

Key Takeaways

• Managed load balancers can provide Let’s Encrypt support and HTTP/3, automatically issuing and renewing SSL certificates at no cost through Let’s Encrypt while also improving user performance with HTTP/3. This removes the need to configure Let’s Encrypt manually on each virtual server.
• Managed application platforms can automatically provision and renew SSL certificates when you attach a custom domain, requiring no manual setup.
• The do-it-yourself method with Let’s Encrypt and cron jobs works, but it requires continuing maintenance. Managed services provide automated HTTPS certificate management without certbot.
• HTTP-to-HTTPS redirects and HSTS headers are important hardening measures no matter which SSL method you choose.
• Monitoring certificate expiration dates helps prevent service interruptions, even when renewals are automated.

Prerequisites

Before you begin, make sure you have the following:

• A cloud account with a virtual machine running Ubuntu 24.04 or later
• A domain name with DNS access so you can configure A records and validation
• Basic familiarity with Nginx configuration and the Linux command line
• SSH access to your virtual machine
• An API token for your cloud provider if you want to automate tasks through scripts

How Managed SSL Works on Cloud Platforms

Transport Layer Security (TLS) encrypts traffic between clients and servers. SSL certificates, more accurately TLS or X.509 certificates, confirm your server’s identity and allow encrypted connections. Let’s Encrypt issues free server certificates that remain valid for 90 days, so they must be renewed before they expire.

How does a cloud platform handle certificate renewals when you use managed services?

The platform provisions certificates, usually through Let’s Encrypt, verifies domain ownership, and renews certificates automatically before expiration. No certbot process and no cron job are required.

• For load balancers, the listener, often an HTTPS listener, terminates TLS at the edge.
• For application platforms, the service manages SSL certificates for deployed apps when you add a custom domain. Both options can support multi-region deployments and, where available, global distribution.

Cloud providers generally offer three approaches:

• DIY on virtual machines: You manage Let’s Encrypt certificates yourself with certbot and cron jobs.
• Managed SSL on load balancers: The cloud provider provisions and renews certificates at the load balancer layer.
• Managed application platform SSL: Platform-as-a-service SSL automation and container platform certificate renewal are handled automatically with no configuration.

The following sections focus on automating SSL on load balancers and managed application platforms, with full renewal management and no manual certbot use.

Setting Up SSL with Let’s Encrypt on a Virtual Machine

This section covers the traditional do-it-yourself method using Let’s Encrypt and certbot. Although this approach works, it requires more maintenance than managed solutions such as load balancers and application platforms.

Installing Certbot

First, update the system and install certbot:

sudo apt update
sudo apt install certbot python3-certbot-nginx -y

The python3-certbot-nginx package includes the Nginx plugin, which can automatically adjust Nginx for SSL. If Nginx is not installed yet, install and configure it first.

Requesting the First Certificate

Before requesting a certificate, confirm that your domain points to your virtual machine’s IP address. Create an A record in DNS that maps the domain to the server’s public IP.

Request a certificate for your domain:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

Certbot will perform the following actions:

• Verify domain ownership through an HTTP challenge
• Create the certificate
• Update the Nginx configuration to use SSL
• Enable automatic renewal

After the certificate is created successfully, certbot typically installs a systemd timer that attempts renewal twice per day. Even so, you should verify that this is functioning correctly.

Verifying Automatic Renewal

Test the renewal process with a dry run:

sudo certbot renew --dry-run

If this command succeeds, automatic renewal is configured correctly. The certbot systemd timer runs certbot renew twice daily, but it renews only certificates that are within 30 days of expiration.

You can inspect the timer status with:

sudo systemctl status certbot.timer

Common Problems with DIY Certificate Management

Several issues can appear when certificates are managed manually:

• Port 80 is blocked: Let’s Encrypt needs port 80 for HTTP validation. Your firewall must allow HTTP traffic.
• DNS propagation delays: If your DNS changes have not fully propagated, certificate requests can fail. You can verify propagation with tools such as dig or online DNS checkers.
• Multiple renewal paths: If multiple servers sit behind a load balancer, each server may require its own certificate, which makes renewals more complex. In that case, managed certificates on a load balancer are usually a better fit.
• Certificate synchronization: After renewal, Nginx must be reloaded, and certificates may need to be synchronized across multiple servers.

Automating SSL on Cloud Load Balancers

Managed load balancers make SSL certificate automation easier by taking care of TLS termination and renewal automatically.

This method is especially useful when you run multiple backend servers or want to remove SSL processing from your application hosts. Load balancers spread traffic across several servers and improve availability.

Enabling Managed SSL on a Load Balancer

Open your cloud provider’s control panel and create a new load balancer.

1. Go to the networking section and choose load balancers, then create a new one.
2. Select the region where the load balancer should run. It is generally best to use the same region as the backend servers.
3. Select the pool of backend virtual machines, either during creation or afterward.
4. Add forwarding rules to define how traffic moves from the load balancer to the backend servers. At least one rule is required.

A typical default rule sends HTTP traffic on port 80 at the load balancer to HTTP port 80 on the backend servers. Additional rules can be created during setup and adjusted later in the settings.

You can usually choose between these options:

• Create a forwarding rule that uses a Let’s Encrypt certificate
• Upload your own certificate and private key

If your domain is managed in the provider’s DNS service, you can normally select the Let’s Encrypt option to generate a fully managed SSL certificate. The platform then creates and renews that certificate automatically.

Many platforms also offer an option to create DNS records automatically for newly issued Let’s Encrypt certificates. If you prefer to manage DNS yourself, you can disable that option during setup.

This setting can usually be changed later when adding or updating forwarding rules. However, the updated preference normally affects only new rules and does not change existing DNS records.

Forcing HTTPS Traffic

If you want all visitors to connect through HTTPS for stronger security and better data integrity, you can redirect HTTP traffic to HTTPS. Any insecure request reaching the load balancer is then redirected to the certificate-enabled HTTPS endpoint.

In advanced settings, enable an option such as Redirect HTTP to HTTPS.

After this is configured, the platform usually performs the following actions automatically:

• Verifies domain ownership through DNS
• Provisions the SSL certificate
• Configures automatic renewal
• Associates the certificate with the load balancer

The load balancer decrypts SSL traffic and forwards plain traffic to backend servers over the private network. This reduces CPU usage on application servers and simplifies certificate management. Certificates remain only on the load balancer instead of being copied to every backend system.

Managed SSL certificates on the load balancer are automatically renewed before they expire. No cron jobs and no certbot configuration are needed.

If you require full end-to-end encryption because of compliance or stricter security requirements, use SSL passthrough instead of TLS termination.

SSL passthrough means certificates must still be managed on the backend servers, but it provides stronger protection for sensitive workloads.

Automating SSL on Managed Application Platforms

Managed application platforms offer the simplest form of automated HTTPS certificate management. When you attach a custom domain, the platform automatically provisions and renews SSL certificates with zero configuration. This includes platform-as-a-service SSL automation and container platform certificate renewal without certbot or other manual steps.

Enabling HTTPS on an Application Platform

To use automatic HTTPS and cloud platform HTTPS automation, first deploy your application.

After deployment, open the networking or domains area of the application dashboard.

Below are the typical steps for setting up a custom domain and SSL on a managed application platform:

1. Add a Custom Domain to the Application

• Open the cloud provider’s control panel.
• Go to the dashboard for your application.
• Under the domains section, choose the option to add a domain.
• Enter your custom domain and confirm the change.

2. Update DNS Records

Go to your domain registrar or DNS provider and update the DNS records so the domain points to the managed application platform. The platform will generally provide the required CNAME or A records.

DNS propagation can take some time, so patience is required.

It may also take a few minutes after propagation before SSL becomes active. If HTTPS does not appear immediately, verify the DNS settings, refresh the platform dashboard, and allow additional time for changes to propagate.

3. Automatic SSL Certificate Provisioning

Once the DNS records are correct and fully propagated, the application platform will automatically provision an SSL certificate for your domain, usually through Let’s Encrypt.

After this step, your app should be reachable through https:// followed by your custom domain.

You do not need to generate CSR files or manually install certificates, because the platform handles the entire process.

Once the custom domain is correctly configured, SSL/TLS is automatically provisioned. This means there is no need to obtain or install certificates manually.

In addition, most managed application platforms automatically redirect all incoming HTTP requests to HTTPS, so users are always served through secure connections.

You will know SSL is active when:

• Your app is reachable over https, for example https://www.myapp.com.
• A padlock icon appears in the browser address bar.
• The browser marks the connection as secure.

The application platform usually performs these tasks automatically:

• Validates domain ownership
• Issues an SSL certificate through Let’s Encrypt
• Configures automatic renewal
• Sets up HTTP-to-HTTPS redirects
• Enables HSTS headers

No manual certificate management is required. The platform manages the full certificate lifecycle.

Application platforms generally monitor certificate expiration and renew certificates automatically, often around 30 days before expiration. There is no need to configure cron jobs, systemd timers, or renewal scripts.

How Cloud Platforms Handle Certificate Renewals

With managed SSL on load balancers and application platforms, the cloud provider handles the entire renewal lifecycle:

Both load balancer and application platform managed SSL certificates are typically issued through Let’s Encrypt, and renewal is automatic. This is the main difference between managed SSL and Let’s Encrypt on virtual machines: on servers, you handle certbot yourself; on managed services, the cloud platform does it for you.

Troubleshooting Common SSL Problems

For load balancer SSL versus application platform SSL, both rely on managed certificates and automatic renewal. Choose a load balancer for custom backend infrastructure and an application platform for platform-managed applications.

Security and Performance Best Practices

No matter which SSL option you choose, whether load balancer SSL, application platform SSL, or DIY certificates, you should apply these security and performance best practices.

Enforcing HTTPS Redirects

Make sure all HTTP traffic is redirected to HTTPS. On load balancers, this is usually done through forwarding rules. On virtual machines with Nginx, add the following to the server block:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://$host$request_uri;
}

This permanently redirects all HTTP requests to HTTPS with a 301 redirect.

Configuring HSTS

HTTP Strict Transport Security, or HSTS, is a browser policy that tells clients to always use HTTPS instead of HTTP when accessing your site. By enabling HSTS, you help protect users from downgrade attacks and cookie hijacking.

To enable HSTS in Nginx on a virtual machine, add the following directive to your HTTPS server block, meaning the block that listens on port 443:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

• max-age=31536000 tells browsers to use only HTTPS for one year.
• includeSubDomains extends that rule to all subdomains.
• preload requests inclusion in browser preload lists, which strengthens HTTPS-only enforcement.

Example:

Place the add_header line inside the HTTPS server block in your Nginx configuration file for the domain, then reload Nginx so the changes take effect.

server {
    listen 443 ssl;
    server_name yourdomain.com www.yourdomain.com;

    # ...other SSL configuration...

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    # ...other settings...
}

This tells browsers to always prefer HTTPS when visiting your site and improves overall security.

Security Headers

It is also a good idea to add security headers to your server configuration to reduce exposure to common web attacks. In Nginx, you can add the following:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Here is what each header does:

• X-Frame-Options “SAMEORIGIN”: Prevents pages from being embedded in a frame or iframe by another site, helping reduce clickjacking risks. Only the same site can frame the content.
• X-Content-Type-Options “nosniff”: Instructs browsers not to guess a file’s MIME type and instead use the declared Content-Type, which helps prevent some drive-by download attacks.
• X-XSS-Protection “1; mode=block”: Enables the browser’s cross-site scripting filter and tells it to block the page if an attack is detected rather than trying to sanitize it.
• Referrer-Policy “strict-origin-when-cross-origin”: Controls how much referrer data is sent with requests, sending the full referrer only on same-origin requests and only the origin on cross-origin requests, which improves privacy.

Add these directives to your server, for example inside the Nginx server block, so browsers enforce these protections on every response.

These headers strengthen your site’s security posture with only a few lines of configuration.

Monitoring Certificate Expiration

Even with automated renewal in place, you should still monitor certificate expiration dates so issues are detected early. Set up alerts to notify you when certificates are getting close to expiration.

Checking Certificate Expiration Dates

For certificates on virtual machines, you can check expiration by running:

sudo certbot certificates

Output

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Found the following certs:
  Certificate Name: yourdomain.com
    Domains: yourdomain.com www.yourdomain.com
    Expiry Date: 2026-05-10 10:35:03+00:00 (VALID: 87 days)
    Certificate Path: /etc/letsencrypt/live/yourdomain.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/yourdomain.com/privkey.pem

This displays all certificates together with their expiration dates and file locations.

Setting Up Expiration Alerts

Create a monitoring script that checks certificate expiration:

#!/bin/bash
DOMAIN="yourdomain.com"
EXPIRY_DATE=$(echo | openssl s_client -servername "$DOMAIN" -connect "$DOMAIN:443" 2>/dev/null | openssl x509 -noout -dates | grep notAfter | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY_DATE" +%s)
CURRENT_EPOCH=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_EPOCH - $CURRENT_EPOCH) / 86400 ))

if [ "$DAYS_LEFT" -lt 30 ]; then
    echo "WARNING: Certificate for $DOMAIN expires in $DAYS_LEFT days"
    # Send alert via email, Slack, or monitoring service
fi

Schedule this script to run daily with cron:

0 9 * * * /path/to/check-cert-expiry.sh

Using Monitoring Services

Monitoring services can also alert you to certificate problems. Configure SSL certificate monitoring so that you receive notifications when certificates are close to expiration or when validation issues occur. Infrastructure monitoring platforms can often provide this automatically.

When to Use Managed SSL vs Custom Certificates

Use the following decision framework to choose between managed SSL on load balancers or application platforms and custom or Let’s Encrypt certificates on virtual machines.

Choose DIY on Virtual Machines If

• You have a single server or a small deployment
• You need full control over certificate configuration
• Cost is the main concern and you want to avoid load balancer fees
• You are comfortable maintaining renewal automation yourself

Choose Managed SSL on a Load Balancer If

• You have multiple backend servers
• You want to move SSL processing away from application servers
• You need high availability and redundancy
• You want managed renewal without the limitations of a fully managed application platform

Choose Automatic SSL on an Application Platform If

• You are deploying containerized or serverless applications
• You want zero-configuration SSL management
• You prefer a fully managed platform experience
• You are building new applications instead of migrating existing infrastructure

Migration Path

If you are currently using DIY certificates on virtual machines, the migration path can look like this:

• To a load balancer: Create the load balancer, add the virtual machines as backend nodes, configure SSL termination, and update DNS so the domain points to the load balancer IP address.
• To an application platform: Deploy the application to the managed platform, add the custom domain, and allow the platform to manage SSL automatically.

Both migration paths remove the need for manual certificate maintenance while preserving or improving the security of your application environment.

FAQs

How do you automate SSL certificates on a cloud platform?

You can automate SSL certificates in two main ways without running certbot manually:

• Use a load balancer with SSL termination and select Let’s Encrypt. The cloud provider provisions and renews the certificate automatically.
• Use a managed application platform and add a custom domain. HTTPS and renewal are then enabled automatically.

For virtual machines, automation is usually handled with certbot and either a systemd timer or cron job.

Does a cloud provider automatically renew SSL certificates?

Yes, for managed SSL on load balancers and application platforms, cloud providers generally renew SSL certificates automatically before they expire. There is no need to configure cron jobs or run certbot yourself. For DIY Let’s Encrypt on virtual machines, you must configure the renewal timer or cron job manually.

How does SSL work on a managed application platform?

When you add a custom domain in the application settings, the platform validates ownership, provisions an SSL certificate through Let’s Encrypt, and enables HTTPS together with HTTP-to-HTTPS redirects. Renewal is automatic. No load balancer configuration or certificate upload is required, because SSL automation is built in.

Can you use custom SSL certificates on a cloud platform?

Yes. On load balancers, many providers allow you to upload a custom certificate, for example one from a commercial certificate authority, instead of using Let’s Encrypt. On managed application platforms, certificates are usually provided automatically when you add a domain. On virtual machines, you can use either Let’s Encrypt or a custom certificate with Nginx or Apache.

What happens if an SSL certificate expires?

Browsers will display security warnings and may prevent access to the site. With managed SSL on load balancers and application platforms, renewal is automatic so expiration is normally avoided. If you use DIY certbot, configure monitoring and repair the renewal process, such as by running certbot renew, or migrate to managed SSL.

Do managed certificates use Let’s Encrypt?

Yes. Both load balancer and application platform managed SSL certificates are commonly issued through Let’s Encrypt. The cloud provider handles validation, issuance, and renewal, so you do not interact with Let’s Encrypt directly.

How long does it take for SSL to activate on a cloud platform?

For load balancers and application platforms, once DNS points to the correct resource, certificate provisioning usually finishes within minutes. Full activation can still take up to 24 to 48 hours depending on DNS propagation and validation timing.

Conclusion

Managing SSL certificates does not need to remain a constant source of operational effort. While the DIY method with Let’s Encrypt and cron jobs is suitable for smaller environments, managed cloud solutions usually provide stronger reliability and less maintenance.

Load balancers with managed SSL certificates remove renewal complexity for multi-server deployments, while managed application platforms offer the easiest path through zero-configuration SSL handling. Both options automatically manage certificate provisioning, validation, and renewal.

The important part is selecting the right approach for your infrastructure. Single-server applications may still work well with DIY certificates, but as environments scale or operational simplicity becomes more important, managed solutions become increasingly useful. No matter which method you choose, implement proper security hardening with HTTPS redirects and HSTS headers.

Even when renewals are automated, monitor certificate expiration so edge cases can be detected early. Set up alerts and check your SSL configuration regularly to make sure applications stay secure and reachable.