Stuck between one wildcard cert (*.vectel.nl) and a SAN cert with explicit subdomains
Wildcard covers any subdomain, but one cert shares private-key risk across everything. SAN (Subject Alternative Names) names explicitly which hosts are on it. For SMB with many ad-hoc subdomains wildcard wins, for strict security SAN wins.
Try this first
- 1For a small number of subdomains (3 to 10): a SAN cert is clearer and reduces blast radius on a key leak.
- 2For many or dynamic subdomains (preview deploys, customer-specific subdomains): wildcard is more practical, otherwise ACME rate limits hit daily.
- 3Wildcard covers only one level (*.vectel.nl, not *.dev.vectel.nl). For two levels you need two wildcards or a SAN.
- 4With wildcard: store the private key in a secrets manager with tight ACL, not spread across dev machines.
- 5For public websites: both wildcard and SAN are free via Let's Encrypt or ZeroSSL. EV certs are practically SAN-only.
When to bring us in
If you want a cert strategy that fits your deploy flow and risk profile, we can choose between wildcard, SAN or a mix.
See also
- Domain expires tomorrow and nobody saw the emailAn expired domain doesn't transfer instantly. There's a redemption window, but you pay extra.
- Unsure whether to enable auto-renewDisabling auto-renew only makes sense for domains you'll truly drop. For anything live, just keep it on.
- New registrar asks for auth code, can't find itEPP code or transfer code is the password to move a domain from registrar A to B.
None of the above fits?
Describe your situation below. We pass your input plus the steps you already saw to our AI and return tailored next-step advice. If it's too risky to DIY, we'll say so.
Or skip the DIY entirely
Our Managed IT clients do not look these things up. One point of contact, a fixed monthly price, resolved within working hours.