Wildcard SSL vs Single-Domain SSL: Which Certificate Should You Choose?

A TLS certificate must cover the hostname a visitor opens. A single-domain certificate, wildcard certificate and multi-domain certificate solve different naming problems. The best choice is the smallest manageable scope that covers the real services and can renew reliably.

What a certificate does

TLS encrypts traffic and lets the browser verify that the server presents a certificate valid for the requested hostname and trusted chain. It does not prove that every business claim is true, remove malware or secure an outdated application.

Single-domain certificate

This covers the named hostname or set explicitly included by the product. Check whether both example.ie and www.example.ie are included; they are different names. Single-name scope limits the impact of one private key and is straightforward for isolated services.

Wildcard certificate

A wildcard such as *.example.ie covers one level of subdomains, such as shop.example.ie and mail.example.ie. It does not normally cover example.ie itself unless that name is separately included, and it does not cover deeper names such as a.b.example.ie.

Wildcard issuance under ACME requires DNS-01 validation. That means the certificate system must prove control through DNS. Protect DNS API credentials carefully and scope them where the provider permits.

Multi-domain certificate

A Subject Alternative Name certificate can list several exact hostnames, potentially across different domains. It is useful for a related group but exposes the full name list in certificate transparency and couples renewal: a validation failure for one name can affect the set.

When a wildcard helps

• many first-level subdomains are created regularly;
• a controlled platform can secure and rotate the private key;
• DNS automation is available and protected;
• the organisation accepts the broader key scope.

When separate certificates are safer

• services belong to different teams or providers;
• private keys should not be shared;
• only a few stable names exist;
• failures should be isolated;
• automatic HTTP validation is simpler than DNS automation.

DV, OV and wildcard describe different dimensions

Domain Validation checks control of a domain. Organisation Validation adds checks of organisation information under certificate authority rules. “Wildcard” describes hostname scope, not organisational assurance. Choose validation and scope separately according to customer, technical and procurement needs.

Private-key risk

A wildcard key copied to many servers becomes a high-value secret. One compromise can impersonate every covered first-level hostname. Prefer central termination or separate certificates where practical. Never email private keys, commit them to source control or leave unencrypted copies in shared folders.

Renewal is part of the design

Certificates expire. Automate renewal and monitor the actual public endpoint. Confirm that renewed certificates are deployed, not merely issued. For DNS-01, keep API credentials valid but least-privileged. For HTTP validation, keep challenge routes reachable.

Certificate Transparency

Publicly trusted certificates are normally recorded in Certificate Transparency logs. Names in a multi-domain certificate can become publicly discoverable, so do not put secret project names into public certificates. Monitor logs for unexpected issuance as an extra signal, not a substitute for account security.

Load balancers and multiple servers

Every endpoint serving a hostname must present a valid certificate. Central termination can simplify renewal, while end-to-end encryption may require internal certificates too. Avoid copying one private key to unmanaged servers. Document where TLS terminates and how deployment is verified.

Revocation and incident response

If a private key may be exposed, replace it, issue and deploy a new certificate everywhere, and revoke the affected certificate according to the authority’s process. Investigate the exposure. Renewal is insufficient when the compromised key is reused.

CAA and DNSSEC

CAA records can specify which certificate authorities may issue for a domain. Incorrect CAA can block renewal, so review it before switching issuer. DNSSEC protects DNS authenticity but does not replace TLS; both need correct lifecycle management.

Inventory before purchase

1. List every public hostname and environment.
2. Separate production, staging and internal systems.
3. Identify who controls DNS and servers.
4. Choose validation method and automation owner.
5. Decide whether key sharing is acceptable.
6. Set expiry monitoring and incident rotation.
7. Test the complete chain and redirects after deployment.

Common mistakes

• buying *.example.ie but forgetting the apex domain;
• assuming it covers multiple subdomain levels;
• installing a certificate without intermediate certificates;
• sharing one wildcard key across unrelated vendors;
• renewing but failing to reload the server;
• leaving HTTP assets that cause mixed content;
• treating HTTPS as application security.

Choose with Hoster

Many hosting setups support automated domain-validated certificates. When organisation validation or wildcard scope is required, compare current options on Hoster’s SSL page. Review hosting plans for the destination and read the complete HTTPS guide. If the hostname architecture is complex, ask Hoster before ordering.

Official sources

• Let's Encrypt challenge types
• Let's Encrypt TLS glossary
• CA/Browser Forum TLS Baseline Requirements
• Let's Encrypt CAA guidance