webRequest.getSecurityInfo: can't get self-signed/ToFU/"Exception" certificates

Add-ons Development
#1

I’m developing an extension to display more information about the current TLS connection.

However, I can’t seem to get the certificate chain for self-signed or otherwise Invalid certificates the user has manually accepted (for e.g. LAN/IP sites, altnet domains, internal sites pre-PKI, etc.)

securityInfo.certificates works fine iff the cert chain leads back up to a CA that’s been explicitly trusted by the user, their IT team, or Mozilla—but, when the certificate chain is otherwise, this is just an empty array.

If this a design choice, to represent the fact that the certificate chain isn’t valid-per-se, then

  1. It’s redundant with these connections’ securityInfo.state=="insecure"
  2. It’s harmful, because it deprives me, the extension developer, access to see the ostensibly-invalid certificate and take action based on its contents

Therefore, I’m asking that, if it’s a bug, it be fixed; and, if it’s a design choice, that it be reconsidered for the above 2 reasons.

#2

I actually need to make a correction to the OP:

Firefox claims, when clicking on the green lock in the URL bar:

Connection not secure

You are not securely connected to this site.

You have added a security exception for this site

However despite the above message (2/3 of which is in a red font) being the UI’s side of the story, the webRequest.getSecurityInfo() API nevertheless dispenses the following object (pay special attention to the first line), copied directly out of the debugger console:

{
  "state": "secure",
  "cipherSuite": "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
  "keaGroupName": "P256",
  "signatureSchemeName": "RSA-PKCS1-SHA512",
  "isDomainMismatch": true,
  "isExtendedValidation": false,
  "isNotValidAtThisTime": false,
  "isUntrusted": true,
  "certificateTransparencyStatus": "not_applicable",
  "protocolVersion": "TLSv1.2",
  "certificates": [],
  "hsts": false,
  "hpkp": false
}

Now, clicking through to “View” the certificate on the UI does still reveal a certificate chain. For self-signed certs, this is 1-deep; for alt-CAs (e.g. U.S. DoD, CAcert), it’s 2- or 3-deep; but it’s definitely existent in both cases. And it’s not being exposed by the API.

(So, to be precise: the correction to the OP is that “certificates-being-empty” is redundant with isUntrusted, rather than with state=="secure". It’s still redundant, though—and the harmfulness stands, too.)

#3

I’m bumping this thread lest it get automatically-closed.

#4

Have you reported this as a bug on https://bugzilla.mozilla.org/ ?

#5

Yes, I just reported it earlier today: