Accepted wildcards used by server certificates for server authentication

Implementation of SSL/TLS in the SCHANNEL security provider allows for the use of wildcard characters in server certificates in all operating systems except in Microsoft Windows 2000 with service packs installed. When you install Windows 2000 Service Pack 1 or later, this functionality is already present.

When SCHANNEL is used to authenticate a server during an HTTPS session, the server presents a certificate. This certificate has a common name that is compared against the server name extracted from the remote resource request. For example, if you point your browser to https://www.e-commerce.example.com/, SCHANNEL ensures that the server presents a certificate with the common name www.e-commerce.example.com; otherwise it informs the application that the server authentication failed.

A variation on this certificate-matching scheme has been documented in RFC 2595 and draft RFC specs for other protocols. This functionality allows the server certificate to have a wildcard (*) in the common name (CN). With the wildcard, you may have a single certificate (or only one CN in the certificate) installed on a group of servers with somewhat similar names. The implementation is designed so that multiple servers are given duplicates of the same wildcarded certificate that authenticates a set of servers. For instance, a company may have three SSL e-commerce servers with the following names: For this example, the company may buy a single certificate containing the name *.e-commerce.example.com.

The following are some examples of how wildcards should and should not be used for maximum interoperability.

Accepted wildcard examples

• www.example.com matches www.example.com
• *.example.com matches www.example.com
• w*.example.com matches www.example.com

Nonaccepted wildcard examples

• *www.example.com
• *w.example.com
• w*w.example.com