Cloudflare Universal SSL Renewal Failed: Edge vs Origin Checks

This article is a localized edition of the Japanese original. Read the Japanese original

Cloudflare's Universal SSL is issued and renewed automatically by Cloudflare, so when renewal stops, the cause is almost always one of these: "is the zone in an active state," "are the conditions in place for the certificate authority to issue (CAA, DNSSEC, name servers)," or "is the hostname even within the scope of Universal SSL." It is also common to mix things up, because a browser error turns out to actually be a certificate problem on the origin server. This article explains how to tell whether the problem is at the edge or at the origin, and the reasons Universal SSL renewal stops, in order of how easy they are to check.

First: is the problem the edge certificate or the origin certificate?

Two kinds of certificates are involved with a site that goes through Cloudflare.

• Edge certificate: The certificate used between the visitor's browser and Cloudflare. Universal SSL is this one.
• Origin certificate: The certificate used between Cloudflare and the origin server. A Let's Encrypt certificate installed on the origin, or a Cloudflare Origin CA certificate, is this one.

To tell them apart, look at the error that is displayed. If the browser shows a certificate error such as "Your connection is not private" and the issuer of the certificate is a certificate authority that Cloudflare uses, it is the edge side. On the other hand, if the Cloudflare error page shows 525 (SSL handshake failed) or 526 (Invalid SSL certificate), it is a problem between Cloudflare and the origin and has nothing to do with Universal SSL renewal. A 526 appears when the SSL/TLS encryption mode is "Full (strict)" and validation of the origin's certificate fails because it is expired, the hostname does not match, or the like.

Also, a hostname whose DNS record has the proxy disabled (gray cloud) does not go through Cloudflare, so the edge certificate is not used. If a certificate error appears on that hostname, check the origin server's certificate.

The following commands are handy for checking, from your own machine, the certificate that is actually being served.

# Issuer, expiry, and covered hostnames of the certificate being served
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -enddate -ext subjectAltName

# Whether DNS points to Cloudflare's proxy (whether a Cloudflare IP is returned)
dig +short example.com

Cause 1: The hostname is outside the scope of Universal SSL

Universal SSL covers the zone apex (example.com) and first-level subdomains (*.example.com, for example www.example.com). Subdomains two or more levels deep, such as dev.app.example.com, are not included.

If a certificate error appears on a proxied second-level subdomain, renewal did not fail; it was never covered in the first place. Handle it in one of the following ways.

• Change to a first-level hostname (such as dev-app.example.com)
• Issue a certificate that includes that hostname with the paid Advanced Certificate Manager (the Total TLS feature is included in this)
• Upload a certificate you obtained yourself as a custom certificate (availability differs by plan)

Which features are available on which plans can change, so check Cloudflare's official documentation (as of October 2026).

Cause 2: The zone is not Active, or the name servers have been removed

With a full setup (the method of pointing your name servers to Cloudflare), Cloudflare uses its own authoritative DNS to complete the certificate authority's domain control validation (DCV) automatically. For this reason, renewal cannot happen in the following states.

• At the registrar, you changed the name servers back to something other than Cloudflare, or you mixed in a different DNS for only some of them
• The zone's status is pending (waiting for the name server change), or it was left as moved
• The domain is close to expiring and has been suspended by the registrar

Check both by looking at the status in the zone overview on the dashboard and by looking up the name servers from outside.

dig +short NS example.com
whois example.com | grep -iE "name server|expir"

It is normal if only the two Cloudflare name servers assigned on the dashboard are returned.

With a partial (CNAME) setup, DNS is managed somewhere other than Cloudflare, so Cloudflare cannot complete DCV automatically. You need to add the TXT record that the control panel instructs, and the CNAME record for DCV delegation, on the side of the DNS provider you use. There are cases where a record that was added earlier was deleted during a DNS cleanup, and the next renewal stopped.

Cause 3: The CAA records do not allow Cloudflare’s certificate authority

A CAA record is a mechanism that specifies "the certificate authorities that may issue certificates for this domain." Universal SSL is issued from several certificate authorities, such as Let's Encrypt and Google Trust Services (the authority used can change), so if CAA allows only specific authorities, issuance is not possible.

dig +short CAA example.com

If nothing is returned, there are no restrictions, so this is not the cause. When CAA exists, Cloudflare has a mechanism that automatically adds the CAA for the certificate authorities needed for Universal SSL, but if you manage CAA by hand in detail, or have placed separate CAA records on subdomains, check in the DNS settings on the dashboard and the SSL/TLS edge certificates screen that the authorities Cloudflare uses are permitted.

Cause 4: DNSSEC misconfiguration

If DNSSEC is enabled and the DS record registered at the registrar does not match Cloudflare's current key, validating resolvers can no longer resolve the domain. Certificate authorities also validate DNSSEC, so DCV and CAA checks fail. A typical cause is leaving the old provider's DS record at the registrar when you moved DNS to Cloudflare.

# Whether it resolves with validation (if SERVFAIL, suspect a DNSSEC mismatch)
dig example.com @1.1.1.1 +dnssec
dig +short DS example.com

If there is a mismatch, either re-register the DS record value shown on the Cloudflare dashboard at the registrar, or disable DNSSEC at the registrar first and then redo the setup. Changes to DS records take time to take effect, so allow plenty of time for the work.

Cause 5: Universal SSL is disabled, or the status is stuck pending

On the SSL/TLS "Edge Certificates" screen of the dashboard (the wording may change), check whether Universal SSL is enabled and whether the certificate's status is active. If the status stays stuck at pending validation, resolve Causes 2 to 4 above first.

You can also check the status of the certificate pack through the API. Give the token read permission for SSL only, and do not leave the value in code or in a public repository.

curl -s "https://api.cloudflare.com/client/v4/zones/your-zone-id/ssl/certificate_packs" \
  -H "Authorization: Bearer your-api-token" | jq '.result[] | {type, status, hosts}'

If you disable Universal SSL and then enable it again, the certificate is reissued, but the moment you disable it the edge certificate disappears, and HTTPS access may become unavailable until the new certificate becomes active. Treat it as a last resort when removing the cause does not get things moving, and it is safer to do it during hours with little traffic, or to first check the status with Cloudflare support or the community.

Operations to keep renewal from stopping

• When you change DNS providers or registrars, or change DNSSEC or CAA, check the edge certificate's status and the expiry date with openssl the same day
• When you create new subdomains two or more levels deep, design on the assumption that they are outside the scope of Universal SSL
• With external monitoring, watch the expiry dates on both the edge side (example.com) and the origin side (checking the origin's hostname or IP with -servername added)

Summary

• First, work out whether the error is the edge certificate or the origin's certificate. 525 and 526 are origin-side problems and separate from Universal SSL renewal.
• The scope of Universal SSL is the apex domain and first-level subdomains; two or more levels deep is not covered.
• The main reasons renewal stops are: the zone is not active or the name servers have been removed, CAA restrictions, DNSSEC mismatch, and lost DCV records in a partial setup.
• Disabling and re-enabling Universal SSL can make HTTPS temporarily unavailable, so keep it as a last resort.

• How to use a Cloudflare Origin CA certificate with WordPress
• What to do when WordPress shows a Cloudflare 525 error

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)