Firefox 3 connection now results in ssl_error_bad_cert_domain
Hi, I started using firefox 3 and I am now getting errors connecting to intra-net sites that were OK in firefox 2. We have our own intra-net and we have a CA that issues server certs and user certs. I have loaded the CA certs and the CA certs are visable under Authorities tab (Preferences-Advanced-Encryption-View Certificates) and the This certificate can identify web sites is checked. In firefox 2, this was sufficient to stop the warnings, but with firefox 3, I now get ssl_error_bad_cert_domain error. I can go through the motions and add an exception, but this is a pain to do for each of the servers. If I manually add the exception will this permanently bypass all the other cert checking (valid dates, revocation, etc.)? If I Get Certificate when I manually Add Security Exception, it seems that firefox complains about Certificate Status and Wrong Site. Under Certificate Status, it says This site attempts to identify itself with invalid information, but I can't understand why because firefox has the CA certs so it should be able to validate the cert. Under Wrong Site it says Certificate belongs to a different site which could indicate an identity theft and I might be able to accept that because the URL is different than that found doing a reverse DNS lookup. How can I get firefox to stop complaining about the certificates for intra-net sites? Is there something I need to place in the server certs? Bruce ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Firefox 3 connection now results in ssl_error_bad_cert_domain
Bruce Keats wrote: Hi, I started using firefox 3 and I am now getting errors connecting to intra-net sites that were OK in firefox 2. We have our own intra-net and we have a CA that issues server certs and user certs. I have loaded the CA certs and the CA certs are visable under Authorities tab (Preferences-Advanced-Encryption-View Certificates) and the This certificate can identify web sites is checked. In firefox 2, this was sufficient to stop the warnings, but with firefox 3, I now get ssl_error_bad_cert_domain error. I can go through the motions and add an exception, but this is a pain to do for each of the servers. If I manually add the exception will this permanently bypass all the other cert checking (valid dates, revocation, etc.)? If I Get Certificate when I manually Add Security Exception, it seems that firefox complains about Certificate Status and Wrong Site. Under Certificate Status, it says This site attempts to identify itself with invalid information, but I can't understand why because firefox has the CA certs so it should be able to validate the cert. Under Wrong Site it says Certificate belongs to a different site which could indicate an identity theft and I might be able to accept that because the URL is different than that found doing a reverse DNS lookup. How can I get firefox to stop complaining about the certificates for intra-net sites? Is there something I need to place in the server certs? Yes, Certificates are normally valid for specific websites only. The sites they are valid for are listed specifically in the certificate itself (most certs are good for exactly one site, but it's legal to make certs good for a specific list of sites). In Firefox 2.0, it was using a general override. When you accepted a certificate, that certificate was considered good for SSL period. It appears you were using this for your intranet websites, giving the same certificate for all your servers (or for servers that had multiple aliases). The problem with this is it could create a security issue. Users did not understand how that it was granting global SSL privellege for the whole cert (if they understood the certificate at all). This means a phisher could get his cert trusted by convincing users to visit his website. For many intranet users, the continual request to 'enable this cert' trained them to click through those dialogs. The phisher could then pretend to be some commercial website without notice given to the users. Your best bet if you are managing a bunch of internet sites is to create a root cert for your intra-net and have your users download and trust that... then issue real SSL certs with the proper network name(s) in either the subject alt field (preferred) or the CN of the subject name (acceptable if there is only one). There's a new open source project based on an old product that can help you manage that here: http://pki.fedoraproject.org/wiki/PKI_Main_Page. This will remove all the exception cases (which is preferable, you really don't want to acclimatize your users to ignoring certificate warnings...). bob smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Firefox 3 connection now results in ssl_error_bad_cert_domain
Bruce Keats wrote, On 2008-07-02 12:35: I started using firefox 3 and I am now getting errors connecting to intra-net sites that were OK in firefox 2. I don't recall any changes in that area between FF2 and FF3. We discussed making some changes, but didn't actually make them because we believed it would introduce too many incompatibilities. (see bug 159483) We have our own intra-net and we have a CA that issues server certs and user certs. I have loaded the CA certs and the CA certs are visable under Authorities tab (Preferences-Advanced-Encryption-View Certificates) and the This certificate can identify web sites is checked. In firefox 2, this was sufficient to stop the warnings, but with firefox 3, I now get ssl_error_bad_cert_domain error. That error means one thing: the name(s) in the cert do not match the name (or IP address) of the server given in the URL. Nothing you can do to any Issuer cert will overcome the fact that the server cert doesn't have the desired server name in it in the right place. I can go through the motions and add an exception, but this is a pain to do for each of the servers. Yup. A much better solution is to ensure that the cert has the host name used in the URL, and vice versa. If I manually add the exception will this permanently bypass all the other cert checking (valid dates, revocation, etc.)? I believe so, yes. How can I get firefox to stop complaining about the certificates for intra-net sites? Is there something I need to place in the server certs? Ensure that the cert has the hostname used in the URL, and vice versa. Pay attention to FQDNs. If the cert's host name is an FQDN, then the host name in the URL must be an FQDN. Reverse DNS lookups are irrelevant. They play no role whatsoever in matching the hostname given in the URL to the name in the cert. 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. Bruce /Nelson ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Firefox 3 connection now results in ssl_error_bad_cert_domain
Thanks for the help. That answers a lot of questions, but raises some more. On Wed, Jul 2, 2008 at 5:01 PM, Nelson B Bolyard [EMAIL PROTECTED] wrote: That error means one thing: the name(s) in the cert do not match the name (or IP address) of the server given in the URL. Nothing you can do to any Issuer cert will overcome the fact that the server cert doesn't have the desired server name in it in the right place. 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. 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? I can go through the motions and add an exception, but this is a pain to do for each of the servers. Yup. A much better solution is to ensure that the cert has the host name used in the URL, and vice versa. If I manually add the exception will this permanently bypass all the other cert checking (valid dates, revocation, etc.)? I believe so, yes. Given both of those answers, I would rather change out my server certs than have the users manually override the cert checking. How can I get firefox to stop complaining about the certificates for intra-net sites? Is there something I need to place in the server certs? Ensure that the cert has the hostname used in the URL, and vice versa. Pay attention to FQDNs. If the cert's host name is an FQDN, then the host name in the URL must be an FQDN. Reverse DNS lookups are irrelevant. They play no role whatsoever in matching the hostname given in the URL to the name in the cert. 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? Bruce /Nelson ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto Thanks, Bruce ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Firefox 3 connection now results in ssl_error_bad_cert_domain
Robert Relyea wrote, On 2008-07-02 14:03: Bruce Keats wrote: Hi, I started using firefox 3 and I am now getting errors connecting to intra-net sites that were OK in firefox 2. We have our own intra-net and we have a CA that issues server certs and user certs. I have loaded the CA certs and the CA certs are visable under Authorities tab (Preferences-Advanced-Encryption-View Certificates) and the This certificate can identify web sites is checked. In firefox 2, this was sufficient to stop the warnings, but with firefox 3, I now get ssl_error_bad_cert_domain error. I can go through the motions and add an exception, but this is a pain to do for each of the servers. If I manually add the exception will this permanently bypass all the other cert checking (valid dates, revocation, etc.)? If I Get Certificate when I manually Add Security Exception, it seems that firefox complains about Certificate Status and Wrong Site. Under Certificate Status, it says This site attempts to identify itself with invalid information, but I can't understand why because firefox has the CA certs so it should be able to validate the cert. Under Wrong Site it says Certificate belongs to a different site which could indicate an identity theft and I might be able to accept that because the URL is different than that found doing a reverse DNS lookup. How can I get firefox to stop complaining about the certificates for intra-net sites? Is there something I need to place in the server certs? Yes, Certificates are normally valid for specific websites only. The sites they are valid for are listed specifically in the certificate itself (most certs are good for exactly one site, but it's legal to make certs good for a specific list of sites). In Firefox 2.0, it was using a general override. When you accepted a certificate, that certificate was considered good for SSL period. Sorry, Bob, That's not correct. In FF2, when you accepted a cert, it was good for all the names that appeared in the cert, including wildcard names. When you overrode a cert name mismatch, the cert also became good for the name of the host for which you overrode it. The name of the server for which you overrode the error got added to the valid host names for that cert, but only for the lifetime of the process, which is why people complained about the fact that host name mismatch overrides had to be redone every time they started the browser. That was one of the motives for the new exception scheme in FF3. It appears you were using this for your intranet websites, giving the same certificate for all your servers (or for servers that had multiple aliases). The problem with this is it could create a security issue. Users did not understand how that it was granting global SSL privellege for the whole cert (if they understood the certificate at all). Bob, NSS does not, and did not in FF2, consider a trusted server cert to be good for all host names. Years and years ago, for a brief time, NSS did that, and it caused a CERT alert, and was fixed pronto. This means a phisher could get his cert trusted by convincing users to visit his website. For many intranet users, the continual request to 'enable this cert' trained them to click through those dialogs. The phisher could then pretend to be some commercial website without notice given to the users. A phisher could have a cert with multiple host names in it. By getting the user to override for that cert, that cert became valid for all the names in the cert, but that's quite different than having become valid for all names of all https servers everywhere. Your best bet if you are managing a bunch of internet sites is to create a root cert for your intra-net and have your users download and trust that... I believe the original poster already claims he has done that. The errors he is getting are not unknown issuer but rather host name mismatch. Getting a new set of CA software won't necessarily fix the host name mismatch problem. He needs to issue certs with the right host names, and/or change his intranet URLs to use the names in the certs. In many intranets, the users don't want to use FQDNs, and the problem is that the cert has an FQDN in it, but the user types in a simple host name. The solution is to change either the URL (use the FQDN) or change the host name in the cert to include the simple host name. The latter is dangerous, but feasible. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Firefox 3 connection now results in ssl_error_bad_cert_domain
Bruce Keats wrote: 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? I'll let Nelson or someone else provide the definitive answer to this, but I believe what he's saying is that, e.g., if you have three hostnames a.example.com, b.example.com, and c.example.com that are used for a given server, and you use SubjAltName, you should put all three names in the extension, as opposed to (e.g.) putting CN=a.example.com and then just b.example.com and c.example.com in SubjAltName. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Firefox 3 connection now results in ssl_error_bad_cert_domain
Nelson B Bolyard wrote: 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. s/RFC 2822/RFC 2818/g, just in case somebody is desperately trying to find the relevant text in the RFC (2822 is the Internet message format). ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Firefox 3 connection now results in ssl_error_bad_cert_domain
Kaspar Brand wrote, On 2008-07-02 21:47: Nelson B Bolyard wrote: 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. s/RFC 2822/RFC 2818/g, just in case somebody is desperately trying to find the relevant text in the RFC (2822 is the Internet message format). Thanks, Kaspar. You're right. Everywhere where I wrote RFC 2822 I really meant RFC 2818. Glad you're paying attention! Thanks. /Nelson ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
