Dear maintainer,

One of our partners (an American health insurance company) recently changed
the certificates for their API and this broke our connectivity. This report is
similar to #1095913 since it also involves certificates issued by Entrust, but
the root missing in question is "SSL.com TLS RSA Root CA 2022" and not one from
Sectigo. We were able to work around it by manually adding this root
certificate and running update-ca-certificates.

After doing so the chain looks like this with openssl s_client:
depth=2 C=US, O=SSL Corporation, CN=SSL.com TLS RSA Root CA 2022 verify return:1
depth=1 C=US, O=SSL Corporation, CN=Entrust OV TLS Issuing RSA CA 1
verify return:1
depth=0 [leaf cert details omitted] verify return:1

https://crt.sh/?id=7439767372 and https://crt.sh/?id=14258407195 respectively.

FWIW, on July 24, 2024 SSL.com posted this announcement about partnering with
Entrust:
https://www.ssl.com/blogs/ssl-com-and-entrust-form-strategic-partnership/

Same as with the aforementioned bug report, please consider adding the root CA
to ca-certificates in stable.

Kind regards,
Bart

Can confirm — hit the same issue on Debian 10 (buster, EOL) and Debian 12 (bookworm, ca-certificates 20230311+deb12u1, latest available) validating a certificate issued by SSL.com through "SSL.com TLS Issuing RSA CA R1", chaining to the same missing "SSL.com TLS RSA Root CA 2022" root. Worked around it the same way — manually adding the root cert and running update-ca-certificates. This is affecting production TLS validation for our infrastructure (client-facing services), not just a corner case. Would be good to see this root added to ca-certificates in stable, same as requested in the original report.

Reproduced the same issue on Debian 11 (bullseye), ca-certificates 20210119 — same missing root "SSL.com TLS RSA Root CA 2022", same chain (SSL.com TLS Issuing RSA CA R1 -> SSL.com TLS RSA Root CA 2022), same "unable to get local issuer certificate" (depth 1) failure.
This confirms the issue spans multiple Debian releases still in active support (bullseye, bookworm), not just an edge case on a single suite. Worked around it the same way on all affected hosts — manually adding the root certificate and running update-ca-certificates.
Given SSL.com's TLS RSA Root CA 2022 has been in Mozilla's trust store since 2023 (per bug 1799533 in Mozilla's tracker) and is already present in Debian's ca-certificates package in unstable/sid, it would be very helpful to see this backported to bullseye and bookworm via stable updates, since a growing number of CAs and their partners (Entrust, per the earlier report in this bug) are issuing under this root.

Happy to provide further logs/details if useful.

version: 20250419~deb12u1