'unable to get local issuer certificate' on connect t specific website

sevendogs · 2025-05-14 17:31:58

loqs wrote:

Has anyone affected reported the issue to any upstream? How is using an old version of the ca-certificates-mozilla package considered a fix rather than a work around?

That does seem odd, except maybe unless the CA cert in question was revoked and that’s why it’s not included in 311. Agree reporting upstream is a good idea.

loqs · 2025-05-14 17:45:22

sevendogs wrote:

That does seem odd, except maybe unless the CA cert in question was revoked and that’s why it’s not included in 311.

I could not identify any certificate additions, removals or revocations in post #23 in the 311 release. Have you been able to identify any?

seth · 2025-05-14 19:12:44

--- mozilla.trust.p11-kit	2025-05-02 04:29:22.000000000 +0200
+++ /usr/share/ca-certificates/trust-source/mozilla.trust.p11-kit	2025-03-29 21:17:13.000000000 +0100
@@ -7,7 +7,7 @@
 # Source: nss/lib/ckfw/builtins/nssckbi.h
 #
 # Generated from:
-# NSS_BUILTINS_LIBRARY_VERSION "2.76"
+# NSS_BUILTINS_LIBRARY_VERSION "2.74"
 #
 [p11-kit-object-v1]
 label: "ACCVRAIZ1"
@@ -2468,7 +2468,7 @@ AgEGMAoGCCqGSM49BAMDA2gAMGUCMBq8W9f+qdJU
 label: "Baltimore CyberTrust Root"
 class: x-certificate-extension
 object-id: 2.5.29.37
-value: "0%16%06%03U%1d%25%01%01%ff%04%0c0%0a%06%08%2b%06%01%05%05%07%03%04"
+value: "0 %06%03U%1d%25%01%01%ff%04%160%14%06%08%2b%06%01%05%05%07%03%04%06%08%2b%06%01%05%05%07%03%01"
 modifiable: false
 -----BEGIN PUBLIC KEY-----
 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAowS7IquYPVfoJnKatXnU
@@ -5021,7 +5021,7 @@ rg3bhzjlP1v9mxnhMUF6cKojawHhRUzNlM47ni3n
 label: "Comodo AAA Services root"
 class: x-certificate-extension
 object-id: 2.5.29.37
-value: "0%16%06%03U%1d%25%01%01%ff%04%0c0%0a%06%08%2b%06%01%05%05%07%03%04"
+value: "0 %06%03U%1d%25%01%01%ff%04%160%14%06%08%2b%06%01%05%05%07%03%04%06%08%2b%06%01%05%05%07%03%01"
 modifiable: false
 -----BEGIN PUBLIC KEY-----
 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvkCd9G7h6naHHE1FRI6+
@@ -7681,7 +7681,7 @@ gKDWHrO8Dw9TdSmq6hN35N6MgSGtBxBHEa2HPQfR
 label: "Entrust.net Premium 2048 Secure Server CA"
 class: x-certificate-extension
 object-id: 2.5.29.37
-value: "0%16%06%03U%1d%25%01%01%ff%04%0c0%0a%06%08%2b%06%01%05%05%07%03%04"
+value: "0 %06%03U%1d%25%01%01%ff%04%160%14%06%08%2b%06%01%05%05%07%03%04%06%08%2b%06%01%05%05%07%03%01"
 modifiable: false
 -----BEGIN PUBLIC KEY-----
 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArU1LqRKGsuqjIAcVFmQq
@@ -9363,7 +9363,7 @@ xwy8p2Fp8fc74SrL+SvzZpA3
 label: "GlobalSign Root CA"
 class: x-certificate-extension
 object-id: 2.5.29.37
-value: "0%16%06%03U%1d%25%01%01%ff%04%0c0%0a%06%08%2b%06%01%05%05%07%03%04"
+value: "0 %06%03U%1d%25%01%01%ff%04%160%14%06%08%2b%06%01%05%05%07%03%04%06%08%2b%06%01%05%05%07%03%01"
 modifiable: false
 -----BEGIN PUBLIC KEY-----
 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7mmY3Oo+NPin778YuD
@@ -10161,10 +10161,25 @@ s8H2PA==
 #        92:e3:04:d1:7a:42:8a:75:90:59:e3:9b:d1:4c:a2:64:bd:73:
 #        79:9b:6f:f2:b3:c1:f6:3c
 
+[p11-kit-object-v1]
+label: "Go Daddy Class 2 CA"
+class: x-certificate-extension
+object-id: 2.5.29.37
+value: "0 %06%03U%1d%25%01%01%ff%04%160%14%06%08%2b%06%01%05%05%07%03%04%06%08%2b%06%01%05%05%07%03%01"
+modifiable: false
+-----BEGIN PUBLIC KEY-----
+MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEA3p3X6lcYSaFb69dfSIbq
+vt3/5O9nHPRlaLNXcaBed7vtm0npcIA9VhhjCG/a8szQP38CVCJUENiygdTAdT1L
+f8d3wz54qxoDtSBrL2orscWIfsS7HrDB2EUnb6o3WPeHJtfYLfapF7cfcjZOphc/
+ZZiS2ypuXaL+iOAL3n/ljRXh68s61eISohMt2I6vXxI9oAgFCLZcpWU4BEWZHqNg
+YHTFQaVyYhtixR9vXxpCvgJRZaiuIxhq/HgDqU1/gMP6q1r8oUCkyhkW/rLI715z
+De53vZr2eZi8sQdnohUN3aBYxkR7Cj5iKF+6QQdTWM8Rfjh0xfj/tWmQj4R06pcb
+rwIBAw==
+-----END PUBLIC KEY-----
 
 [p11-kit-object-v1]
 label: "Go Daddy Class 2 CA"
-trusted: false
+trusted: true
 nss-mozilla-ca-policy: true
 modifiable: false
 nss-server-distrust-after: "%00"
@@ -16150,10 +16165,25 @@ QFH1T/U67cjF68IeHRaVesd+QnGTbksVtzDfqu1X
 #        85:48:ac:1d:6a:dd:39:69:e4:e1:79:78:be:ce:05:bf:a1:0c:
 #        f7:80:7b:21:67:27:30:59
 
+[p11-kit-object-v1]
+label: "Starfield Class 2 CA"
+class: x-certificate-extension
+object-id: 2.5.29.37
+value: "0 %06%03U%1d%25%01%01%ff%04%160%14%06%08%2b%06%01%05%05%07%03%04%06%08%2b%06%01%05%05%07%03%01"
+modifiable: false
+-----BEGIN PUBLIC KEY-----
+MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAtzLI/ulxpgSFrQwRZN/O
+Te/IAxiHP6Gr+zymn/DDodrU2G4rU5D7JKQ+hPCe6F/s5SdE9SimP3ve4CrwyK9T
+L57KBQGTHo9mHDmnTfpatnMEJWbrd3/nWcZKmSUUVOsmx/N/GdUwcI+vsEYq/63r
+Ke3Xn6oEh6PU+YmlNF/bQ5GCNtlmPLG4uYL9nDo+EMg77wZlZnqbGRg9/3FRPDAu
+X749d3OyXQZswyNWmiuFJpIcpwKz5D8Nrwh5grg2Peqc0zWzvGnK9cyd6P1kjReA
+M25eSl2ZyR6HtJ0awNVuEzUjXt+bXz3v1vd2wuo+u3gNHEJnawTY+Nbab4vyRKAB
+qwIBAw==
+-----END PUBLIC KEY-----
 
 [p11-kit-object-v1]
 label: "Starfield Class 2 CA"
-trusted: false
+trusted: true
 nss-mozilla-ca-policy: true
 modifiable: false
 nss-server-distrust-after: "%00"
@@ -19436,7 +19466,7 @@ jjxDah2nGN59PRbxYvnKkKj9
 label: "XRamp Global CA Root"
 class: x-certificate-extension
 object-id: 2.5.29.37
-value: "0%16%06%03U%1d%25%01%01%ff%04%0c0%0a%06%08%2b%06%01%05%05%07%03%04"
+value: "0 %06%03U%1d%25%01%01%ff%04%160%14%06%08%2b%06%01%05%05%07%03%04%06%08%2b%06%01%05%05%07%03%01"
 modifiable: false
 -----BEGIN PUBLIC KEY-----
 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmCQevRW0ut/HjKUntjgL

There's also out comodo friend.

https://bugzilla.mozilla.org/show_bug.cgi?id=1957685
https://bugzilla.mozilla.org/show_bug.cgi?id=1937338

Seems very deliberate and means the affected domains must update their certificate chain.
The certificates have effectively been revoked w/o being marked compromised.
https://en.wikipedia.org/wiki/Planned_obsolescence

loqs · 2025-05-14 19:47:05

Conclusion the owner of the beamp.com domain needs to get a new certificate from ssl.com from a root certificate authority that still has its website trust bit set?

seth · 2025-05-14 20:48:18

"beammp.com", but it seems they got their certificate from cloudflare, CF used https://ssl-tools.net/subjects/94b4fbe6 … e5cd855ea5 and that was issued by the CA certificate that had its website bit withdrawn.
Don't ask me where to put the onus - essentially comodo should™ have migrated the certificate, ssl.com should™ have caught that they're about to lose the trust on their certificate and migrated theirs and beammp.com probably has only ever talked to cloudflare.

beammp.com (and others) need to know that they're about to lose https and then bubble this up

loqs · 2025-05-14 20:58:21

I guess other OS users will encounter the issue with browser updates that incorporate the same change unless it is Mozilla only.

seth · 2025-05-14 21:25:19

chromium uses its own trust store, if mozilla doesn't apply this to FFs truststore (I'll call them bigots, but)it would only affect non-browser network clients relying on mozillas certificates.
Even iff, the browsers will likely tell "can't verify, add execption and continue?" and then allow the "insecure" connection at which point this move would become actively harmful by training users to do dumb things…
No idea how many domains are affected by this ("cloudflare"…) but I'm willing to deem undoing change a perfectly valid solution.
There's no actual problem, mozilla has untrusted those certificates because it's 2025 and if the CAs disagree and this turns into a stand-off, users will effectively side w/ the CAs and want to undo this because they just want their internet to work.

If any of this was in the news, that has completely escaped me.

cryptearth · 2025-05-14 22:21:15

well - someone seem to have fucked up big time - in both directions
according to RFC 5280 and its earlier versions the extended key usage extension should not be part of a root or intermediate certificate anyway but only of end entitiy certificates - as the root and intermediate certificates are used only for verification of the certs signed with thier key
likewise an application shouldn't even bother if an intermediate or root certificate has the extended key usage extension or if its set shouldn't check its value as 1) extended key usage should be marked non-critical anyway and 2) when using an upper-level certificate to build a trust chain its the key usage having set keycertsign set
so curl failing because the root certificate it resolves doesn't have extended key usage set seems to be an additional bug it the underlying tls code it uses (likely openssl?) to improper check for an extension not required for trust path validation
this is quite a mess of an card house already missing some cards yet somehow still stands
I question that 5280 is followed here correctly by whatever code is checking it - and I highly question why some of those root ca certs even have this extension set at all - and why removing it causes this issue in the first place as it shouldn't according to 5280

seth · 2025-05-15 06:29:32

"should" …

May 2008 [though 3280 doesn't critically differ] … In general, this extension will appear only in end entity certificates … MAY, at the option of the certificate issuer, be either critical or non-critical … If the extension is present, then the certificate MUST only be used for one of the purposes indicated … using applications MAY require that the extended key usage extension be present and that a particular purpose be indicated

and https://wiki.mozilla.org/index.php?titl … id=1252981 doesn't argue at all "oh, root CAs should not have this so we need to remove this erroneous bit".
The reasoning there is "it's 2025".

CyberPingU · 2025-05-16 22:13:24

I didn't downgrade anything.
I just took the AAA Service pem certificate from https://certificate.fyicenter.com/350_A … 0A4B4.html https://www.sectigo.com/knowledge-base/ … 00000117cL , saved it into an aaa.pem file and then

sudo mkdir -p /etc/ca-certificates/trust-source/anchors/
sudo cp aaa.pem /etc/ca-certificates/trust-source/anchors/aaa.crt
sudo trust extract-compat
openssl verify -CAfile /etc/ssl/certs/ca-bundle.crt /etc/ca-certificates/trust-source/anchors/aaa.crt

EDIT:
as per seth comments (down this one), I admit the mistake and I changed the link.
As per Sectigo is used as CA provider for us (government) so I'm confident.

Last edited by CyberPingU (2025-05-17 08:35:04)

seth · 2025-05-17 05:25:49

Where's the step where you verified that the random certificate you got from somewhere on the internet is actually legit?
Why did you not download the crl from comodo directly and converted it locally?

loqs pointed out that downgrading is neither a scalable nor sustainable solution to this situation, but you found an approach that's actually much worse than that.
PSA: Do not just incorporate random root CAs you found on the internet. You might disagree with mozilla's vetting results but at least the do some vetting.
Don't forget to retract the trust once the certificate has fallen out of fashion and gets compromised.

Also this leaves another half-a-dozen or so CAs broken + another dozen next year and then some in 2027…

Arch Linux

#26 2025-05-14 17:31:58

Re: 'unable to get local issuer certificate' on connect t specific website

#27 2025-05-14 17:45:22

Re: 'unable to get local issuer certificate' on connect t specific website

#28 2025-05-14 19:12:44

Re: 'unable to get local issuer certificate' on connect t specific website

#29 2025-05-14 19:47:05

Re: 'unable to get local issuer certificate' on connect t specific website

#30 2025-05-14 20:48:18

Re: 'unable to get local issuer certificate' on connect t specific website

#31 2025-05-14 20:58:21

Re: 'unable to get local issuer certificate' on connect t specific website

#32 2025-05-14 21:25:19

Re: 'unable to get local issuer certificate' on connect t specific website

#33 2025-05-14 22:21:15

Re: 'unable to get local issuer certificate' on connect t specific website

#34 2025-05-15 06:29:32

Re: 'unable to get local issuer certificate' on connect t specific website

#35 2025-05-16 22:13:24

Re: 'unable to get local issuer certificate' on connect t specific website

#36 2025-05-17 05:25:49

Re: 'unable to get local issuer certificate' on connect t specific website

Board footer