Sign in Get started
← Blog

Webflow Custom Domain SSL Not Working: The Cert Didn't Renew

By Yoni Ryabinski

When you see a “Your connection is not private” browser warning, your webflow custom domain ssl not working problem almost often stems from a failed automatic certificate renewal. Webflow manages and renews your SSL/TLS certificates automatically in the background, but when underlying DNS records change or proxy settings conflict, certificate authorities cannot verify your domain ownership and your HTTPS security lapses.

For inbox-safety context, FTC phishing guidance recommends treating unexpected messages and requests for personal information with caution.

For privacy context, FTC guidance on how websites and apps collect and use information explains why people should be careful about where they share personal contact details.

For a non-technical founder with active customers, seeing your live Webflow app or marketing site blocked by aggressive red security warnings is terrifying. Visitors assume your site has been hacked or abandoned. Fortunately, this issue is rarely caused by a broken website; instead, it is an administrative breakdown between your domain registrar, your DNS host, and Webflow's certificate provisioning engine. In this guide, we walk through exactly how Webflow SSL renewal operates, the five most common reasons renewals fail, how to isolate the exact point of failure, and how to verify your renewed certificate so you rarely get surprised by an expired site again.

How Webflow SSL Issuance and Renewal Actually Works

To fix the issue, it helps to understand what happens under the hood when Webflow provisions an SSL certificate. Webflow uses automated certificate authorities, primarily Let's Encrypt, to generate free SSL/TLS certificates for custom domains. These certificates encrypt traffic between your visitors' web browsers and Webflow's hosting servers.

Webflow uses the ACME (Automated Certificate Management Environment) protocol via HTTP-01 or DNS-01 verification challenges. Under an HTTP challenge, the certificate authority makes an automated request over the public internet to your domain at a path like /.well-known/acme-challenge/<token> . If your domain's DNS points cleanly to Webflow's servers, Webflow serves the cryptographic token, the certificate authority validates domain control, and a fresh certificate is silently deployed. Source: Webflow source. Source: Nightlamp source .

If your DNS records were modified, if a new proxy was placed in front of your domain, or if a legacy record blocks the validation query, the verification request fails. Let's Encrypt retries periodically, but if the issue remains unresolved for 30 days, your existing certificate reaches its expiration timestamp. The moment it expires, every visitor's browser instantly throws an ERR_CERT_DATE_INVALID or NET::ERR_CERT_COMMON_NAME_INVALID error screen.

The 5 Common Causes of Webflow Custom Domain SSL Failures

When an existing custom domain suddenly stops serving HTTPS, the issue almost often maps back to one of five DNS or hosting configuration mistakes. Review each suspect in order to identify what went wrong on your domain.

1. Conflicting CAA (Certification Authority Authorization) Records

A CAA record is a DNS record that tells the global internet which specific certificate authorities are allowed to issue SSL certificates for your domain. If someone on your team added a CAA record for another service—such as Google Workspace, Amazon Web Services, or DigiCert—without including Let's Encrypt, certificate authorities will strictly obey the rule and refuse Webflow's renewal requests.

When Webflow attempts to issue the cert, Let's Encrypt queries your domain's DNS for CAA records. If a CAA record exists and does not contain issue "letsencrypt.org", renewal is denied immediately. To resolve this, log in to your DNS provider (GoDaddy, Namecheap, Google Domains, Cloudflare, etc.) and check for any CAA record types. If you need CAA records active, you must add an entry permitting Let's Encrypt:

Type: CAA
Name: @ (or your root domain)
Flag: 0
Tag: issue
Value: "letsencrypt.org"

2. Proxying Through Cloudflare with Incompatible SSL Settings

Many founders route their DNS through Cloudflare to manage redirects, caching, or custom security rules. However, placing an active Cloudflare proxy (the orange cloud icon) directly in front of Webflow's default DNS setup often creates certificate renewal loops and edge-certificate errors.

If you use Cloudflare, the SSL/TLS encryption mode must be set to Full (strict). If it is set to “Flexible,” Cloudflare communicates with Webflow over unencrypted port 80 (HTTP). Webflow automatically redirects all HTTP traffic to HTTPS, causing an infinite redirect loop (ERR_TOO_MANY_REDIRECTS) or disrupting the certificate authority's challenge validation. Furthermore, if you are following standard Webflow instructions, Webflow explicitly recommends disabling the Cloudflare proxy (turning the cloud icon to “DNS only” / grey cloud) during initial setup and certificate renewal so Let's Encrypt can talk directly to Webflow's origin servers.

3. Stale AAAA (IPv6) Records Left Over from an Old Host

This is one of the most insidious and overlooked reasons for sudden SSL failures. When founders migrate an existing domain from Squarespace, WordPress, Shopify, or Vercel over to Webflow, they often remember to update the A records and the CNAME record, but forget to look for AAAA records.

AAAA records map your domain to IPv6 addresses. Modern certificate authorities and web browsers prefer IPv6 over IPv4 whenever an IPv6 record is present. If your DNS still has an old AAAA record pointing to your previous host's servers, the certificate authority will attempt to validate the renewal challenge against that old host instead of Webflow. The old host doesn't have the ACME token, the validation query returns a 404 or connection timeout, and renewal silently halts. If you host on Webflow without a specialized enterprise IPv6 routing setup, verify that your root domain contains zero AAAA records.

4. Default Domain Misalignment (Root vs. WWW Mismatch)

Webflow handles custom domains by binding two distinct hostnames: your root domain (e.g., example.com) and your subdomain (e.g., www.example.com). For standard Webflow hosting plans, Webflow requires that one of these domains be designated as the “Default” domain to avoid duplicate content penalties and routing conflicts.

In almost all cases, Webflow strongly recommends setting the www version as the default domain. When the www version is default, traffic to the root domain is redirected at the DNS edge via two A records pointing to Webflow's load balancers (75.2.70.75 and 99.83.190.102 ), while the www record uses a CNAME pointing to proxy-ssl.webflow.com . If your DNS registrar does not support CNAME flattening (ALIAS or ANAME records) and you mistakenly set the root domain as default in Webflow, SSL certificates for the root domain can fail to validate or renew properly.

5. SSL Toggled Off in Hosting Settings or Legacy IP Addresses

In your Webflow project's Site Settings under the Publishing (or Hosting) tab, there is an advanced control labeled “Enable SSL.” While this is enabled by default for modern projects, toggling custom code, adjusting client billing, or re-linking custom domains can sometimes accidentally toggle this off. If SSL is disabled in Webflow settings, Webflow stops requesting renewals altogether, serving the site strictly over insecure HTTP.

Additionally, if you set up your Webflow site years ago, your DNS might still point to legacy Webflow IP addresses (such as 34.193.69.252 or 34.193.204.92). While legacy IPs continued working for existing sites for a time, Webflow's modern SSL infrastructure and automated certificate renewals require the current routing addresses documented in the Webflow University custom domain guide.

How to Diagnose Which Layer Is Failing

When your site is down, don't make random changes to your DNS settings. DNS changes take time to propagate across global nameservers, and changing records blindly will only prolong your outage. Follow this methodical testing sequence to isolate the exact layer where the failure is happening.

Step 1: Check the Webflow Staging URL

Start by visiting your site's default Webflow subdomain: yourproject.webflow.io. Webflow automatically provisions an internal SSL certificate for all *.webflow.io domains. If your staging domain loads securely over HTTPS without any certificate errors, you know that your Webflow project, hosting plan, and asset build are healthy. The issue exists strictly in the custom domain routing layer.

Step 2: Test the Root and WWW Hostnames Separately

Open an incognito browser window and test both domain variations manually:

  • https://yourdomain.com
  • https://www.yourdomain.com

Does one variation show a valid lock icon while the other triggers a privacy warning? If www.yourdomain.com loads fine but yourdomain.com fails, your CNAME record is working, but your root A records or root domain redirect certificate has lapsed. If both fail, your primary certificate bundle or your global DNS delegation is misconfigured.

Step 3: Inspect DNS Records Using Command Line or Online Tools

You can check the live DNS records resolving across public resolvers using the dig utility in your terminal or free web-based DNS lookup tools. Run the following checks:

# Check root domain A records
dig yourdomain.com A +short

# Check for rogue IPv6 records
dig yourdomain.com AAAA +short

# Check www CNAME record
dig www.yourdomain.com CNAME +short

# Check for blocking CAA records
dig yourdomain.com CAA +short

Examine the output closely:

  • The root A query should return exactly Webflow's two IP addresses (75.2.70.75 and 99.83.190.102) and nothing else.
  • The AAAA query must return completely blank. If any IPv6 addresses appear, delete them from your registrar immediately.
  • The CNAME query should resolve to proxy-ssl.webflow.com.
  • The CAA query should either return empty or include an entry explicitly authorizing letsencrypt.org.

Step-by-Step Fix in Webflow Hosting Settings

Once you have cleaned up any errant DNS records in your registrar, follow these exact steps inside Webflow to force certificate re-issuance.

  1. Open Webflow Project Settings: Log in to Webflow, select your project dashboard, and navigate to Settings > Publishing (in older interfaces, this is under Hosting).
  2. Verify Custom Domains: Scroll down to the Custom Domains section. You should see both your root domain (example.com) and subdomain (www.example.com).
  3. Set Default Domain: Ensure that www.yourdomain.com has the green tag indicating it is the Default Domain. If it is not, hover over the www entry and click Make Default.
  4. Run Webflow DNS Check: Next to each domain name, click the small “Check Status” or refresh icon. Webflow queries your DNS in real time. Once your DNS records have fully propagated and match Webflow's requirements, Webflow provisions and deploys an SSL certificate. If an icon remains red, Webflow will show you the exact record discrepancy (e.g., unexpected IP or missing CNAME).
  5. Toggle SSL and Re-publish: Under the Advanced Publishing Options, ensure Use Secure Connection (SSL) is toggled to ON. If Webflow shows a stuck or pending certificate status, toggle SSL off, wait 30 seconds, toggle it back on, and click the blue Publish button in the top right corner. Ensure both the .webflow.io domain and custom domains are selected, then hit Publish to Selected Domains.

Publishing forces Webflow's routing layer to synchronize its reverse proxy configuration and initiate a fresh ACME challenge with the certificate authority. Once your DNS records have fully propagated and match Webflow's requirements, Webflow provisions and deploys an SSL certificate.

Confirming the New Certificate's Expiration Date

After Webflow confirms that the certificate has been provisioned, do not just assume everything is working because your browser loads the page. Your browser might still be serving cached assets or reading a local session. You should inspect the certificate metadata directly.

Open your website in Google Chrome, Microsoft Edge, or Brave:

  1. Click the site security icon in the address bar (to the left of the URL—often shown as tuning sliders or a lock icon).
  2. Click Connection is secure, then select Certificate is valid.
  3. In the certificate viewer window, review the Validity Period.
  4. Check the Issued On and Expires On dates.

If the fix worked, the certificate should show an issuance timestamp from today and an expiration date exactly 90 days in the future. If the expiration date is still today or in the past, your local machine or local ISP DNS resolver is still caching the stale certificate. You can confirm external propagation immediately using our free TLS certificate inspection tool to see what external edge servers are presenting to visitors.

Resolving Post-Renewal Warnings: Mixed Content

Occasionally, founders fix their certificate renewal only to find that the browser still warns that their site is “Not fully secure.” When a valid certificate is installed but your pages still show an insecure lock icon or broken padlock, you are dealing with mixed content. This happens when your HTML page is served securely over HTTPS, but specific embedded assets—such as custom fonts, external tracking scripts, images hosted on external buckets, or unencrypted webhooks—are being requested via insecure http:// URLs.

Modern browsers block these insecure scripts and images by default. To understand how to find and rewrite these insecure asset URLs inside your Webflow designer or CMS collections, read our detailed guide on how mixed content gets blocked after moving to HTTPS. For deeper background on domain certificate lifecycles, see our guide on what happens when an SSL certificate expires.

Why You Need Warning Days Before Expiry, Not the Morning Of

The core problem with automated certificate renewal is that it operates as a silent process. When it works, you rarely think about it. But when it fails, it fails silently for 30 days until the exact moment your website breaks. Webflow does not send an urgent SMS to your phone saying “A CAA record prevented your certificate renewal 20 days ago.” Instead, you find out on a Monday morning when a prospective customer messages you on LinkedIn saying your checkout page is dangerous.

For founders building on modern visual platforms like Webflow, Lovable, Bolt, or Bubble, infrastructure issues should not require you to become a full-time site reliability engineer. You shouldn't have to put calendar reminders every 60 days to manually check browser certificates or verify that your DNS registrar didn't add an unwanted default record.

This is why having dedicated external monitoring matters. Nightlamp monitors certificate hygiene and expiry and tells you before a certificate lapses. Instead of alerting you when your site is already down, monitoring tracks the exact validity window of your custom domain's SSL certificates, your DNS records, and your public HTTP endpoints.

When something breaks, you don't need a barrage of automated alert noise with complex stack traces. Nightlamp does not auto-remediate infrastructure on its own; a real engineer diagnoses each incident and tells you exactly what to fix. Human engineers diagnose incidents for you; Nightlamp does not just fire alerts. Led by founding engineer Yoni Ryabinski, Nightlamp acts as your on-call App Care partner—telling you in plain English that a stale AAAA record was detected or that a certificate renewal attempt failed, giving you step-by-step instructions to fix it days before any customer notices an error.

Frequently Asked Questions

How long does Webflow take to issue an SSL certificate after fixing DNS?

Once your DNS records have fully propagated and match Webflow's requirements, Webflow provisions and deploys an SSL certificate. However, DNS propagation across global resolvers can take anywhere from a few minutes up to 24 hours depending on the TTL (Time to Live) settings configured at your domain registrar. Setting your DNS TTL to 300 seconds (5 minutes) prior to making changes can significantly speed up this process.

Why does my site work on HTTP or www but show a privacy error on the root domain?

This occurs when the root domain (yourdomain.com) and the subdomain (www.yourdomain.com) are resolving to different servers, or when the certificate authority only succeeded in validating one of the two hostnames. In Webflow, this is frequently caused by having outdated A records on the root domain, missing the root domain redirect certificate, or failing to set www as the default domain in Webflow's Publishing tab. Verify both hostnames are listed in your Webflow project settings and that both pass the DNS verification check.

Can I upload my own custom third-party SSL certificate to Webflow?

No, standard Webflow hosting plans do not permit uploading custom, third-party SSL certificates. Webflow generates and manages its own certificates through Let's Encrypt automatically. If your organization requires custom enterprise certificates, private CA management, or custom EV certificates, you must either be on Webflow's Enterprise tier or front your domain with an external reverse proxy (like Cloudflare Enterprise) that handles edge SSL termination.

Why did my Webflow SSL work perfectly for three months and then suddenly break?

Webflow's SSL certificates have a 90-day expiration lifetime. When you initially connected your domain, Webflow validated your DNS records and issued a 90-day cert. If you later modified your domain's DNS settings—such as connecting an email marketing tool, changing nameservers, turning on a Cloudflare proxy, or adding a restrictive CAA record—those changes might not have affected your live site immediately. However, when Webflow attempted its automated background renewal 30 days prior to expiration, the new DNS configuration blocked the renewal verification. Once the original 90-day validity ran out, the site immediately showed certificate errors.

Don't wait for your customers to tell you that your domain's security certificate has expired. Nightlamp is a paid managed service with a 14-day free trial; plans start at $79/mo. Start your 14-day trial today at Nightlamp Pricing and let experienced engineers monitor your Webflow site, certificate lifecycles, and core flows around the clock.