1153204 - Firefox doesn't connect to https://www.deutschepost.de/ because its issuer certificate contains invalid dNSName entries with trailing spaces

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Alexander Buchner]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150403142420

Steps to reproduce:

Visit https://www.deutschepost.de/


Actual results:

Secure Connection Failed

An error occurred during a connection to www.deutschepost.de. security library: improperly formatted DER-encoded message. (Error code: sec_error_bad_der)

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.


Expected results:

Connect like Chrome does.

I guess that this is related to the Common Name in the certificate being " www.deutschepost.de" (starting with a space).

Comment 1

[Hanno Boeck]

To throw my opinion in: I think it's actually a good thing that firefox is throwing an error. This is an invalid CN value, the cert violates the baseline requirements (which say that the CN must be one of the SAN values).

I think especially in crypto being more strict is better than being lax on verifying things. The fault here is the cert, not the browser.

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Steve Roylance from GlobalSign figured it out:

https://groups.google.com/d/msg/mozilla.dev.security.policy/nEM8cfLf324/Lgs6rjXJEOIJ

The problem isn't the common name attribute of the subject (subject CN). First, when the certificate contains a subjectAltName extension that contains dNSName or iPAddress entries, Firefox will not look at the subject CN. That is, it follows the RFC 6125 rules, modified to account for iPAddress entries.

Secondly, when there is no subjectAltName extension, Firefox will look at the subject CN, but if the subject CN isn't a valid DNS name, it will just ignore it, assuming the subject CN wasn't trying to identify a domain name.

Based on what Steve said in dev.security.policy, this is getting fixed by the site operator. Moving to Tech Evangelism to track that happening.

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Also, for future reference, two of the invalid dNSName entries in the issuer name constraints were "leserservice-media.de[SPACE]" and "leserservice-sicherheitsabo.de[SPACE]". I'm not sure if there were other ones.

Comment 4

[Hanno Boeck]

Attachment: leaf certificate of www.deutschepost.de

Comment 5

[Hanno Boeck]

Attachment: Intermediate DPDHL TLS CA I3

Just to keep this as a reference attaching the intermediate and the leaf.

Comment 6

[Steve Roylance]

Just to let everyone know that I've returned from vacation and verified the issue and reached out to the Deutsche Post team.  Initial e-mails show my main contact out of office for the next week (until the 20th).

Comment 7

[will69]

There is a new certificate as of 2015-04-20. Works for me.

Comment 8

[Alexander Buchner]

I have the same problem with https://mobil.dhl.de/ .
Is this the same bug/problem?

Comment 9

[Gingerbread Man]

(In reply to Alexander Buchner from comment #8)
> I have the same problem with https://mobil.dhl.de/ .
> Is this the same bug/problem?

Bug 1175423