1138273 - Server certificates containing IP addresses encoded as DNS names are sometimes rejected

Status: RESOLVED DUPLICATE of bug 1148766

(Core :: Security: PSM, defect)

Description

[Stuart Cook]

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

Steps to reproduce:

While testing an internal tool, I found that Firefox 37 (Beta) was rejecting some privately-issued server certificates that were accepted by Firefox 36 and by current versions of Chrome/IE.

After some investigation, I found that the issue is apparently triggered by the presence of IP addresses in the certificate's SubjectAltName list that have been mis-encoded as DNS names. However, it only occurs if those mis-encoded entries appear earlier in the SAN list than the correctly-encoded entry for the domain/address that presented the certificate.

(These entries are needed for compatibility with current and past versions of IE, so removing them is not an option.)

It seems strange that Firefox would be sensitive to the relative order of SAN entries.


Actual results:

An error page complaining about "sec_error_bad_der", but only if any improper entry occurs before the real entry for the current domain/address.


Expected results:

The certificate should be consistently accepted or rejected, regardless of whether IP addresses appear in DNS name entries in the SAN.

Comment 1

[Stuart Cook]

I have modified our internal tool so that it always places the mis-encoded entries last when generating server certificates, which sidesteps the issue. But Firefox's behaviour nevertheless seems undesirable, especially since the cause of the failure is not easily diagnosed.

(Apologies for not being able to provide an example certificate.)

Comment 2

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

I agree it's surprising for the result to be success if one entry appears first and failure if a different entry appears first instead. Here's what RFC 6125 says:

"The search succeeds if any presented identifier matches one of the reference identifiers, at which point the client SHOULD stop the search."

Maybe we should just skip malformed entries as not matching anything? (i.e. instead of returning sec_error_bad_der early)

Comment 3

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

See also bug 1108408 comment 13 and 14. If the subjectAltName extension is empty, we return SEC_ERROR_BAD_DER, which isn't a great error code (particularly considering if it weren't present we might just return a domain name mismatch (or even success if the subject common name matched)).

Comment 4

[David Hrbáč]

David,

Well you are right. Would be nice to have detailed info or better to have FF accepting that kind of certificate again. That's some kind of a regression. These certificates are very old, created in 2008 with TinyCA2. All the our certificates (the whole CA chain) are/were very well accepted by Firefox up to 35 version.

What is annoying is the fact, that there's no info within the 36th Release Notes about this change. FF 36 will print out only SEC_ERROR_BAD_DER. There's no way to click on something like "I'm aware of the risk". So, effectively right now FF 36 is out of the play for us since we can't use it anymore, unless we recreate all the CAs and certificates.

Just the note: Chrome and IE11 are fine with these certificates. Anyway, it's not the excuse that our certificates are not conforming to RFC 5280.

Comment 5

[[e-mail]]

Maybe bug 1088140 comment #12 and on is related.

Comment 7

[Loic]

A user reported the same issue on the French support board.
Is there a plan to fix that? Any workaround for FF37?

Comment 8

[:Cykesiopka]

Bug 1148766 is being tracked for what appears to be the same issue, so I'm marking this bug as a duplicate.