Action-85: Wildcard certs and virtual hosts

Folks,

During the January 23rd conf call, I picked up an action item to 
"summarize issues around deployment of certificates in wildcard / 
virtual hosting situations."

For those not familiar with wildcard certs, a simple explanation is that 
these are certs that include only a partial domain name in the Common 
Name (CN) element of the cert's Distinguished Name (DN). Normally, when 
a TLS (SSL) session is established, the domain name from the URL is 
matched to the cert's CN. However, for a wildcard cert, the CN is 
composed of one or more wildcard characters plus a base domain name. 
When a TLS or SSL session is established with a wildcard cert, the 
domain name from the URL is matched against the wildcard template 
contained in the cert to determine if the cert is valid for the URL 
associated with the site. The simplest way to clarify this is to provide 
an example.

Suppose the Widgets manufacturing company owns the domain name 
<widgets.tld>. They might then set up three Web servers for different 
groups of users to access via https: <customer.widgets.tld>, 
<partners.widgets.tld>, and <employees.widgets.tld>. Normally, they 
would have to get one cert for each of these three servers. But suppose 
they want to run all three web servers on the same physical server 
system? Instead of having to acquire three certs, they could get a 
single wildcard cert with <*.widgets.tld> in the Common Name. However, 
as a practical matter, they would typically require a separate IP 
address for each "sever."

"Virtual hosts" represent one method for establishing multiple distinct 
Web servers on a single physical server, as outlined in the Widgets 
example above. However, the original purpose for virtual hosts was to 
allow a single physical host/server to support multiple distinct 
servers, such as might be common for a hosting service provider that 
would map multiple customers to a single physical server. In general, 
wildcard certs and virtual hosts are unrelated to each other, though 
there has often been confusion about this. Again, this glosses over some 
details that are rather important when deploying actual systems.

Wildcard certs are also used in some situations where web services are 
load balanced across multiple servers or where Web services are 
geographically distributed in order to improve resilience. DNS services 
can also be used to map the same domain name to multiple servers, 
thereby obviating the need for wildcard certs. Note that I'm glossing 
over some details here, but I don't think they're germane to the 
interests of our WSC group.

The justification for wildcard certs is that they avoid the extra 
license charges (fees) associated with acquiring multiple certs just 
because an organization wants to use multiple domain names in setting up 
its Web services. However, another approach would be for Certification 
Authorities to charge for the up front vetting of an organization before 
giving them their first SSL cert, and then charge a minimal fee for 
subsequent certs. After all, the cost is mostly in the vetting process, 
and certs are merely bundles of bits that have negligible cost to produce.

What is the relevance of all of this to the WSC group? Mostly it is a 
matter of interpreting how any of this might be portrayed to the user of 
a browser that has surfed to a Web site that uses a wildcard cert. In 
almost all cases, the user never needs to know if the site's cert 
contains a wildcard CN or not. There have been some arguments in the 
past that wildcard certs might not be as secure as certs containing 
fully qualified domain names. However, these concerns are secondary, or 
even tertiary. What does matter is that the user should not be 
confronted with decisions about whether or not to accept a Web session 
based on the use of a wildcard cert.

There is one other issue that may be relevant to this group, and that is 
whether or not EV certs will be allowed to have wildcarded CNs? I'll 
have to defer to others on this list for clarification of this point as 
well as elucidation of the potential impact on browsers and user interfaces.

...Chuck
-- 
_____________________________
   Chuck Wade, Principal
   Interisle Consulting Group
   +1  508 435-3050  Office
   +1  508 277-6439  Mobile
   www.interisle.net