1617458 - Firefox doesn't show certificate (and gives error) while the connection is marked as secure

Status: NEW

(Firefox :: Security, defect, P2)

Description

[mail]

Attachment: cloud.mka.crt

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

I have a self-signed certificate chain and the root CA certificate imported to the system as well as in Firefox.

Actual results:

While accessing the TLS secured pages Firefox shows, that the connection is secured. If I wanna view the certificate, I get an error page: "Certificate. Something went wrong.
We were unable to find the certificate information, or the certificate is corrupted. Please try again."
Firefox Klar doesn't load/display the page at all, while the chromium certificate viewer gives me detailed information about the certificate as expected.

Expected results:

See the (details of that) certificate.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

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

This may be bug 1601035. What version of Firefox are you on?

Comment 3

[mail]

The error message is the same as in bug https://bugzilla.mozilla.org/show_bug.cgi?id=1601035, but that certificate I can display without problems in my Mozilla Firefox for Arch Linux 73.0.1 (64-bit).

Comment 4

[Johann Hofmann [:johannh]]

Attachment: parsed cert data

Comment 5

[Johann Hofmann [:johannh]]

I attached what PKI.js is parsing for this certificate, the issue is this part:

      [
        null,
        "DNS:cloud.mka"
      ]

in the "Subject". Our old cert viewer and the OSX one is calling this the Subject Alt Name, so I suppose this is a parsing issue with PKI.js? We might need to file an issue with them and upstream the fix.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:johannh, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[Maarten Bosmans]

The problem is that in certviewer/content/strings.js normal attributes are defined as:

"2.5.4.10": {
  short: "o",
  long: "Organization",
},

, while extensions are defined as:

"2.5.29.17": {
  name: {
    short: "Subject Alt Names",
    long: "Subject Alternative Names",
  },
},

The function parseSubsidiary in certDecoder.js is not prepared to handle this extra level of indirection and simply uses name.long and name short and not name.name.long and name.name.short.

Another problem with parseSubsidiary is that it assumes that if name !== undefined && name.short !== undefined, that then name.long must be defined, which is not the case here. I think the name !== undefined branch which falls back to using the OID directly should also be used in case name is defined but both name.short and name.long are undefined.

Furthermore, it makes sense to change the normalizeToKebabCase function to handle undefined input, just to make the code more robust, as that is the function actually triggering the exception.

Comment 8

[Maarten Bosmans]

Should I make a patch for the fixes I proposed?
As far as I can see, the problem is not with the DER decoding of PKI.js, but rather with interpreting the decoded data in certviewer itself.

Comment 9

[Maarten Bosmans]

Attachment: Bug 1617458 - Make subject parsing more robust to missing properties. r?johannh

In parseSubsidiary, the case where name was defined, but had neither a short or long property was not handled correctly.

Comment 10

[Maarten Bosmans]

Attachment: Bug 1617458 - Fix names of certificate attributes. r?johannh

Some names where defined with an extra name: {} level, which is not parsed correctly elsewhere.

Also amend some short names of extensions, according to those found in RFC 5280.

Depends on D105118

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

There are some r+ patches which didn't land and no activity in this bug for 2 weeks.
:mkbosmans, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:serg, since the bug has high priority and recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

Redirect needinfos that are pending on an inactive user to the triage owner.
:serg, since the bug has high priority, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 15

[Marco Castelluccio [:marco]]

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.