Closed Bug 1579060 Opened 5 years ago Closed 5 years ago

mozilla::pkix tag definitions for issuerUniqueID and subjectUniqueID shouldn't have the CONSTRUCTED bit set


(NSS :: Libraries, defect, P1)



(firefox-esr60 wontfix, firefox-esr68 fixed, firefox69 wontfix, firefox70 fixed)

Tracking Status
firefox-esr60 --- wontfix
firefox-esr68 --- fixed
firefox69 --- wontfix
firefox70 --- fixed


(Reporter: stefan_matthaeus, Assigned: keeler)




(3 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

I open management https websites from server hardware like DELL iDRAC, VMWare ESXi, Webmin, etc. which only have self signed certificate with Firefox 69. (OS = Windows 10 1903)

Actual results:

Firefox displays:

Fehler: Gesicherte Verbindung fehlgeschlagen

Beim Verbinden mit idrac.server.fqdn trat ein Fehler auf. Sicherheitsbibliothek: Fehlerhaft formatierte DER-verschlüsselte Nachricht. Fehlercode: SEC_ERROR_BAD_DER


When clicking on (i) in front of the URL, it says connection is not safe (what is true due to self signed certificate on that device) , then click on ">" & more information, going to the security tab, it tells that the website has no owner and the website is not encrypted.

Expected results:

Open the website, like it still happened with Firefox 68.0.2 before.


I can understand, that self signed websites are not the acme of security. But does it really make sense to block them totally? Then it even it is no more possible to secure them on device installation/maintenance, as you can't get into the device's management interface to assign a secure certificate. This is an egg-chicken-problem and it would be required that the user can override such blocking like it has been before. Otherwise user can not secure the device through it's web based management interface.

Or, isn't it a feature, but it is a bug?

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 wouldn't be a self-signed issue, it sounds like the cert itself has an encoding problem.

Any chance you can attach the certificate to the bug? I am not sure what ASN.1 decoding changes we may have made that might have caused this, but that's how we're going to nail it down.


Flags: needinfo?(stefan_matthaeus)

Hello, how to attach screenshots from firefox, chrome and edge? Chrome&Edge warns because of self signed cert but I can overide and access. The website example is a Dell iDRAC server management website.

Base 64 encoded self signed certificate of the Dell iDRAC (saved using Chrome browser, Firefox does not offer as it does not detect the cerificate at all)


Flags: needinfo?(stefan_matthaeus)

Can you also attach a packet trace of the TLS handshake? Thanks!

Flags: needinfo?(stefan_matthaeus)

There are people that confirm the problem on reddit: site returns a SEC_ERROR_BAD_DER.
I also have all my development virtual machines that are not accessible with Firefox 69.0 x64. I need to use Chrome instead.

Seems to be limited to Win10 Pro x64.

Can you attach a packet trace of the TLS handshake? Thanks! Also maybe try disabling antivirus "connection scanning" if you have it enabled?

Flags: needinfo?(sccedric)
Attached file badssl.pcapng

Here is a trace with with the new update 69.0.1

Flags: needinfo?(sccedric)

Thanks! Unfortunately there's nothing that stands out in that packet trace that would result in that error. Can you use to find when this stopped working?

Flags: needinfo?(sccedric)
Closed: 5 years ago
Resolution: --- → INCOMPLETE

Just tested Firefox 69.0.2 - Bug is still not fixed. Dell iDRAC web interface still not working. Still SEC_ERROR_BAD_DER error.

Get an old DELL server, try yourself.

Flags: needinfo?(stefan_matthaeus)

@Dana: It's not because someone did not have time to test your request that you can just close the ticket.
With a clean profile, I got no problem with mozregression but I still have the problem on 69.0.2.
May be I don't know how to work correctly with mozregression.
I'll retry as soon as I can with my profile as source.

@Stefan: If they did not mark it as confirm, it is because they don't reproduce it. You need not to be so condescending with a "Go buy a server!".

We are seeing a similar issue with a self-signed certificate used by our internal application on Firefox 69. (Worked with prior versions.) When Firefox 69 tries to use the certificate SEC_ERROR_BAD_DER is displayed, and no option to accept the certificate.

Let me know if another data point would be useful, and I can provide specifics.

Wayne, Cédric, and Stefan, can you try with a recent nightly? ( This bug may have the same cause as bug 1570222, which was recently fixed.

Flags: needinfo?(wayne.holmes)

I have checked in a virtual machine the recent nightly, it's not fixed. You can check by yourself by opening or the https idrac management interface of a Dell R610 server (this is the oldest machine I could test, I can see US offers for working machine for just 49 bucks).

Please note, like said on above reddit posting, that in about:config the setting "security.enterprise_roots.enabled" must be set to "true" to reproduce the issue. This is default here in this company (I think, done through GPO), and the setting is greyed out in about:config, so it can't be changed by user. (I don't like to use Chrome instead of FF to go arround that issue.)

So you need to reopen that issue and investigate.

Flags: needinfo?(dkeeler)

I confirm Stefan assomption about "security.enterprise_roots.enabled" preference.
I removed it in my C:\Program Files\Mozilla Firefox\mozilla.cfg and I get now the self-signed error back.

With the enterprise roots feature enabled, can you please try:

  • enabling the browser console by setting to true in about:config
  • opening the browser console (ctrl + shift + j)
  • running Cc[";1"].getService(Ci.nsINSSComponent).getEnterpriseRoots() and Cc[";1"].getService(Ci.nsINSSComponent).getEnterpriseIntermediates()
  • copying the output (best with right-click and Copy object)
  • attaching the output to this bug in a text file
Flags: needinfo?(dkeeler)
Resolution: INCOMPLETE → ---
Attached file enterprise.txt

Here, the requested command results.
Good luck !

Flags: needinfo?(sccedric)

Thanks! It appears the definitions mozilla::pkix is using for the tags for issuerUniqueID and subjectUniqueID (optional certificate fields that, evidently, aren't used much) have been incorrect since we shipped it 5 years ago (since the underlying type is BIT STRING, which is a "primitive" type, it shouldn't have the CONSTRUCTED bit set).

Assignee: nobody → nobody
Component: Security: PSM → Libraries
Ever confirmed: true
Flags: needinfo?(wayne.holmes)
Product: Core → NSS
QA Contact: jjones
Summary: SEC_ERROR_BAD_DER with Firefox 60 on websites with self signed certificate → mozilla::pkix tag definitions for issuerUniqueID and subjectUniqueID shouldn't have the CONSTRUCTED bit set
Version: 69 Branch → other

I am unable to turn off "security.enterprise_roots.enabled" as it shows as "locked" when I do an about:config using the corporate customized version of Firefox. Is there another workaround until this gets fixed and released to an ESR?

According to RFC 5280, the definitions of issuerUniqueID and subjectUniqueID in
TBSCertificate are as follows:

issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,

where UniqueIdentifier is a BIT STRING.

IMPLICIT tags replace the tag of the underlying type. For these fields, there is
no specified class (just a tag number within the class), and the underlying type
of BIT STRING is "primitive" (i.e. not constructed). Thus, the tags should be of
the form CONTEXT SPECIFIC | [number in class], which comes out to 0x81 and 0x82,

When originally implemented, mozilla::pkix incorrectly required that the
CONSTRUCTED bit also be set for these fields. Consequently, the library would
reject any certificate that actually contained these fields. Evidently such
certificates are rare.

Assignee: nobody → dkeeler
Priority: -- → P1

checkin for NSS_3_47_BETA2

Flags: needinfo?(jjones)
Keywords: checkin-needed
Flags: needinfo?(jjones)
Flags: needinfo?(dkeeler)

Dealing with this in bug 1588567.

Flags: needinfo?(dkeeler)
Closed: 5 years ago5 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 3.47

Hello, I like to confirm, with Firefox 70, installed today, I am again able to open Dell iDRAC and

Thanks for fixing!

Thanks, also fixed for me.

Confirmed our app is now working with Firefox 70.


Is this something likely to bite in an enterprise environment such that we should consider backporting to NSS 3.44 for ESR68 as well?

Yes - this is likely to affect enterprise users.

Flags: needinfo?(dkeeler)
See Also: → 1705732
You need to log in before you can comment on or make changes to this bug.