Non-compromised certs from ca_root_nss are blacklisted by the recent update

karolyi

karolyi

Hey,

bugs.freebsd.org. isn't working (HTTP 503 all the time) so I'm posting it here in hopes of catching the attention from someone from devs/staff:

The recent security update blacklisted certs that seemingly haven't been compromised. the package ca_root_nss contains two of them:
  • emSign ECC Root CA - C3
  • emSign Root CA - C1
The problem is, anyone who has the ca_root_nss package installed, will get these blacklisted (but not compromised), and freebsd-update will want to remove them.

They were not compromised (seemingly), information sources: https://emudhra.we-have-a-problem.com/ and the recent security advisory.

Upon running freebsd-update, it ill say that:

The following files are affected by updates. No changes have
been downloaded, however, because the files have been modified
locally:
/etc/ssl/cert.pem


The following files will be removed as part of updating to
15.1-RELEASE-p6:
/etc/ssl/certs/406c9bb1.0
/etc/ssl/certs/4b718d9b.0
Click to expand...

These are the two non-compromised keys, from my investigation.

Anyone who will have ca_root_nss installed (version 3.131 at the time of writing) can run into this issue. The package is required by lots of tools, rclone is one of them in my case. It installs certs into /usr/local/share/certs which certctl picks up and thus modifies /etc/ssl/certs.pem into a state that freebsd-update will reject.

Either this has to be rolled back (maybe with another update) or the certs be removed from ca_root_nss, the latter of which I don't think is a valid solution.
 
Since there aren't mechanisms available on all platforms/software to only block/remove intermediate CAs, it seems it is the agreed-upon procedure to phase out the root CAs that signed the compromised intermediates to break the trust chain.

Compromised eMudhra Intermediate Certificates

groups.google.com groups.google.com
Today, 20th October, we are also releasing an update to the trusted certificates list in NSS which removes the root certificate used to sign these intermediates. Although this change is not necessary for Firefox, this helps protect other users of our trust store or third party derivatives who do not benefit from the protection of OneCRL. This change will impact the availability of some servers for those non-Firefox users until those servers move to new certificate chains.
Click to expand...

NSS 3.131.1 Release - Important Security Updates

groups.google.com groups.google.com

Changes in NSS 3.131.1​

This release removes trust in the following root certificates:

Click to expand...

Also: the port simply pulls the tarball from upstream and prepares/compiles/packages it. It doesn't contain any decision-making on what CAs to trust/distrust or remove.


edit:

OH.
MY.
GOD.

2083449 - eMudhra: Private key compromise of Intermediate Certificates

ASSIGNED (naveen.ml) in CA Program - CA Certificate Compliance. Last updated 2026-10-22.
bugzilla.mozilla.org bugzilla.mozilla.org
After Wayne's report of key recovery, I was able to recover the private keys for the impacted keys trivially. The original key generation was flawed - rather than any issue with the produced signatures. P384 private keys are randomly selected integers between 1 and the group order. The 8 impacted keys all used integers less than 256. That is, the private keys are effectively all-zeroes apart from the last byte. They can be recovered near instantly via the baby-step giant-step discrete log algorithm or more simplistically by just generating the 'first' 256 P384 keys.
Click to expand...

It is 110% the correct choice to remove this CA completely from any trust store...


edit2:

aaaand they're dead:

eMudhra to Exit global SSL/TLS Certificate Business

eMudhra Limited (BSE: 543533 | NSE: EMUDHRA), a global digital trust company, today announced that its Board has decided to voluntarily withdraw from the global SSL/TLS certificate business.
emudhra.com emudhra.com

TBF, given their horrific history surfacing in that de-restricted bug at mozilla, I highly doubt they would have kept their status as a trusted CA anyways...
So, its time for another update of ca_root_nss and caroot
 
On 14.5 release, I get
# freebsd-update fetch
...
Inspecting system... done.
Preparing to download files... done.
The following files will be removed as part of updating to
14.5-RELEASE-p3:
/etc/ssl/certs/4b718d9b.0
The following files will be updated as part of updating to
14.5-RELEASE-p3:
/etc/ssl/certs/36c6b318.0
/etc/ssl/certs/422cf4bf.0
/etc/ssl/certs/9cd9d94b.0
/etc/ssl/certs/faf4fe6b.0
/etc/ssl/untrusted/14bc7599.0
/etc/ssl/untrusted/3dbee7d3.0
/etc/ssl/untrusted/3ed72a2f.0
/etc/ssl/untrusted/b548496f.0
/etc/ssl/untrusted/e36a6752.0
/etc/ssl/untrusted/eb784c64.0

Then
# freebsd-update install
Installing updates...certctl: Skipping untrusted certificate 14bc7599 (/etc/ssl/untrusted/14bc7599.0)
done.

Does that seem reasonable? Do I need to do anything more? Why did it skip one of the untrused certs?
 
ding ding ding - aand we may have another contestant in the ring that possibly shouldn't be trusted to be a major CA...
www.heise.de

GoDaddy revokes hundreds of thousands of certificates over documentation errors

Because they don’t match their documentation, GoDaddy must revoke 404,607 certificates, including those used by companies such as Host Europe and DomainFactory.
www.heise.de www.heise.de

I really hope those incidents will lead to a larger scale scrutiny of the whole (deeply flawed) CA ecosystem we currently have in place.
 
You must log in or register to reply here.
Back
Top