Your message dated Mon, 23 Feb 2026 16:29:22 +0100
with message-id <[email protected]>
and subject line Re: Bug#1128593: Disable CAs that doesn't offer Certificate
Transparency or similar
has caused the Debian Bug report #1128593,
regarding Disable CAs that doesn't offer Certificate Transparency or similar
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1128593: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1128593
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: ca-certificates
Version: 20250419
Severity: wishlist
Quoting a recent security update for 'ca-certificates':
> Mozilla certificate authority bundle was updated to version 2.60
> The following certificate authorities were added (+):
> + "AC RAIZ FNMT-RCM SERVIDORES SEGUROS"
> + "ANF Secure Server Root CA"
> + "Autoridad de Certificacion Firmaprofesional CIF A62634068"
> + "Certainly Root E1"
> + "Certainly Root R1"
> + "Certum EC-384 CA"
> + "Certum Trusted Root CA"
> + "D-TRUST BR Root CA 1 2020"
> + "D-TRUST EV Root CA 1 2020"
> + "DigiCert TLS ECC P384 Root G5"
> + "DigiCert TLS RSA4096 Root G5"
> + "E-Tugra Global Root CA ECC v3"
> + "E-Tugra Global Root CA RSA v3"
> + "GlobalSign Root R46"
> + "GlobalSign Root E46"
> + "GLOBALTRUST 2020"
> + "HARICA TLS ECC Root CA 2021"
> + "HARICA TLS RSA Root CA 2021"
> + "HiPKI Root CA - G1"
> + "ISRG Root X2"
> + "Security Communication ECC RootCA1"
> + "Security Communication RootCA3"
> + "Telia Root CA v2"
> + "TunTrust Root CA"
> + "vTrus ECC Root CA"
> + "vTrus Root CA"
Not thinking of any of those CAs specifically, but generally, I wonder
if Debian's users are served by having all of the WebPKI CAs enabled by
default.
Including any public CA certificate is definitely useful, for users to
be able to find necessary trust-points in a simple manner.
However enabling them all by default, which allow any of the CAs to
successfully MITM your TLS connections for any application using the
bundles, (should) trigger some additional concerns and review.
Right now there doesn't seem to be any distinction between the two cases
above, and the Debian criteria looks effectively like accept-all.
By "enabling" I mean including them in the global
/etc/ssl/certs/ca-certificates.crt bundle.
Could Debian establish a set of criteria for which CAs to enable by
default?
One simple criteria could be that the CA supports Certificate
Transparency and offer a public log of all their issued certificates, so
that people can audit the CA and look for issued MITM certs like
*.google.com or similar.
We shouldn't cause user TLS certification errors needlessly as a
consequence of a change like this. I suspect that the majority of
end-entity certs would be covered by the well-known CAs that has
supported Certificate Transparency for many years. Doing experiments
with which CAs are important to enable by default could be done.
Thoughts?
/Simon
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
On 2/21/26 18:25, Simon Josefsson wrote:
Package: ca-certificates
Version: 20250419
Severity: wishlist
Quoting a recent security update for 'ca-certificates':
Mozilla certificate authority bundle was updated to version 2.60
The following certificate authorities were added (+):
+ "AC RAIZ FNMT-RCM SERVIDORES SEGUROS"
+ "ANF Secure Server Root CA"
+ "Autoridad de Certificacion Firmaprofesional CIF A62634068"
+ "Certainly Root E1"
+ "Certainly Root R1"
+ "Certum EC-384 CA"
+ "Certum Trusted Root CA"
+ "D-TRUST BR Root CA 1 2020"
+ "D-TRUST EV Root CA 1 2020"
+ "DigiCert TLS ECC P384 Root G5"
+ "DigiCert TLS RSA4096 Root G5"
+ "E-Tugra Global Root CA ECC v3"
+ "E-Tugra Global Root CA RSA v3"
+ "GlobalSign Root R46"
+ "GlobalSign Root E46"
+ "GLOBALTRUST 2020"
+ "HARICA TLS ECC Root CA 2021"
+ "HARICA TLS RSA Root CA 2021"
+ "HiPKI Root CA - G1"
+ "ISRG Root X2"
+ "Security Communication ECC RootCA1"
+ "Security Communication RootCA3"
+ "Telia Root CA v2"
+ "TunTrust Root CA"
+ "vTrus ECC Root CA"
+ "vTrus Root CA"
Not thinking of any of those CAs specifically, but generally, I wonder
if Debian's users are served by having all of the WebPKI CAs enabled by
default.
Including any public CA certificate is definitely useful, for users to
be able to find necessary trust-points in a simple manner.
However enabling them all by default, which allow any of the CAs to
successfully MITM your TLS connections for any application using the
bundles, (should) trigger some additional concerns and review.
Right now there doesn't seem to be any distinction between the two cases
above, and the Debian criteria looks effectively like accept-all.
By "enabling" I mean including them in the global
/etc/ssl/certs/ca-certificates.crt bundle.
Could Debian establish a set of criteria for which CAs to enable by
default?
One simple criteria could be that the CA supports Certificate
Transparency and offer a public log of all their issued certificates, so
that people can audit the CA and look for issued MITM certs like
*.google.com or similar.
We shouldn't cause user TLS certification errors needlessly as a
consequence of a change like this. I suspect that the majority of
end-entity certs would be covered by the well-known CAs that has
supported Certificate Transparency for many years. Doing experiments
with which CAs are important to enable by default could be done.
The policy is effectively to ship webpki CAs trusted by mozilla for TLS
servers. Which does imply logging certificates, nowadays, so I don't
think there's anything more to do here.
Cheers,
Julien
--- End Message ---
