Bruce Keats wrote, On 2008-07-02 14:52: > Thanks for the help. That answers a lot of questions, but raises some more.
> I assume that firefox is trying to match with the hostname (portion of > the URL) or the IP address with something in the DN or the subject Alt > of the certificate. Firefox is trying to match the host name portion of the URL (which may have been an IP address) with the appropriate portion of the cert, according to RFC 2822. If the host name portion of the URL was a DNS name, then Firefox is trying to match that DNS name with the cert. If the host name portion of the URL was an IP address, then Firefox is trying to match that IP address from the URL with the cert. In NO case does Firefox ever do a forward or reverse DNS lookup and then try to match the result of that lookup with the cert. If it did that, Firefox would be vulnerable to DNS attacks. > When you say names in the cert, then I assume you are referring to the > cert's DN or subject alt name. For the DN, is it the CN that has to match? > > If I use subject Alt name, can I specify multiple hostnames or IP addresses? > > Can I match wildcards such as "*.google.com"? > > Is the name match a specific IP address or can I specify a subnet? The Subject Alternative Names (SAN, note: plural) extension is defined in RFC 5280. It allows any number of names and addresses, in numerous different forms (such as IP addresses, email addresses, and lots more), to be included in a cert. RFC 2822 defines how https clients use the names in certs. It says that the client uses the DNS names and IP addresses in the SAN if the SAN extension is present, and otherwise (only if the SAN is not present, or contains no usable names) it can use ONE host name from the single most-specific CN field in the subject name. (A subject name can have multiple CNs, but one one of them is the most specific one, and that is the only one that RFC 2822 allows to be used for a host name.) The latter provision recognizes that this use of CN was never conformant to the X.50x standards, and that the SAN extension is *the* standards conformant place for such names. It allows backwards compatibility (use of CN) only when SAN is absent (or contains no DNS names and no IP addresses). Wildcards are allowed, as specified in RFC 2822. IP address matches are exact. No subnet masks apply. IPv4 and IPv6 addresses are allowed. Note that, to match, the IP address in the SAN must be encoded in binary, as specified in RFC 5280. Some CAs make the mistake of thinking that an IP address is simply encoded as a DNS host name string in the SAN. That doesn't match. If the host name in the URL is an IP address, then we only check it against binary IP addresses in the SAN, and if it's not an IP address, then we only check it against the DNS name strings in the SAN. > Given both of those answers, I would rather change out my server certs > than have the users manually override the cert checking. That seems wise. > Don't forget that if you have host names in the Subject Alternative Name > extension, then ALL the names in the cert belong there, not all-but-one. > But This is no different than it was in FF2. > I don't think I fully understand the "ALL the names" in this context. > What might help me is if can you elaborate with a simple example? Frank's answer here was correct. Some cert issuers forget that RFC 2822 allows the cert's subject CN to be used ONLY when the SAN is absent or when it contains no DNS names, so they put most (all but one) of the DNS host names into the SAN, and put one DNS name into the CN. But FF does what the standard says, and ignores the CN when the SAN has DNS names. So, if you have multiple names, put them ALL into the SAN. Some admins worry that there might still exist some browsers that don't know about SANs, and that always use CNs, and so those admins desire to put a host name in the CN, as well as in the SAN. You can put ONE host name into the CN. If you do that, it should be in BOTH the CN and in the SAN. Doesn't hurt to appear twice. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
