(“https://msimpson.example.com” or “https://bsimpson.example.com”), they get a Certificate Error indicating a name mismatch. Why?
If we refer back to our SSL/TLS protocol diagrams, we can see that the server must send back a certificate before it knows what website is being referenced. This is part of the SSL/TLS negotiation. It happens before HTTP can be used to indicate the website (via the ‘Host:’ header). There are a few ways to try and fix this problem.
•A single certificate with multiple DNS names as part of the SubjectAlternativeName field. The security of the private key isn’t a concern because we are still only on one machine. The problem with this approach is that when “lsimpson.example.com” wants to advertise on the website, a new certificate must be issued.
•RFC4366 allows for the ClientHello in the SSL/TLS handshake to indicate the server name field. Support of this feature has been limited, but is becoming more supported as time goes by. However, it offers the tremendous benefit of being able to use separate certificates for each user, which is an increase in security (and in increase in the cost associated with each certificate). The security vs. cost tradeoff would have to be weighed.
•RFC2817 allows HTTP to be upgraded to use TLS which would also solve this problem because it allows for HTTP to specify the server name of interest first and then upgrade to run HTTP over TLS. An interesting idea but support doesn’t seem to be there for this feature in actual customer deployments.
•Wildcard Certificates. This is where the Common Name or the DNS SubjectAlternativeName contain an asterisk (*) to specify a wildcard match. For instance, in our example, the SubjectAlternativeName could be wildcarded as “*.example.com”. Many browsers support the wildcard, unfortunately in a variety of ways, and then a single certificate can be used to support a variety of names. Unfortunately, wildcard support also depends on the protocol being used (e.g., LDAPS versus HTTPS).
o RFC4513 which specifies LDAP authentication methods offers this guidance: “The '*' (ASCII 42) wildcard character is allowed in subjectAltName values of type dNSName, and then only as the
o RFC2818 which describes HTTP over TLS specifies: “Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com.”
o When presented with such confusion, we should refer to the RFC that controls the format of the certificate, RFC3820 defines that format. RFC3820 does not mention anything about wildcard characters in the Subject Field. It does mention it for the SubjectAlternativeName field: “Finally, the semantics of subject alternative names that include wildcard characters (e.g., as a placeholder for a set of names) are not addressed by this specification. Applications with specific requirements MAY use such names, but they must define the semantics.” Hardly a ringing endorsement!
Why are we talking so much about name validation? Well, it is a common complaint from customers and it is extremely important that everyone understand the types of checks that go on.
88