Automatic SSL for custom domains means a TLS certificate is issued the moment DNS verification passes, with zero action from the customer — no CSR to generate, no certificate file to upload, no renewal to track. A domain that's verified but uncertified isn't done. It's a browser warning waiting for the customer's first visitor.
What does "automatic SSL" mean for a customer domain?
Automatic SSL is the second half of a domain connection, not an optional add-on to it. Once a platform confirms a customer owns a domain — the DNS verification step — the domain needs a TLS certificate before it can serve traffic over HTTPS. Automatic means that certificate is requested, issued, installed, and renewed without the customer ever seeing a certificate file, and without an engineer manually running the request. For the mechanics of how that issuance actually works — the ACME challenge, the certificate authority handshake, the renewal cycle — see how to automate TLS for customer domains and the on-demand TLS glossary entry.
Why does automatic issuance matter more than verification alone?
Verification answers "does this customer own this domain?" It doesn't answer "can a browser trust a connection to it?" Those are two different guarantees, and a platform that solves only the first one ships a domain that looks connected in the dashboard and shows a certificate error to every actual visitor.
Manual certificate issuance breaks in predictable ways at scale:
- The gap between verified and secured becomes visible downtime. A customer announces their new domain, sends traffic to it, and visitors hit "your connection is not private" because the certificate request is sitting in a queue.
- Renewal is a recurring liability, not a one-time task. Certificates expire — most commonly every 90 days under current CA baseline requirements — and a manual process has to remember every domain, every time, forever.
- One certificate authority outage or misconfigured renewal script takes down every domain behind it at once, because manual systems tend to batch renewals instead of handling each domain independently.
Who carries this risk?
A platform engineer or CTO running a handful of customer domains can track certificate expiry on a spreadsheet and survive. A multi-tenant SaaS platform, a site builder, or a PaaS offering customer-facing custom domains as a feature can't — every new domain a customer connects is another certificate that needs issuing on day one and renewing on a fixed clock, indefinitely, for as long as that customer stays. The math doesn't stay linear: more customer domains means more renewal dates to track, more certificate authority rate limits to manage, and more chances for one expired certificate to become a support escalation.
Agencies and white-label resellers managing a client-domain book inherit this the same way they inherit DNS — they're the ones who hear about it first when a client's site throws a certificate warning, often before the platform's own monitoring catches it.
Why does this need fixing now, not after the first incident?
Certificate expiry doesn't degrade gracefully — a domain is either secured or it isn't, and the failure is binary and visible to every visitor at once. Manual or semi-manual issuance tends to work fine at low volume and then fail all at once when a renewal is missed, a rate limit is hit, or a certificate authority changes a requirement. By the time it fails, it's an incident, not a backlog item. Fixing it before the first expired-certificate ticket is materially cheaper than fixing it after.
What's the cost of leaving certificate issuance manual?
The direct cost is broken domains at exactly the moment a customer is showing their new domain to their own customers — the worst possible time for a certificate error. The support cost is every "my domain shows a security warning" ticket, which reads as a platform reliability failure even when the root cause is a missed renewal. The engineering cost is the ongoing maintenance of a renewal system that has to scale with every new customer domain, not just the ones that existed when it was built. And there's a churn signal underneath all of it: a customer whose custom domain doesn't work reliably is a customer questioning whether the platform is production-ready.
How do you fix it?
DIY hardening means automating certificate requests against a certificate authority's ACME endpoint the moment DNS verification passes, storing renewal dates per domain, and running a renewal job with enough lead time and retry logic to survive a failed attempt — plus handling apex-domain and CNAME edge cases, covered in apex domain vs. CNAME, and multi-tenant certificate architecture in multi-tenant TLS.
The managed-layer path removes the renewal system as something the platform's team owns at all: certificates issue automatically on verification, typically within about 30 seconds, renew on their own schedule, and fail closed if anything's wrong — meaning no unapproved hostname is ever served, verified or not. Zero customer action, zero renewal calendar for the platform to maintain.
Connecting more than a handful of domains? Talk to us.
Score your whole flow on the 9-check grader: customdomain.ai/domain-onboarding-grader.
Frequently asked questions
Does DNS verification automatically trigger SSL issuance?
It should, but it doesn't by default in most self-built systems — verification and certificate issuance are separate steps that have to be explicitly wired together. See how to automate TLS for customer domains for the mechanics of connecting the two.
How often do TLS certificates need to renew?
Most publicly trusted certificates are valid for around 90 days under current CA/Browser Forum baseline requirements, which means a platform running its own issuance needs a renewal job that fires reliably, per domain, on that cycle — indefinitely.
What happens if a certificate expires before it renews?
Visitors hit a hard browser warning — the domain is effectively down for anyone trying to reach it over HTTPS, even though DNS still resolves correctly. It's one of the more visible failure modes in customer-domain onboarding because it looks like the platform is broken, not just the certificate.
Can one platform issue certificates for hundreds of different customer domains?
Yes, with multi-tenant TLS architecture designed for it — see multi-tenant TLS for how certificate issuance and serving scale independently of the DNS layer.