A Certificate for Every Subdomain

Certificates cover names, not sites

A certificate is issued for specific names and secures those names only.

So a certificate issued for your main domain does nothing for a subdomain, even though both are obviously the same business.

The browser is comparing the name it asked for against the names in the certificate, and anything not listed produces a warning.

That warning is severe, full-page, and reads as though the site is dangerous, which loses whoever encountered it.

Where subdomains come from

• A booking system on its own name.
• A shop or a portal.
• A staging site nobody removed.
• Mail on its own subdomain.
• Something a supplier set up years ago.

The third is the common one. A staging or development subdomain left running with an expired or missing certificate is both a warning waiting to happen and a page nobody has looked at in two years.

What a wildcard actually covers

Which is more limited than the name suggests.

A wildcard certificate covers any single level of subdomain: the booking one, the shop one, and anything else at that level.

It does not cover a second level, so a subdomain of a subdomain is not included.

And it does not automatically cover the bare domain itself, which surprises everybody, so that name has to be listed separately in the same certificate.

Most certificates issued today do include both, and it is worth confirming rather than assuming.

Where your main site shows a warning and the subdomains do not, that is exactly this.

A worked example

A business had a booking subdomain set up by a supplier three years earlier.

Their main site had a certificate that renewed automatically and the booking subdomain did not.

Customers clicking through from the site to book were meeting a full-page security warning, and a proportion of them stopped there.

Nobody had reported it, because a customer who sees that warning assumes the business is compromised and leaves rather than telephoning.

The fix was including the subdomain in the automatic renewal, which took their host twenty minutes.

Bookings rose noticeably afterwards, which is how they learned how long it had been broken.

Check every name you use

Which is the practical exercise.

List every address that a customer might reach: the bare domain, the www version, and every subdomain.

Open each one and look for the padlock, or for a warning.

Include any spare domain that redirects, since a redirect from an insecure domain still shows a warning before it redirects.

That last one catches people, since the redirect appears to work when you type the address without the protocol.

Ten minutes covers every name a business of this size is likely to have.

Write the list down, since the same names come up in the DNS check.

Automatic renewal is the actual answer

Since certificates are short-lived now.

Free certificates renew every ninety days, which is far too often for anybody to do manually.

Almost all hosting handles that automatically, and the failures happen when a name is added later and not included in the automatic process.

So the question to ask your host is not whether certificates renew but whether every one of your names is in the renewal.

That is a one-line question with a definite answer.

Ask it whenever a subdomain is added, which is precisely when the gap gets created.

Whoever adds the subdomain is rarely the person thinking about certificates.

Remove what you do not need

Which is frequently the better fix.

A staging subdomain, an old portal, or a supplier's leftover is a name to remove rather than a certificate to buy.

Each one is a certificate to maintain, a page that can go wrong, and occasionally something exposed that should not be public.

Removing an unused subdomain takes minutes and reduces the surface permanently.

Do that before deciding you need a wildcard, since the answer is frequently that you have two subdomains rather than seven.

You probably do not need to buy one

Worth saying plainly, since this is a sold product.

For a small business site, free automatically renewing certificates covering the exact names you use are entirely sufficient.

A paid certificate offers warranties and validation levels that make no visible difference to a customer.

A wildcard is worth buying only where subdomains are created frequently enough that listing each one is a burden.

Most small businesses have three names in total and never need one at all.

Count yours before anybody sells you the alternative.

The warning is worse than no site at all

Worth understanding, since it changes how urgent this is.

A page that fails to load reads as a technical problem, and a full-page security warning reads as a business that has been compromised or is untrustworthy.

Browsers deliberately make it difficult to continue past one, with an extra click behind an advanced option, and most people do not look for it.

So a subdomain with a certificate problem is not degraded, it is closed, and the visitor leaves with a worse impression than if it had simply been offline.

That is why this belongs on the blocking list rather than among the things to get to eventually.

The counter-case

Wildcards have real uses.

A business generating subdomains programmatically, such as one per client, genuinely cannot list them individually.

Some environments also make the automatic validation for a wildcard easier than managing many separate certificates.

And a warning on a staging subdomain nobody visits is genuinely not urgent, whatever a security scanner says about it.

Remove that subdomain rather than certifying it, which resolves the finding and the risk together.

List every name you use, open each and check for a warning, remove the ones you do not need, and confirm the rest are in the automatic renewal.

The ten minutes

1. List every name in use.
2. Include the bare and www versions.
3. Include redirecting domains.
4. Open each and look for a warning.
5. Remove unused subdomains.
6. Ask whether all are in the renewal.
7. Recheck when adding one.

Step three catches the case people miss entirely, since a spare domain redirecting to your site still shows a full-page warning before the redirect happens.

The wider question is covered in https on every page, not most of them.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.