Firefox 3 connection now results in ssl_error_bad_cert_domain
Bruce Keats
Nelson B Bolyard
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
Nelson Bolyard
> Bruce Keats wrote:
>> Hi,
>>
>> I started using firefox 3 and I am now getting errors connecting to
>> 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
>> an exception, but this is a pain to do for each of the servers.
>>
>> other cert checking (valid dates, revocation, etc.)?
>>
>> 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.
>>
>> 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.
Bruce Keats
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-tec...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Frank Hecker
> 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
hec...@mozillafoundation.org
Nelson B Bolyard
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.
Kaspar Brand
> 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).
Nelson B Bolyard
Thanks, Kaspar. You're right.
Everywhere where I wrote RFC 2822 I really meant RFC 2818.
Glad you're paying attention! Thanks.
/Nelson
Bruce Keats
Thanks you so very much for taking the time to explain that! I know
that it takes time and effort to put together such a detailed
response ... it really does help me understand what I need to do. I
was unaware there were RFCs ... if I had known then I probably would
have tried to read them first.
Thanks again,
Bruce
Francisco Puentes
I am trying to generate a RSA pair of keys with this code:
NSS_Init("./rsa.db");
SECKEYPublicKey*rsaPbKey=NULL;
SECKEYPrivateKey*rsaPrKey=SECKEY_CreateRSAPrivateKey(1024,&rsaPbKey,NULL);
...
NSS_Shutdown();
But all seems to be wrong, rsaPrKey (and its partner) are always NULL.
What is wrong?
Francisco Puentes
(PR_LOAD_LIBRARY_ERROR).
Later I have copied following files into the directory of my standalone
application:
Freebl3.dll
Mozcrt19.dll
Nspr4.dll
Nss3.dll
Nssckbi.dll
Nssdbm3.dll
Nssutil.dll
Plc4.dll
Plds.dll
Softokn3.dll
Sqlite3.dll
Freebl3.chk
Softokn3.chk
Now NSS_NoDB_Init success and both keys are generated property.
¿is this list enough or are more files that I need?
-----Mensaje original-----
De: dev-tech-crypto-bounces+fpuentes=udc...@lists.mozilla.org
[mailto:dev-tech-crypto-bounces+fpuentes=udc...@lists.mozilla.org] En nombre
de Robert Relyea
Enviado el: lunes, 15 de septiembre de 2008 18:42
Para: mozilla's crypto code discussion list
Asunto: Re: Beginner with NSS
Francisco Puentes wrote:
> Being a beginner with NSS, I need help :-(
>
> I am trying to generate a RSA pair of keys with this code:
>
> NSS_Init("./rsa.db");
>
NSS_Init requires a pointer to a directory (which should already exist).
You should check the error code coming back for NSS_Init. It's probably
failing.
> SECKEYPublicKey*rsaPbKey=NULL;
>
> SECKEYPrivateKey*rsaPrKey=SECKEY_CreateRSAPrivateKey(1024,&rsaPbKey,NU
> LL);
>
Just a note: this will produce an ephemeral key (non-persistent). I can't
tell if that's what you want from your code fragment or not.
> ...
> NSS_Shutdown();
>
> But all seems to be wrong, rsaPrKey (and its partner) are always NULL.
>
> What is wrong?
>
>
>