Effectively, the algorithm is going to be something like this:
If( dNSName is present)
{
Match dNS Name
}
Else
{
Match Common Name
}
For HTTPS, we saw that a mismatch caused a warning dialog box with Internet Explorer 6 and an explicit Certificate Error with Internet Explorer 7. Combining everything we have learned so far, we can form a very easy rule with SSL/TLS:
One name to one IP Address to one port number identifies one certificate.
For instance, looking at the previous trace:
w2003.example.internal => 192.168.0.1 + TCP 636 => LDAPS certificate
That was easy, right? Well, things get more complicated due to a few factors:
•Server Farms – having multiple servers respond to one name
•Virtual Hosting – having one web site for many customers
•Limited IP addresses – public servers require public IP addresses
•SSL Certificates for the Internet cost money
Server farms are where I have several machines handling SSL requests in order to load balance. For example, if you do an nslookup on a major site, you may see more than one IP address. Going back to our LDAPS example, it would be something like this:
w2003.example.internal = 192.168.0.1, 192.168.0.2, 192.168.0.3
Each time the name w2003.example.internal is resolved to an IP address, a different IP address is used. This behavior allows for load balancing. If each IP address is a separate machine, a single certificate needs to be stored on multiple machines because of how the naming checks are done.
When distributing the same certificate to multiple machines, there is a danger around private key protection. Alternatively, separate certificates can be used with the same name but a differing organizational unit so that they can be distinguished (if the CA supports issuing certificates in this form). For example, you can see how Jetdirect populates the organizational unit:
86