How to renew an SSL certificate in 2026: manual steps and automation

What renewing an SSL certificate actually means

"SSL certificate" is the name everyone searches for, but the protocol it secures is TLS: SSL itself was retired years ago, and servers today negotiate TLS 1.2 or TLS 1.3. The certificate is what lets a browser trust the connection. It ties your domain name to a public key and carries a CA's signature and two dates, notBefore and notAfter. After notAfter, every mainstream client rejects it.

Renewal therefore means three things happen again:

• A key pair is chosen. Best practice is a fresh private key for every renewal, generated on the server that will use it.
• Validation is repeated. The CA confirms domain control, and for OV and EV certificates the organization as well, unless an earlier validation is still inside the allowed reuse period.
• A new certificate is issued and installed. Until the server presents it, nothing has changed for your visitors.

Why certificate lifetimes keep getting shorter

In April 2025 the CA/Browser Forum, the body of CAs and browser makers that sets the rules for public certificates, passed ballot SC-081. It shrinks both how long a certificate may live and how long a CA may reuse an earlier domain validation:

Shorter lifetimes limit how long a stolen key or a mis-issued certificate stays useful. The practical consequence is simpler: in 2029 a certificate renewed by hand needs attention roughly eight times a year, per certificate. Most teams will automate long before then, and the rest of this guide assumes you will.

Check when your certificate expires

Before renewing, confirm what is actually deployed. The certificate your CA dashboard shows is not always the one your server, load balancer or CDN presents.

• In a browser: click the site-information icon beside the address, open the certificate details and read "Valid to" or "Expires".
• From a terminal, against the live server. The -servername flag matters on shared hosting, where one IP serves many certificates:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

• From the file on disk, useful before you swap files:

openssl x509 -in /etc/ssl/example.com/fullchain.pem -noout -enddate -ext subjectAltName

Write down every host name in the subjectAltName list. The renewed certificate has to cover all of them, or a subdomain that worked yesterday will break tomorrow.

The SSL certificate renewal process, step by step

For a certificate you manage yourself (a commercial DV, OV or EV certificate, or any certificate you upload by hand), the process is the same whichever CA sold it:

1. List what the certificate must cover: the exact host names, whether you need a wildcard, and the validation level (DV, OV or EV).
2. Generate a new private key and CSR on the server, or on a secure workstation if the key is going to a load balancer.
3. Start the renewal with your CA (sometimes called a "reissue" or "renew order"), paste the CSR and choose a validation method.
4. Complete domain control validation by publishing a DNS record, placing a file on the site or answering an approval email while that is still allowed.
5. Download the issued certificate and the CA's intermediate chain. Most CAs offer a "full chain" or "bundle" file.
6. Install both on every server or service that terminates TLS for those names, then reload, not only restart, the service.
7. Verify from outside that the new expiry date and the complete chain are served, then remove the old key and certificate from disk.

Generate a new private key and CSR

OpenSSL is available on Linux and macOS and ships with Git for Windows. This creates a 2048-bit RSA key and a CSR for two names:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key -out example.com.csr \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

For modern clients an ECDSA key (-newkey ec -pkeyopt ec_paramgen_curve:prime256v1) is smaller and faster; keep RSA if you still serve very old devices. Set the key file to be readable by the web server only (chmod 600), and never email a private key or paste it into a CA's web form. On Windows Server, IIS Manager's "Create Certificate Request" wizard builds the key and CSR inside the machine's certificate store instead. For keys and other secrets in application code, see secure coding best practices.

Complete domain control validation

The CA will offer one or more of these methods. Pick the one you can repeat reliably, because at 47-day lifetimes you will be repeating it often.

Email validation is on its way out. Under the current Baseline Requirements, the email methods "SHOULD NOT" be used from March 15, 2026 and CAs must stop relying on them from March 15, 2028. If your renewals still wait on someone clicking an email, move to DNS validation now. If validation fails even though the record is in place, check for a CAA record in your DNS: it lists the only CAs allowed to issue for your domain.

Install the renewed certificate on your server

Install the leaf certificate together with its intermediates. A missing intermediate is the most common renewal mistake: desktop browsers often paper over it, while Android apps, API clients and payment providers refuse the connection.

Nginx

Put the server certificate first and the intermediates after it in one file, then point ssl_certificate at it:

server {
    listen 443 ssl;
    server_name example.com www.example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;
}

Test and reload with sudo nginx -t && sudo systemctl reload nginx. A reload picks up the new files without dropping open connections.

Apache HTTP Server

Since Apache 2.4.8, SSLCertificateFile can hold the certificate followed by its intermediates, which makes the old SSLCertificateChainFile directive obsolete:

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile    /etc/ssl/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/example.com/privkey.pem
</VirtualHost>

Run apachectl configtest, then sudo systemctl reload apache2 (or httpd on Red Hat family systems).

IIS on Windows Server

In IIS Manager, open Server Certificates and choose Complete Certificate Request (if you created the CSR there) or Import for a PFX file. Then open each site's Bindings, edit the https binding and select the new certificate. Check every binding that used the old one, including other sites sharing the same IP with SNI.

cPanel, Plesk and managed hosting

Hosting panels usually issue free DV certificates automatically (cPanel's AutoSSL, Plesk's Let's Encrypt extension). Those renew on their own as long as the domain still points at the host. For a certificate you bought elsewhere, open SSL/TLS, install the new certificate, key and CA bundle for the domain, and remove the expired entry so the panel does not keep serving it.

Load balancers, CDNs and cloud platforms

If traffic passes through a CDN or load balancer, that is where the certificate your visitors see lives, and replacing the file on the origin changes nothing for them.

• AWS Certificate Manager renews Amazon-issued certificates automatically when they use DNS validation and are in use by a service such as Elastic Load Balancing or CloudFront. Imported certificates are not renewed: you re-import the new one.
• Cloudflare renews its own edge certificates. A custom certificate you uploaded must be replaced before it expires, and the origin certificate behind Cloudflare has its own expiry date.
• Azure App Service, Google Cloud load balancers and Kubernetes ingresses each offer managed certificates. When you bring your own, the renewal is a new upload or a new secret, followed by checking which listener uses it.

Renewing a wildcard or multi-domain certificate

A wildcard certificate for *.example.com covers shop.example.com and mail.example.com, but not example.com itself (add it as a second name) and not a.b.example.com. Wildcards cannot be validated with a file on the website: the CA has to check DNS, or a contact published for the domain while email and phone methods are still allowed. So a wildcard renewal is the moment to move the domain to a DNS provider with an API your ACME client can drive.

Multi-domain certificates (also sold as SAN or UCC certificates) list each name explicitly. At renewal, compare the SAN list from your check above with what the CA will issue. Names you drop disappear from the new certificate; names you add need their own validation.

One more wildcard consideration: the same private key installed on dozens of servers is a large blast radius. With automation in place, per-service certificates are often the safer design.

Renewing a Comodo (now Sectigo) certificate

Comodo CA rebranded as Sectigo on November 1, 2018, and "Comodo" certificates bought through resellers are issued by Sectigo today. Renewal follows the same process: generate a new CSR, start the renewal in the Sectigo or reseller account, complete validation and install the certificate together with the Sectigo intermediate bundle the email or portal provides. If the reseller account has lapsed, a new order with any CA works just as well; nothing ties the domain to the CA it used before, unless a CAA record says so.

Automate SSL certificate renewal with ACME

ACME, standardized as RFC 8555, is how most certificates on the web are now renewed: a client on your server requests a certificate, answers the validation challenge and installs the result, on a schedule, without anyone logging in. Let's Encrypt is free and ACME-only, and several commercial CAs and cloud platforms offer ACME endpoints too.

Common clients:

• Certbot (EFF) for Apache and Nginx on Linux. Most installs add a scheduled certbot renew; test it with sudo certbot renew --dry-run. Since Certbot 4.0 a certificate is due once less than a third of its lifetime remains.
• acme.sh, a shell-only client with DNS API plugins for many providers, handy for wildcards.
• Caddy and Traefik, web servers and proxies that obtain and renew certificates by themselves.
• cert-manager for Kubernetes, which stores certificates as secrets and renews them before expiry.
• win-acme for IIS on Windows Server.

Three habits make automation dependable:

1. Renew early. Let's Encrypt recommends renewing with a third of the lifetime left, and checking ACME Renewal Information (ARI, RFC 9773) at least twice a day so the CA can ask you to renew sooner, for example before a revocation.
2. Reload after renewing. A new file on disk is not a new certificate in memory. Use a deploy hook (certbot renew --deploy-hook "systemctl reload nginx") so the server picks it up.
3. Monitor separately. Alert on the expiry date seen from outside, not on the renewal job's exit code. A job can succeed while a load balancer keeps serving the old certificate.

Let's Encrypt is also shortening its own certificates. Its default "classic" profile issues 90-day certificates today; an opt-in 45-day tlsserver profile started on May 13, 2026, the default moves to 64 days on February 10, 2027, and to 45 days on February 16, 2028. A client that renews on a fixed 60-day timer will break at that point, which is one more reason to rely on ARI or the one-third rule.

Verify the renewal worked

After installing, check from outside your network:

• openssl s_client (as above) shows the new notAfter date and the right issuer.
• The chain is complete: openssl s_client -connect example.com:443 -servername example.com -showcerts should list your certificate followed by its intermediate.
• Every host name on the certificate answers with the new certificate, including www and API subdomains.
• An external test such as Qualys SSL Labs reports no chain issues and only TLS 1.2 and 1.3 enabled.
• Anything that pins or caches certificates (mobile apps, partners' firewalls, payment gateways) still connects.

Common SSL renewal errors and how to fix them

If renewals keep landing on someone's calendar, that is the real problem to fix. Our hosting and maintenance service runs certificate automation and external expiry monitoring as part of looking after a site, and our security scanning flags weak TLS settings along with the rest of your exposed surface. HTTPS is also your first defence against eavesdropping attacks, which is why an expired certificate is more than a cosmetic warning. The certificate is one item on a longer list; our website security checklist covers the rest.