SSL Certificate Renewal Checklist for Agencies: 12 Steps Before Every Renewal
SSL certificate renewal sounds straightforward: the renewal fires automatically, or you get a reminder and click renew, and the certificate updates. For individual developers managing their own projects, this usually works. For agencies managing 20–50 client domains across Shopify, Webflow, Netlify, Vercel, and WordPress hosting — the failure modes are different, and they occur more often than most agencies expect.
The most common pattern: the renewal process completes successfully from the platform's perspective, but the renewed certificate is invalid in practice because an underlying DNS or chain condition that existed before renewal wasn't caught first. The platform issues a new certificate. The new certificate is issued against a CNAME target that changed two months ago. The site throws a security error that a fresh certificate was supposed to fix.
This checklist exists to prevent that. Run it before every renewal, not after.
Pre-Renewal Checklist (Run Before the Renewal)
1. Verify the CNAME delegation is still intact
SSL certificates for custom domains on hosted platforms (Netlify, Vercel, Shopify, Webflow) are provisioned via ACME DNS challenges against the CNAME target. If the client's CNAME record has drifted — changed registrar, IT migration, accidental deletion — the renewal will either fail outright or issue a certificate that doesn't validate correctly against the current DNS state.
Check: dig CNAME clientdomain.com — confirm the CNAME target matches the platform's expected endpoint.
For Netlify, expect a target pointing to [site].netlify.app or Netlify's load balancer. For Vercel, cname.vercel-dns.com. For Shopify, shops.myshopify.com. For Webflow, proxy-ssl.webflow.com.
If the CNAME target has changed or is missing, fix the DNS record before initiating renewal.
2. Confirm the DNS record is propagated at multiple resolvers
A CNAME fix applied at the registrar can take minutes to hours to propagate depending on TTL settings. If you've recently corrected a CNAME, verify propagation at multiple resolvers before triggering the renewal.
Check: dig @8.8.8.8 CNAME clientdomain.com and dig @1.1.1.1 CNAME clientdomain.com — both should return the correct CNAME target before you proceed.
3. Verify the domain registration expiry is not within 30 days
SSL certificate renewals are independent of domain registration renewals — but a domain registration that expires during or shortly after an SSL renewal creates a window where the renewed certificate is valid but the domain is offline. Clients frequently forget domain renewals. Check registrar expiry before renewing SSL.
Check: whois clientdomain.com — note the registration expiry date and alert the client if it is within 60 days.
4. Check the current certificate's issuing CA and chain
Know what you're renewing before you renew it. The current certificate's issuing CA determines which intermediate chain the renewed certificate will use. If the platform has changed its certificate authority — moving from Let's Encrypt R3 to E1, or from DigiCert to Google Trust Services — the renewed certificate may use a different intermediate that some systems do not cache.
Check: openssl s_client -connect clientdomain.com:443 -showcerts — note the full chain and the issuing CA before renewal.
5. Confirm subdomains that share the SAN are all still live
Some SSL certificates cover multiple subdomains via Subject Alternative Names (SAN). If the certificate covers www.clientdomain.com, api.clientdomain.com, and staging.clientdomain.com, all three subdomains need to be resolvable at renewal time. A SAN subdomain that was decommissioned but not removed from the certificate scope can cause renewal to fail or issue an incomplete certificate.
Check: Verify every subdomain listed in the current certificate's SAN is still DNS-resolvable and intentionally in scope.
6. Review CAA records — confirm the platform CA is authorized
CAA (Certification Authority Authorization) records at the DNS zone level control which certificate authorities are permitted to issue certificates for the domain. If a client's DNS has CAA records that restrict issuance to a specific CA (common on enterprise-managed DNS), and the platform is using a different CA, the renewal will fail.
Check: dig CAA clientdomain.com — if CAA records exist, verify that the platform's CA (Let's Encrypt, DigiCert, etc.) is listed.
Renewal Execution
7. Initiate renewal with the correct certificate scope
For platform-managed certificates (Netlify, Vercel, Shopify), initiate renewal from the platform's domain management UI. Confirm you are renewing the certificate for the correct domain — not a test domain or a staging subdomain. For manually managed certificates, confirm the CSR uses the correct CN and SANs before submission.
8. Monitor for platform-side provisioning completion
Platform-managed certificate provisioning can take 5–20 minutes for ACME validation. Do not assume the renewal is complete because the UI shows the process as initiated. Wait for the platform to confirm the certificate has been provisioned — and note the new expiry date.
Post-Renewal Verification (Run After the Renewal)
9. Verify the new certificate is live at the domain
After the platform confirms provisioning, verify that the renewed certificate is being served — not a cached version of the old one.
Check: openssl s_client -connect clientdomain.com:443 </dev/null 2>/dev/null | openssl x509 -noout -dates — confirm the notAfter date matches the new certificate, not the old one.
10. Validate the full certificate chain
A renewed certificate with a broken intermediate chain will pass an expiry check but fail in some browsers and HTTP clients. Full chain validation requires checking that the chain terminates correctly.
Check: openssl s_client -connect clientdomain.com:443 -showcerts — confirm every certificate in the chain is present and the chain terminates at a trusted root.
11. Test HTTPS on all subdomains covered by the certificate
If the certificate covers multiple subdomains via SAN, test HTTPS on each one — not just the primary domain. A renewed certificate that validates correctly on the apex but not on www. or api. means the SAN coverage changed during renewal.
Check: curl -I https://www.clientdomain.com and any other subdomains in the certificate scope — confirm HTTPS returns 200 or 3xx, not SSL errors.
12. Update your monitoring records with the new expiry date
If you are tracking SSL expiry manually in a spreadsheet or project management tool, update the expiry date for the renewed certificate immediately after renewal. An unchanged record will fire a false-early alert at the old expiry date.
If you are using automated SSL monitoring, verify that the monitoring tool has picked up the new certificate and is tracking the new expiry date — most tools refresh certificate data on the next scheduled check, but confirm this within 24 hours of renewal.
The Most Common Agency Renewal Failures
Failure mode 1: Renewal succeeds but CNAME was already broken The platform issues the certificate but the DNS validation uses cached records. The renewed certificate is issued, the platform dashboard shows it as active, but the live CNAME is pointing to a decommissioned platform endpoint. The renewed certificate is invalid against the current DNS state. The site throws SSL errors within the renewal window.
Prevention: Step 1 (CNAME verification before renewal).
Failure mode 2: Renewal succeeds but chain is incomplete The renewed certificate is valid and unexpired, but the intermediate chain is missing or truncated. Some browsers serve content because they cache the intermediate from the previous certificate. Others — older mobile browsers, API clients, custom HTTP clients — reject the incomplete chain. The issue appears as "SSL error on some devices" rather than a uniform failure.
Prevention: Step 10 (post-renewal chain validation).
Failure mode 3: Domain expiry during the new certificate's validity window The SSL certificate renews successfully with a 90-day validity window. The domain registration expires 45 days into that window because the client didn't renew it. The domain goes offline, and the agency is blamed for "the SSL renewal not working."
Prevention: Step 3 (domain registration expiry check before renewal).
Failure mode 4: CAA record blocks renewal mid-cycle A client's IT team adds CAA records to "secure" the domain without notifying the agency. The existing certificate (issued before the CAA records) is valid. At the next renewal, the platform's CA is not listed in the CAA record. The renewal fails. The existing certificate expires. The site goes HTTPS-broken.
Prevention: Step 6 (CAA record review before renewal).
Automating the Checklist
Steps 1, 2, 3, and 9–12 on this checklist are checkable programmatically. The manual work in agency SSL renewal is in the judgment steps: verifying CNAME targets match platform expectations, checking CAA records for correctness, and reviewing SAN scope against what subdomains are actually in use.
Merlonix runs CNAME integrity checks, full SSL chain validation, and domain registration expiry tracking continuously across your entire client portfolio. The monitoring catches the conditions in steps 1, 2, 3, and 9–12 on a 5-minute interval — not just before each renewal, but at all times.
Start a free 14-day trial — no credit card required.
→ Related: Monthly SSL and DNS Audit for Agencies → Related: Agency SSL Monitoring Checklist: 15 Checks for Every Client Portfolio → Related: DNS Record Audit Template for Agencies → Related: How Agencies Handle Client SSL Certificate Responsibility