Custom Domain and Automatic SSL: Setup and Troubleshooting

Most custom domain automatic SSL trouble looks like one of five things. Match what you see to a row, then run the check.

A pending certificate is often not a fault in custom domain automatic SSL. New domains wait briefly for DNS to be seen. It only becomes a problem when it stays pending after the record is right.

DNS records say where a name leads, and there are two shapes of name to point.

A subdomain, such as www.example.com or app.example.com, can take a CNAME. That record says this name is an alias of another, so the target can move without you touching anything.

The apex, also called the bare or root domain, is example.com with nothing in front. It cannot take a CNAME, because a CNAME must be the only record on its name and the apex already holds the zone's SOA and NS records. So providers offer an A record to a fixed IP address, or an alias feature, sold as ALIAS, ANAME or CNAME flattening, that resolves the target for you. Which you get depends on your DNS host.

• CNAME: subdomains only. Follows the target wherever it moves.
• A record: an IPv4 address. Works anywhere, breaks if the address changes.
• ALIAS, ANAME or flattening: apex-friendly, but only where your DNS host supports it.
• AAAA record: an IPv6 address. Delete stale ones, because a forgotten AAAA sends some visitors to an old server.

Then the TTL: the time in seconds that resolvers may cache an answer. Lower it to 300 an hour or more before a change, then raise it again afterwards. A TTL of 86400 leaves some visitors on the old answer for up to a day. That is what people call propagation. Nothing is spreading. Old answers are simply expiring.

The protocol behind nearly all automatic SSL for a custom domain is ACME. A client asks a certificate authority for a certificate, the authority sets a challenge to prove you control the name, and the client answers it. Let's Encrypt describes the goal as browser-trusted certificates with no human intervention. That only works if the challenge can complete unaided.

Two challenge types matter for a custom domain.

• HTTP-01: the authority fetches a token from a well-known path over plain HTTP. It works only on port 80, follows up to ten redirects, and cannot issue wildcard certificates.
• DNS-01: you publish a TXT record under _acme-challenge. It can issue wildcards, and you can delegate the challenge name to another zone with a CNAME. It is slower, because it waits on DNS.

For a plain hostname on a hosting platform, HTTP-01 is the usual route. The platform answers on port 80 once your record points at it, which is why the record has to be right first.

Certificates behind custom domain automatic SSL are shorter than they used to be, and getting shorter on a fixed schedule. The CA/Browser Forum, which sets the rules public certificate authorities follow, passed ballot SC-081v3 to cut the maximum lifetime of a public TLS certificate from 398 days to 47 days between March 2026 and March 2029. The steps are 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029.

Let's Encrypt is moving faster than the minimum. It issues 90-day certificates today. It opened an optional profile for 45-day certificates on 13 May 2026, and plans to make 64 days the default on 10 February 2027 and 45 days the default on 16 February 2028.

Manual renewal stops being realistic, which is why custom domain automatic SSL matters. Let's Encrypt advises renewing at roughly two-thirds of a certificate's life and alerting on renewal failures. If you run your own proxy, as in self hosted Supabase, the renewal is yours to watch.

Failed issuance is nearly always one of four causes.

• A proxy in the way. If your DNS host proxies the record, the authority reaches the proxy, not your app. Turn the proxy off for the validation, or use DNS-01.
• A CAA record that excludes the authority. CAA records name which authorities may issue. The check starts at the exact name and climbs to the parent, stopping at the first record it finds. A CAA on the parent that lists only another authority blocks the lot.
• Port 80 closed, or a redirect that leaves. HTTP-01 needs an answer on port 80. A firewall rule, or a blanket redirect to a different host, breaks it.
• DNS not yet seen. A negative answer cached from before you created the record can delay things by the time the zone's negative-caching value says.

One more from the CAA guide: if the CAA lookup itself errors, the authority cannot tell whether it may issue, so it does not. A DNS outage can look like a permission problem.

Swap example.com for your own name. Run these in order.

1. 1Ask DNS what it saysRun dig +noall +answer www.example.com A and the same for AAAA and CNAME. The second column is the TTL. If the answer is not what you set, either the record is wrong or you are seeing a cached answer.
2. 2Ask a different resolverRun dig @1.1.1.1 +noall +answer www.example.com and then dig @8.8.8.8 +noall +answer www.example.com. Different answers mean caching, and time will fix it. Wrong answers everywhere mean the record is wrong.
3. 3Check who may issueRun dig +short example.com CAA and the same for www.example.com. No output means no restriction. Output that lacks your authority, for Let's Encrypt written as 0 issue "letsencrypt.org", is your answer.
4. 4Check port 80 answersRun curl -I http://www.example.com/.well-known/acme-challenge/test. A 404, or a redirect to HTTPS on your own host, is fine. A timeout means a firewall or wrong address.
5. 5Read the handshakeRun curl -vI https://www.example.com. Look for the lines that name the certificate subject, the issuer and the expire date. An untrusted or mismatched certificate fails here in plain words.
6. 6Read the certificate itselfRun openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -dates -ext subjectAltName. The -servername flag matters: without it, you may be shown a default certificate. Check the names include your host and notAfter is in the future.

If steps 1 to 4 are right and step 6 still shows the wrong certificate, the platform has not finished issuing.

Custom domain automatic SSL on Helm7 starts when you attach a hostname to a Product with helm7 domain add or the domain_attach operation. It returns the DNS record to create. The domain reads as pending until that record resolves, and pending is not an error. The certificate then issues on its own, usually within a minute.

A subdomain such as www.example.com or app.example.com takes a CNAME. A bare domain such as example.com takes an A record to a fixed address, which works at any DNS provider, and by default redirects to www.example.com, which is attached with it if it is not already. Pass serve: true and the bare domain answers itself. That suits a webhook, because a redirect drops the body of a POST for clients that do not follow it.

domain_list shows the record each domain expects and its certificate status. Our quickstart says nothing is broken until the record is right and the domain is still pending an hour later. Custom domains are billed as a monthly rate per hostname beyond the ones your plan includes, listed on the pricing page. The quickstart has the full command sequence.

Custom domain automatic SSL is not the same as unwatched. Alert on days to expiry, not only on the outage. A certificate below a third of its life means renewal has been failing for a while.

Re-run the CAA and AAAA checks whenever you change DNS provider. Those are the records that were right last year. Our guide to hosting a Next.js app puts the domain step in context.