"Internal" certs (ones for names like "mail") are a problem, because many networks have a server called "mail". One suggestion for making them less risky is to require that the cert contain at least one fully-qualified name for the server in question, and for the browser to display that as a disambiguating mechanism. So (using the old blue-bar treatment we used to have) a cert with: CN = mail SAN = mail.intranet SAN = mail.foobar.com might look like: L mail.foobar.com [ mail/show_inbox.php?page=2 ] (L being the lock) Then, if someone stole this certificate and tried to use it inside bazquux.com, the discrepancy would be obvious in the UI. I think that, instead of requiring CAs to produce certificates like this first, we should do our end first and then require them to take advantage of it. So, this bug is about changing the primary UI in Firefox when displaying such a cert, to show disambiguating information. Straw-man algorithm: - If domain name used does not end with a public suffix - Search through all alternative names in the cert - Display the first one which does end with a public suffix Alternatively, we could require that the CN be the name to display, and any internal names are included as SANs. Gerv
Sid Stamm's musings: "Regarding the multiple-SAN issue ... could we require that there only be one SAN that is a FQDN? Or would it make sense to have a FQDN SAN that begins with each single-token name in the cert? For example, it could have "foo" and "bar" and then "foo.company.com" and "bar.company.com". This would require domain ownership on company.com, and we could safely assume the cert should be used for company.com single-token sites... hmm." Gerv
The BRs prohibit internal names now, so I don't think we need to do anything here.