How many hostnames can be supported by a wildcard ssl certificate? Is there any limit ?
3 Answers
There are two distinct things here. One is about the number of hostnames that you can put in a certificate. The other is the notion of "wildcard names".
In the Subject Alt Names extension, you can put "alternate names" of type dNSName
. Each of them is an "acceptable server name" (i.e. clients will accept the certificate for a server that purportedly uses that name). The ASN.1 notation for the extension is the following:
SubjectAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName ::= CHOICE {
otherName [0] OtherName,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER }
See the "MAX" ? It means "no limit". You can put as many names as you want in a certificate.
Well, since we are talking about DER encoding, the total length of the certificate must not exceed 702223880805592151456759840151962786569522257399338504974336254522393264865238137237142489540654437582500444843247630303354647534431314931612685275935445798350655833690880801860555545317367555154113605281582053784524026102900245630757473088050106395169337932361665227499793929447186391815763110662594625664 bytes, and each name will take a dozen bytes or so (at least). But existing libraries and protocols are likely to enforce stricter limitations. For instance, if the certificate is to be used in SSL/TLS (e.g. a certificate for a Web server that does HTTPS), then the certificate MUST fit within 16 megabytes (its length is encoded in a three-byte field, as per the SSL/TLS protocol). Thus, you can have a maximum of about one million alternate names in a certificate.
Then, each of the name may be a wildcard name, meaning that it contains the "*" character. The "*" will match any sequence of characters except dots. Existing browsers, there again, enforce other constraints, in particular:
- There shall be only one "*" character in the name (so no "
*.*.stackexchange.com
", to take an actual case). - The "*" must appear as first character, not elsewhere (so no "
meta.*.stackexchange.com
", to continue on that real-life situation). - The "*" must stand for a complete name component (hence "
*.example.com
" but not "*foo.example.com
").
A name component is limited to 63 characters, and the characters must be only letters (case insensitive), digits and the minus sign ("-"), so there are about 3764-2 = 23169162752708970943114627382699355445603465075569066753527132965271355336698663689946873706000418559 possible names matching a wildcard name (the "-2" is because the empty string is not a valid name component)(there are other restrictions, e.g. not beginning with a minus sign, but clients tend not to enforce these).
Since you can have a million alternate names in a certificate, multiply that number by one million, and you will have the maximum number of host names that match your "wildcard certificate". It ought to be enough for most purposes.
Take note of a common confusion. We say "wildcard certificate" but that is a misnomer. What is meant is "certificate such that at least one of the contained names is a wildcard name".
For a real-life example, have a look at Google's certificate (connect to https://www.google.com/
, then ask your browser to show the certificate). Right now, the returned certificate contains no less than 49 alternate names which are the following:
*.google.com
*.android.com
*.appengine.google.com
*.cloud.google.com
*.google-analytics.com
*.google.ca
*.google.cl
*.google.co.in
*.google.co.jp
*.google.co.uk
*.google.com.ar
*.google.com.au
*.google.com.br
*.google.com.co
*.google.com.mx
*.google.com.tr
*.google.com.vn
*.google.de
*.google.es
*.google.fr
*.google.hu
*.google.it
*.google.nl
*.google.pl
*.google.pt
*.googleadapis.com
*.googleapis.cn
*.googlecommerce.com
*.googlevideo.com
*.gstatic.cn
*.gstatic.com
*.gvt1.com
*.gvt2.com
*.urchin.com
*.url.google.com
*.youtube-nocookie.com
*.youtube.com
*.youtubeeducation.com
*.ytimg.com
android.com
g.co
goo.gl
google-analytics.com
google.com
googlecommerce.com
urchin.com
youtu.be
youtube.com
youtubeeducation.com
Notice that 39 of these names are "wildcard". With the numbers above, this means that this certificate can potentially match no less than 903597347355649866781470467925274862378535137947193603387558185645582858131247883907928074534016323811 distinct host names. And that's Google -- one can expect that their certificate "works everywhere".
-
Just to save work of others trying to figure out how is the maximum length of BER/DER encoded data determined. Maximum size of the number indicating the length is 127 bytes so the maximum length stored there is 2^(127*8) = 2^1016. See [Length octects - The definite form](https://en.wikipedia.org/wiki/X.690#The_definite_form) on Wikipedia. – pabouk - Ukraine stay strong Oct 17 '14 at 09:56
-
... BUT you have to subtract 1 because in 1016 bits, the biggest integer you can encode is 2^1016-1. AND then you have to add the length for the header (1 byte for the 0x30 tag, and 128 bytes for the encoding of the length). – Tom Leek Oct 17 '14 at 10:56
-
Note also that, stricto sensu, only the TBSCertificate is DER-encoded; the complete certificate structure may use BER with an indefinite length. However not many implementations support that. Moreover, the SAN extension is in the TBSCertificate. – Tom Leek Oct 17 '14 at 10:57
-
I suspect you could potentially have a few more if you include [international domain names](http://tools.ietf.org/html/rfc5890#section-4.2). In addition, your third bullet point ("*The "\*" must stand for a complete name component*" doesn't seem quite right according to [RFC 6125](http://tools.ietf.org/html/rfc6125#section-6.4.3), "*The client MAY match a presented identifier in which the wildcard character is not the only character of the label*". – Bruno Oct 17 '14 at 16:25
-
@Bruno: it should be tested. RFC 2818 certainly allows wildcards to match partial names, but I am not sure deployed clients (Web browsers) actually support that. RFC 6125 lists it as a "may", which means that you cannot really count on it being universally supported. – Tom Leek Oct 17 '14 at 16:30
A wildcard certificate matches a pattern, not a hostname or set of hostnames. It's issues to *.example.com
, meaning any host of format [subdomain].example.com
will match. It is notable perhaps, that it is limited to a single level so the *.example.com
wildcard cert could be used for sub1.example.com
and sub2.example.com
, but not deeper.sub1.example.com
.
So, since the match is based on pattern rather than hostnames, there is no limit, and there would be no way to generically enforce a limit, given that you can use the cert in many places, none of which need know about the others, or all of the specific hostnames it's being used for.
![](../../users/profiles/12.webp)
- 35,525
- 27
- 113
- 141
-
Thanks Xander. How about SAN ? Is there any limit ? Can we use wildcard while defining the hostnames? – Arun Oct 16 '14 at 14:33
-
@Arun There might not be theoretical limits regarding the number of SAN entries you can have, but there will certainly be practical ones: they will make the certificate bigger, which will certainly slow down the handshake, or even stop it from completing successfully. I've seen certain TLS stacks "choke" when using `certificate_authorities` lists (in on a `Certificate Request` message) that are too long, I would suspect the same would happen with a server certificate that has just become too big. – Bruno Oct 17 '14 at 16:14
As per Certificate authority Guideline, Wildcard SSL certificate is only supported for security of single level sub-domains with the same host name.
Without any limit Wildcard SSL can secure unlimited single level sub-domains.
![](../../users/profiles/32529.webp)
- 9
- 3