Open Bug 1617458 Opened 4 years ago Updated 2 years ago

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

Categories

(Firefox :: Security, defect, P2)

73 Branch
defect

Tracking

()

People

(Reporter: mail, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(4 files)

Attached file 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.

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

Component: Untriaged → Security: PSM
Product: Firefox → Core

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

Component: Security: PSM → Security
Flags: needinfo?(mail)
Product: Core → Firefox

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).

Flags: needinfo?(mail)

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.

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(jhofmann)
Blocks: cert-viewer
Flags: needinfo?(jhofmann)
Priority: -- → P2
Status: UNCONFIRMED → NEW
Ever confirmed: true

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.

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.

Flags: needinfo?(jhofmann)

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

Assignee: nobody → mkbosmans
Status: NEW → ASSIGNED

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

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.

Flags: needinfo?(mkbosmans)
Flags: needinfo?(jhofmann)
Assignee: mkbosmans → nobody
Status: ASSIGNED → NEW

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.

Flags: needinfo?(mkbosmans) → needinfo?(sgalich)

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

Flags: needinfo?(sgalich) → needinfo?(mail)
Flags: needinfo?(sgalich)
Flags: needinfo?(mail)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: