Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

Accepted wildcards used by server certificates for server authentication


View products that this article applies to.

Summary

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.

↑ Back to the top


More information

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:
www.e-commerce.example.com
w3.e-commerce.example.com
secure.e-commerce.example.com
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
  • ww*.example.com matches www.example.com
  • Www.Example.com matches www.examPle.cOm

Nonaccepted wildcard examples

  • *www.example.com
  • *w.example.com
  • w*w.example.com
  • *ww.example.com does not match www.example.com
  • www.e*ample.com does not match www.example.com
  • www.*ample.com does not match www.example.com
  • www.ex*.com does not match www.example.com
  • www.*.com does not match www.example.com
  • example.com does not match *.com does not match www.example.com
  • www.example.abc.com does not match *.abc.com
  • example.com does not match *.*
  • example does not match *
  • abc.def.example.com does not match a*.d*.example.com
  • www.example.com.au does not match *.*.com.au
  • www.example.com.au does not match www.*.com.au

↑ Back to the top


Applies to:

↑ Back to the top

Keywords: kbenv, kbinfo, KB258858

↑ Back to the top

Article Info
Article ID : 258858
Revision : 8
Created on : 1/22/2010
Published on : 1/22/2010
Exists online : False
Views : 791