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

Reply via email to