What websites (URLs) can be protected by one SSL certificate?
For example, www.security.hsbc.co.uk has a SSL certificate. Can this certificate be used to protect other websites (URLs)? Something that branches off from this one maybe?
9
-
2@Ghedipunk SSL certificates only serve to verify the identity of the server, so I think in this context, "protect" can only mean that. – Mike Ounsworth Oct 23 at 21:06
-
2I think your title could be made clearer. Is your question: "how many websites can be protected by a single certificate" or "what websites can be protected by a certificate"? Because the answers are "depends, with reasons" and "all of them" respectively. I can't tell which question you are asking. – zero298 Oct 24 at 12:26
-
1Websites aren't protected by certificates. Certificates enable secure connections. – user207421 Oct 24 at 23:41
31
If you view the certificate in your web browser, you should be able to find the certificate subject alternative name value for the certificate. This will show a list of all of the sites that can be secured using this certificate, in addition to the site shown in the common name for the certificate. You may see wildcard values used in some of the names, such as *.hsbc.co.uk or *.security.hsbc.co.uk.
As an example, if you look at the certificate protecting this page, you'll see that Stack Exchange uses one certificate for all their sites:
Firefox :
Chrome :
The site we're currently on, https://security.stackexchange.com is covered by the wildcard SAN *.stackexchange.com.
Bear in mind that in order for any site listed in these fields to use this certificate, the site would need the private key that corresponds to the public key in the certificate.
These conditions must be met in order for your browser to make a SSL/TLS connection to the site, without warnings.
-
4I'm sure I'm not the only one that tried to scroll through the windows in that image... – JPhi1618 Oct 24 at 15:30
-
2@JPhi1618 to see the whole list? Here it is: ` *.askubuntu.com *.blogoverflow.com *.mathoverflow.net *.meta.stackexchange.com *.meta.stackoverflow.com *.serverfault.com *.sstatic.net *.stackexchange.com *.stackoverflow.com *.stackoverflow.email *.superuser.com askubuntu.com blogoverflow.com mathoverflow.net openid.stackauth.com serverfault.com sstatic.net stackapps.com stackauth.com stackexchange.com stackoverflow.blog stackoverflow.com stackoverflow.email stacksnippets.net superuser.com ` – Stéphane Gourichon Oct 24 at 18:48
-
2@StéphaneGourichon, No I just meant I was a dummy that tried to grab the scroll bar on an image like it was an actual interactive element, but thanks for the complete list! – JPhi1618 Oct 24 at 18:51
-
10
For a site to successfully use any given X.509 certificate (the type of certificate used by TLS/SSL), it has to meet a few specific requirements:
- It must have the correct private key for the certificate. Without this, nothing else matters, as the server won't be able to correctly encrypt the communications otherwise.
- The Certificate Authority who signed the certificate must be trusted by the user's browser (either because the browser developers/vendor inherently trusts it, or because the user (or the person who set up their system) configured the browser to trust it). Without this, the browser won't trust the certificate to be secure in and of itself.
- It must be accessed through a domain name that either matches the Common Name the certificate is issued to, or one of the Subject Alternate Names listed in the certificate. Without this, the browser may trust the certificate, but it won't let it be used for that site. Some browsers will not check the Common Name at all and require a Subject Alternate Name match.
- The certificate must still be valid. This means that the client system must see the date and time as being after the issue date listed in the certificate, but before the expiration date listed in the certificate. Depending on the browser and site, other checks may be made for this part as well (for example, it may check a certificate revocation list from the CA, or validate the certificate through OCSP). Not meeting this requirement is effectively the same as not meeting the second requirement.
Any website that meets all four requirements for the certificate can use that certificate. Some browsers may warn the user instead of blocking access to the site if any of the above requirements other than the first aren't met, though this is becoming less and less common as a result of HSTS becoming the norm (if a site has asked for HSTS, the browser should block all access without a certificate that doesn't meet all four requirements).
-
2Per rfc2818 if SAN.DNS is present client/browser should use only that and ignore CN. Chrome since 58 (in 2017, more than 2 years ago) requires SAN and will not accept CN match. – dave_thompson_085 Oct 24 at 1:11
-
@dave_thompson_085 I actually did not know about Chrome requiring SAN matching and ignoring the CN. I've updated my answer to reflect this. – Austin Hemmelgarn Oct 24 at 15:31
-
Does the requirement in Chrome apply to private CAs, or just public webPKI CAs? – grawity Oct 24 at 21:25
-
1@grawity: all. But since public CAs have been consistently issuing SAN for years (although many charge extra for anything more than 'x and www.x', or did) it causes actual problems only for private, personal, or test CAs; that's why we have dozens of Qs on several Stacks like 'I created my own cert for test/dev/internal following the instructions I found on some decades-old website somewhere, and it doesn't work in Chrome'. – dave_thompson_085 Oct 25 at 2:04
2
- A wildcard certificate is a digital certificate that is applied to a domain and all its subdomains (
*.domainname.example.com) - With a multi-domain certificate you can secure multiple fully qualified websites with one certificate (
domainname1.example.com,domainname2.example.com, ...)
-
2Should probably add that a wildcard certificate for
*.example.comcan't be used for sub-subdomains likesub.domainname.example.com. – Tom A. Vibeto Oct 24 at 20:15
