If you've brought your own domain to Nodetonet, every proxy you create lives on a subdomain — sub42.yourdomain.com, sub43.yourdomain.com, and so on. Spin up ten proxies and you get ten subdomains. The platform issues exactly one wildcard Let's Encrypt certificate covering *.yourdomain.com, so every one of those subdomains is HTTPS-ready the moment it's created — no per-subdomain provisioning, no waiting on ACME challenges each time you click New Proxy.
TL;DR: One certificate, every subdomain, auto-renewed. You point your nameservers at us once, and TLS just works forever.
Why wildcard — not a certificate per subdomain
The obvious alternative is issuing a fresh certificate every time you create a proxy. It works in theory, but it creates two concrete problems:
- Slow proxy creation. Every new cert requires an ACME round-trip — typically 30-60 seconds of challenge, validation and deployment. Proxy creation blocks behind that wall.
- Rate-limit exposure. Let's Encrypt caps issuance at 50 certificates per registered domain per week. A moderately active account creating and deleting proxies can exhaust that quota in a day.
A single wildcard certificate covers an unlimited number of subdomains under one DNS name, renews on one schedule, and pre-validates any hostname before it exists. When you create sub99.yourdomain.com at 3 am, the TLS handshake just works — the certificate is already deployed to every edge server.
ACME challenge methods — HTTP-01 vs DNS-01
Let's Encrypt uses the ACME protocol to confirm you control a domain before issuing a certificate. There are two relevant challenge types:
| Challenge | How it works | Wildcard support | Requires |
|---|---|---|---|
| HTTP-01 | Let's Encrypt fetches a token file from http://yourdomain.com/.well-known/acme-challenge/ |
No — only validates the exact hostname | Public web server on port 80 for each name |
| DNS-01 | Let's Encrypt reads a _acme-challenge TXT record you publish in your DNS zone |
Yes — a single TXT record proves control of *.yourdomain.com |
Authoritative control of the DNS zone |
HTTP-01 is the most common ACME method, but it cannot validate wildcards — there is no single hostname to drop the challenge file on. DNS-01 sidesteps the problem entirely. Let's Encrypt asks us to publish a specific TXT record at _acme-challenge.yourdomain.com, then queries public DNS to verify it. Because you've pointed your nameservers to ours (see authoritative DNS), we control the zone. We write the record in milliseconds, Let's Encrypt verifies it, and we remove it — all without your involvement.
That is why delegating your nameservers to Nodetonet is a hard prerequisite for wildcard SSL. Without authoritative control of your zone we cannot write the DNS-01 challenge record on your behalf.
The issuance flow, step by step
- You add
yourdomain.comon /domains and switch its nameservers to ours. - Within roughly five minutes of the NS change propagating, the certificate-issuer job picks the domain up.
- We request a certificate from Let's Encrypt covering both
yourdomain.comand*.yourdomain.com. - Let's Encrypt returns a DNS-01 challenge. We publish the required TXT record to our authoritative nameservers.
- Let's Encrypt resolves the TXT record, confirms ownership, and issues the signed certificate.
- We deploy the certificate to every edge node. The domain row on
/domainsflips to ACTIVE — SSL OK.
Total end-to-end wall time is typically under 90 seconds from nameserver propagation.
What you see on the panel
The domain row in your panel shows the certificate's issued-at date, not-after expiry, and the Subject Alternative Name (SAN) list. Three badge states are possible:
- Green — ACTIVE: the certificate is current and deployed.
- Amber — EXPIRING: we're within 14 days of expiry and a renewal job is already queued. No action needed.
- Red — RENEWAL FAILED: the renewal attempt failed and needs your attention. This is rare; common causes and fixes are in how auto-renewal works.
If you ever need the raw certificate files — for example to pin them in a custom client or inspect the chain — the domain row has a download button that returns fullchain.pem and the encrypted private key. Treat the private key with the same care as a database password: never transmit it over plain HTTP or paste it into a chat.
Auto-renewal — nothing to configure
Let's Encrypt certificates are valid for 90 days. Nodetonet queues a renewal 30 days before expiry. The renewal uses the same DNS-01 flow as the initial issuance — we write a new challenge record, Let's Encrypt validates it, we deploy the new certificate to all edge nodes, and we delete the old one. Your proxies never experience a TLS interruption because the renewed certificate is deployed before the old one expires. If a renewal attempt fails (DNS propagation lag, temporary Let's Encrypt outage), the job retries automatically; auto-renewal covers the retry schedule and manual override.
Edge cases worth knowing
- Wildcards are single-level.
*.yourdomain.comcoversa.yourdomain.comandb.yourdomain.combut nota.b.yourdomain.com. Deeply nested subdomains would need their own certificate, which is uncommon in a proxy context. - The apex is included. The same certificate covers bare
yourdomain.com, so a landing page on the root domain won't throw browser TLS warnings. - Let's Encrypt rate limits still apply. If you delete and re-add the same domain repeatedly within a week you'll approach the duplicate-certificate limit. Give deleted domains at least a week before re-adding.
- HTTPS tunnels use the same certificate. HTTP tunnels on your custom domain benefit from the same wildcard cert — any tunnel subdomain is covered without additional steps. See monitoring your tunnel health for TLS-related health checks.
- VPN connections are unaffected. If you also run Nodetonet VPN, the wildcard certificate governs the HTTPS layer of your proxies and tunnels, not the VPN transport itself.
How this fits into the broader custom-domain setup
Wildcard SSL is one piece of a three-part custom-domain stack: nameserver delegation (so Nodetonet controls your DNS zone), wildcard certificate issuance (this post), and edge routing (SNI-based routing that directs each subdomain to the right proxy). All three are configured automatically once you add a domain — there is no manual NGINX config, no certificate upload, and no Certbot to run. See bringing your own domain for the end-to-end flow, and HTTPS proxies and SNI routing for how requests are dispatched after the TLS handshake.
Get started
Ready to add your domain? Go to the custom-domain setup guide, point your nameservers, and your wildcard certificate will be live within minutes. If you have questions, reach us at support@nodetonet.com or join discord.gg/nodetonet. You can also create a free account and explore the panel before pointing any production domain.