www.authorize.net certificate warning in Pale Moon

[dolphin]

What causes https://www.authorize.net/ to produce a red certificate error in Pale Moon but works fine in chrome and edge.

Pale Moon says:

www.authorize.net uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. The server might not be sending the appropriate intermediate certificates. An additional root certificate may need to be imported. (Error code: SEC_ERROR_UNKNOWN_ISSUER)

[suzyne]

Can confirm. Edge shows the details in the first pic for the certificate, but in Pale Moon there isn't even a button in the usual position to view the certificate.

Clipboard_06-21-2025_02.png

Clipboard_06-21-2025_01.png

[mmouse]

Hello

while I am certainly no expert in web certificates, I'd go out on a limb and suggest that Palemoon does not support the root certificate used by the transient Cloudflare certificate.
While inspecting the thing in Palemoon (by using 'Add security exception' and clicking on 'view' and then 'details', the root authority appears as
'''
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
Validity
Not Before: Jan 1 00:00:00 2004 GMT
Not After : Dec 31 23:59:59 2028 GMT
Subject: C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:be:40:9d:f4:6e:e1:ea:76:87:1c:4d:45:44:8e:
be:46:c8:83:06:9d:c1:2a:fe:18:1f:8e:e4:02:fa:
f3:ab:5d:50:8a:16:31:0b:9a:06:d0:c5:70:22:cd:
49:2d:54:63:cc:b6:6e:68:46:0b:53:ea:cb:4c:24:
c0:bc:72:4e:ea:f1:15:ae:f4:54:9a:12:0a:c3:7a:
b2:33:60:e2:da:89:55:f3:22:58:f3:de:dc:cf:ef:
83:86:a2:8c:94:4f:9f:68:f2:98:90:46:84:27:c7:
76:bf:e3:cc:35:2c:8b:5e:07:64:65:82:c0:48:b0:
a8:91:f9:61:9f:76:20:50:a8:91:c7:66:b5:eb:78:
62:03:56:f0:8a:1a:13:ea:31:a3:1e:a0:99:fd:38:
f6:f6:27:32:58:6f:07:f5:6b:b8:fb:14:2b:af:b7:
aa:cc:d6:63:5f:73:8c:da:05:99:a8:38:a8:cb:17:
78:36:51:ac:e9:9e:f4:78:3a:8d:cf:0f:d9:42:e2:
98:0c:ab:2f:9f:0e:01:de:ef:9f:99:49:f1:2d:df:
ac:74:4d:1b:98:b5:47:c5:e5:29:d1:f9:90:18:c7:
62:9c:be:83:c7:26:7b:3e:8a:25:c7:c0:dd:9d:e6:
35:68:10:20:9d:8f:d8:de:d2:c3:84:9c:0d:5e:e8:
2f:c9
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
A0:11:0A:23:3E:96:F1:07:EC:E2:AF:29:EF:82:A5:7F:D0:30:A4:B4
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.comodoca.com/AAACertificateServices.crl
Full Name:
URI:http://crl.comodo.net/AAACertificateServices.crl
Signature Algorithm: sha1WithRSAEncryption

'''
using certutil on the database provided with last distributed version, I see 3 Comodo root certificates using RSA, and certainly none of them using the (long deprecated) sha1 algo.
This is strange, and the real question is why are other browsers accepting this old thing ? I looked at a recent Firefox installation and it seems that these great guys have added yet another undocumented file format to their vast collection, somthing called data.safe.bin that *seems* to hold some version of root (or is it intermediate) certificates. Certainly cert9.db does not do that anymore. So it's unclear how to examine the root. Well, I bailed out and examined the database in the Web interface, and sure this darn old thing is still here and considered as valid. So it seems that maybe Palemoon was too eager to deprecate old root certificates :-/

Update: my mistake, this root certificate exists in current Palemoon configuration, it's issued by Comodo but I was fooled by it appearing under the name 'AAA Certificate services'. So I don't know yet why this appears as invalid.

Update2: there was this setting sha1_enforcement_level that used to exist in Firefox at some point but don't anymore, and it still exists in the Palemoon configuration but does not seem to have any reference in source code. Setting browser.xul.error_pages.expert_bad_cert to true brings this pearl of wisdom:

The certificate is not trusted because the issuer certificate is unknown.
The server might not be sending the appropriate intermediate certificates.
An additional root certificate may need to be imported.

That's not bringing too much light :-/

I think I am beginning to understand now; Cloudflare is offering 2 different certificates, one with RSA and one with ECC according to the following answer:

https://stackoverflow.com/questions/620 ... rtificates

OpenSSL s_client picks the ECC one, while curl and Palemoon are picking the RSA one. However curl (8.5) is accepting the old certificate while Palemoon does not like it. My guess is this sha1 signature is the root cause.

update 3: that's it, I have browsed the recent release notes and stumbled on this one:
v33.7.1 (2025-05-06)
This is bugfix and security release.

Changes/fixes:

Fixed a crash dealing with BigInt in Javascript compilation.
Updated NSS to 3.90.7 to pick up a security fix.
Updated devtools to escape some more characters in "Copy as cURL" on POSIX operating systems. DiD

NSS is the Mozilla library that deals with certificate authorities; trying out 33.7.0, it is working for authorize.net so it's about 99% probable that this NSS upgrade is the culprit.

[Moonchild]

It seems the certificate data for root certs I adopted from Mozilla has been incorrect, leading to this issue (and potentially some other sites not being trusted).
I'll revert what was added in our copy of NSS in the root cert refresh performed a few point releases ago. I tested with the changes reverted and it passes for www.authorize.net in that case.
I'm not sure why this works for Mozilla despite this problem.

[mmouse]

Well, looking a bit more at the difference between 33.7.0 and 33.7.1, the only thing that matters is the trust for the AAA Services certificate from Comodo. The change has removed the trust for web services, keeping its use only for mail. Checking web server for the AAA Services certificate in current Palemoon is sufficient to make the configuration work normally.

Not sure at all, but could the Firefox trick be just ignoring this web server trust configuration for root certificates ? After all, one is not supposed to use these certificates directly, so maybe the trust level don't matter. I have never checked if these certificate usages have really a meaning for the root certificate authorities, or if they can validate any use for leaf certificates; a quick Internet search returned nothing of interest.
I looked a bit a some root certificates, and Comodo is not the only one for which a root certicate exists that don't have 'web server' checked (see for example Staat of Nederland). I have no definite answer, my guess is that for a root certificate what really matters is the use to actually sign lower level certificates.

Edit: after a glass of water, the security change has hit me: if there is now realist ways to break sha1, direct use of this certificate to validate a web site could be possible. So invalidating the use at the browser level makes sense.

[Moonchild]

Root certs are part of the trust chain. If a root cert isn't allowed to authorize web servers, then it breaks the chain of trust for certs below it. So if the change was AAA becoming untrusted for web servers, then it makes sense that any chain relying on it would also not be trusted. Mozilla obviously changed something elsewhere to change that behaviour (but I don't know where, off-hand)

I may fine-tune the cert store before the next release; I'll check next week.

[mmouse]

>>If a root cert isn't allowed to authorize web servers, then it breaks the chain of trust for certs below it.

It does not seem to work like that for Firefox. Looking at Chrome, there is no such thing at all in the root certificates in the store.
This usage is typically not included in the root certificates (field 'key usage'). Looking at duckduckgo.com, the web server itself (obviously) and the intermediate authority certificates have an 'extended key usage', not the root certificate itself. It could be possible that the chain of trust is only necessary from the parent intermediate certificate, not all certificates in the chain.
So it seems that this information (web, mail use) is added by NSS, not extracted from the root certificates.

[Moonchild]

It does not seem to work like that for Firefox.

Seems to me like it should, though? I mean, logically speaking, you'd expect being allowed to authorize something would only get stronger if you go up a chain of trust/authority. But here it would get weaker at the root level?

[mmouse]

Seems to me like it should, though? I

Not sure of that; facts can be explained as well by assuming that higher level certificates are intended only to validate lower level certs, so they can validate certificates having different goals; that's why they don't have a extended key usage field. Once at a given level an intermediate certificate adds an extended key usage field, at lower levels (sub-leaves) it's only possible to narrow the scope but only when a specialization has been included. I think that's what is implied in 5.3.1 of this page: https://www.mozilla.org/en-US/about/gov ... ts/policy/ : root certificates can be not 'technically constrained'.

[Moonchild]

I guess you could look at it both ways...
Either way I'll find some solution.

[mmouse]

I have investigated a bit more using key decryption. What I can say is that there is no difference between queries and server replies between Palemoon 33.7.0 and 33.7.1. The only thing that change is that after receiving the certificates Palemoon bails out and sends an alert 'unknown CA' to the server. So it confirms that the difference is indeed the changed state for the root certificate in nss configuration done here:

ommit 95fc9e6b026230f1e6dffe48d7971b1211fac3bf (tag: NSS_3_111_BETA1)
Author: xxxx xxxxx <xxxx@mozilla.com>
Date: Wed Apr 16 15:18:33 2025 +0000

Bug 1957685 - Turn off Websites Trust Bit from CAs. r=yyyyy

Differential Revision: https://phabricator.services.mozilla.com/D245737

--HG--
extra : moz-landing-system : lando


so far so good. Now looking at Firefox behaviour nothing is clear unfortunately (139.0.4). I see 4 attempts at doing a Tls key exchange, all terminating by the server returning the last certificate in the chain being issued by the accursed AAA services. Firefox should refuse it, and indeed I see (maybe because my whole setup is slow) a brief message saying that the connection is not secure, and then the Cloudflare challenge is displayed and ... the connection is now secure, and looking at the certificate the chain is identical except for the root that is mysteriously changed into a recent root certificate (SSL.com TLS ECC Root CA 2022)

As there is quite a lot of traffic (Firefox connecting to its ads and telemetry service and some other less clearly defined services, also attempts at connecting using Quick that don't succeed it seems) it's difficult to parse the Wireshark output, I could not find where this magical new root certificate was obtained. I'm sure that reading the Firefox source code and git log for a few (hours?)(days?)(weeks?) I could understand it. It's just that I definitely don't have weeks available; not even hours this week-end.
If someone wants to take a look at this trace file (pcap format) I can send it (dunno if the messages on this forum allow for a 800K attachment though).

[Moonchild]

Well, it just means that Mozilla code also distrusts AAA's root certificate, because the ssl.com root certificate is cert path #2 for that site (i.e. it relies on the cross-signing for the intermediate CA cert). And our implementation apparently does not, for some reason not yet known to me. Maybe it requires us to upgrade our NSS library, which I've been holding off on since there have been multiple changes in more recent NSS besides the sec fixes I ported back that are really not relevant to our surrounding code and could cause compatibility issues.

[mmouse]

@moonchild

After reading this:

https://www.ssltrust.com/blog/understan ... ss-signing

I am no wiser.
This seems more informative:

https://scotthelme.co.uk/cross-signing- ... they-work/

there could be 2 mechanisms, Authority Information Access but it don't seem to be what happens here (nothing like that in the downloaded certificates), and the CCADB, a database collating information about all certificate authority certificates (including intermediates, not only the roots).
Now that's interesting, a database managed by a restricted organization controlled by the 3 'big' browsers (and Cisco). Reading this:

https://www.ccadb.org/rootstores/bylaws

seems to make clear that being a member has for requirement (besides paying a bunch of money of course) to be big enough to issue ukases to certificate authorities. It's obvious that Palemoon (or any alternate browser) can't qualify (it's unsure for how long even Firefox will still qualify given its market share...). If an alternate browser can't get access to the CCADB, it is making it more difficult to manage corner cases.

Now to get back to this problem, there is certainly no mention of these intermediate certificates in the Firefox settings.

Ahah, after downloading Firefox source code, finally I think I nailed it. Hard-coding the intermediate cert (!):

commit 8acc8bc5ad8ef59a5986ca8b305c15c102467597
Author: xxx <xxxx@mozilla.com>
Date: Thu May 22 17:41:53 2025 +0000

Bug 1966632 - bundle cross-signed "SSL.com TLS Transit ECC CA R2" intermediate. r=xxx

Differential Revision: https://phabricator.services.mozilla.com/D250486

So Firefox is (probably) not loading the whole CCA db into the browser.

Don't explain why Firefox is displaying 'unsecure' briefly. A bug possibly ?

Also, I noticed from git log that Firefox is not following NSS either - however they are only 3 versions late, that's more up-to-date than Palemoon.

[Moonchild]

So, I was correct! The trust chain was indeed broken by them removing authorization from the AAA root, and the only reason it still works in Firefox is because they hard-coded ssl.com's cross-signed intermediate in the cert verifier of Firefox...
Even if we'd update NSS it would still be broken because of the same issue.

soooo... what I could do is simply add the intermediate to our certdata in NSS when we build it, and that should fix it.

[mmouse]

@moonchild

Yes that should be the best option.

[Moonchild]

It's effectively what Mozilla has done as well (the patch adds a mechanism to read the cert data and add it to the trust store. since it's only one cert so far even in ff-latest, I don't see a reason to spend too much time adding it to the python script when a simple copy/paste would work just fine.

[Goodydino]

What causes https://www.authorize.net/ to produce a red certificate error in Pale Moon but works fine in chrome and edge.

Pale Moon says:

www.authorize.net uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. The server might not be sending the appropriate intermediate certificates. An additional root certificate may need to be imported. (Error code: SEC_ERROR_UNKNOWN_ISSUER)

The error message I get is a bit different:
An error occurred during a connection to www.authorize.net. SSL received a malformed Server Hello handshake message. (Error code: SSL_ERROR_RX_MALFORMED_SERVER_HELLO)

[mmouse]

@goodydino

The error message I get is a bit different:

It could be a different problem, or a different manifestation of the same problem. If you did not read the thread, the advice was to open preferences, goto Advanced/Certitificates tab/View Certificates, select the 'AAA Certificates Services' for Comodo org, click 'edit trust' and check 'websites', validate and restart browser. Then try again. It's not a really valid fix but a work around before a browser update. HTH.

[Veit Kannegieser]

Similar for https://opencv.org/, where openssl s_client -showcerts -connect opencv.org:443 < /dev/null >openssl.opencv.report
would report
Certificate chain
0 s:CN = opencv.org
i:C = US, O = "CLOUDFLARE, INC.", CN = Cloudflare TLS Issuing ECC CA 1
a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA256
v:NotBefore: Jun 10 21:50:11 2025 GMT; NotAfter: Sep 8 21:54:08 2025 GMT
...
1 s:C = US, O = "CLOUDFLARE, INC.", CN = Cloudflare TLS Issuing ECC CA 1
i:C = US, O = SSL Corporation, CN = SSL.com TLS Transit ECC CA R2
a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA384
v:NotBefore: Oct 31 17:17:49 2023 GMT; NotAfter: Oct 28 17:17:48 2033 GMT
...
2 s:C = US, O = SSL Corporation, CN = SSL.com TLS Transit ECC CA R2
i:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
a:PKEY: id-ecPublicKey, 384 (bit); sigalg: RSA-SHA256
v:NotBefore: Jun 21 00:00:00 2024 GMT; NotAfter: Dec 31 23:59:59 2028 GMT
...

[mmouse]

@Veit Kannegieser

see above my reply to @goodydino, the workaround apply.