1157214 - Firefox reports "invalid security certificate" for valid SSL certificate with Subject Alternative Name

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Robert Premuž]

Attachment: screenshot.png

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150415140819

Steps to reproduce:

We have a HTTPS server which uses a SSL certificate signed with our internal CA.
The root certificate can be obtained here: https://sites.google.com/site/wwwherahr/files/hera.hr.cer
If you import that certificate in Firefox trusted authorities (Options > Advanced > Certificates > View Certificates > Authorities > Import) then you should be able to open https://vpn.hera.hr without any security warnings.

This connection is successful in Firefox v. 24.8.1 ESR and 31.6.0 ESR.


Actual results:

But in Firefox 37.* (tested on a Linux system) you get the following warning:

vpn.hera.hr uses an invalid security certificate.
The certificate is only valid for 192.168.168.168
(Error code: ssl_error_bad_cert_domain)


Expected results:

The SSL certificate used for https://vpn.hera.hr contains the following attributes:
Subject:
CN = vpn.hera.hr, O = HERA, L = Zagreb, S = Croatia, C = HR
Subject Alternative Name:
IP Address=192.168.168.168

So, the certificate should not be declared invalid.

It seems that Firefox declares it invalid because the Subject Alt Name does not contain the DNS name of the server (vpn.hera.hr).

The following test shows that the certificate for vpn.hera.hr (exported to vpn.hera.hr.cer file) is valid:

$ openssl verify -CAfile hera.hr.cer vpn.hera.hr.cer
vpn.hera.hr.cer: OK

For comparison, when you connect to https://exmail.hera.hr, which uses a SSL certificate signed with the same root CA certificate, you don't get any errors.

The SSL certificate used for https://exmail.hera.hr contains the following attributes:
Subject:
CN = exmail.hera.hr, OU = hera.hr, O = hera.hr, L = Zagreb, S = Zagreb, C = HR
Subject Alternative Name:
DNS Name=exmail.hera.hr
DNS Name=autodiscover.hera.hr

In this case, the Subject Alt Name does contain the DNS name of the server (exmail.hera.hr). But, IMHO, for a valid HTTPS connection the address of the server must match either Subject or Subject Alt Name attribute of the certificate and matching both attributes is not required.

Comment 1

[Robert Premuž]

This issue may be related to Bug #1155821

Comment 2

[Robert Geißler]

I can reproduce your problem as you describe it.
Internal CA with certificates that have a DNS name als CN an the IP address of the webserver as alternative.

Problem discovered while testing the Firefox ESR release 38.0.1, with ESR 31 the certificate is marked as valid.

please fix - i cannot roll out ESR 38 until our (valid) certificates work as designed.

Comment 3

[Robert Geißler]

maybe somebody will try to reproduce / confirm / fix this problem in the ESR 38 branch?

Comment 4

[Robert Premuž]

As the certificates on the sites mentioned in original post have been changed I'm attaching the old certificates for reference.

Comment 5

[Robert Premuž]

Attachment: certificates

Comment 6

[Dana Keeler (she/her) [:keeler]]

Peter Bowen addressed this on the mailing list, so I'll copy his response here:

On Tue, Jul 28, 2015 at 10:13 PM, Robert Geißler
<[e-mail]> wrote:
> I have problems since version ESR 38.0.1 accessing our internal sites with
> https. (internal testing, productive machines are on ESR 31.8.0)
> Our SSL certificates are generated with the hostname as CN and the servers
> IP address as Subject Alternative Name.
>
> With ESR 38.0.1 and higher, there is a faulty SSL security warning about
> "ssl_error_bad_cert_domain" when accessing the sites with the hostname,
> because it seems the CN is ignored and Firefox tries to compare the hostname
> with the Subject Alternative Name and not the Common Name first.

This is working as designed.  The subject CN is ignored when there is
a subject alternative name available.  This is per specification and
is unlikely to be changed.  The switch to mozilla::pkix exposed a
number of items similar to this, as it is does a better job of
following the specifications and being more rigorous to avoid security
issues.

Thanks,
Peter


See also the comment at https://hg.mozilla.org/mozilla-central/file/2ddec2dedced/security/pkix/lib/pkixnames.cpp#l332

Comment 7

[Robert Geißler]

That means we should generate new certificates with the DNS name and IP both in Subject Alternative Name, because Common Name is not relevant in this case?

Is that right and should that work?

Comment 8

[Dana Keeler (she/her) [:keeler]]

Yes, although take care that you use the appropriate entry type: dNSName for the domain name and iPAddress for the IP address: http://tools.ietf.org/html/rfc5280#page-38

Comment 9

[:Cykesiopka]

Resolving as invalid based on Comment 6 and Comment 8. Feel free to re-open if you think this is in error.

Comment 10

[wdo362]

We have a similar issue with Firefox ESX 45.3.0.

We also recieve a SSL_ERROR_BAD_CERT_DOMAIN error for our certificate in question.

We can also confirm that this worked with FF 31 ESR and still works with IE 8, 9, 11.

The differnece to the initially reported problem is, that we have the subject CN duplicated to the SAN attribute. What is similar to the OP is that we also have an IP entry in the SAN attribute and this is listed prior to the DNS attribute carrying the CN.

We have other installations where certificates are created with identical version of openssl where this works, however the only differnece we can find is that the IP attribute is listed after the DNS attirbute carrying the CN there, so order seems to matter here and trigger the problem.

To rule out any typos I copied the servername out of Firefox error message where it states: "The certficate is only valid for the following names":.......  Error Code: SSL_ERROR_BAD_CERT_DOMAIN.
Firefox connects to the correct server and shows the error message again.