Hey.
Actually I think this should have a higher severity, since the
trusted certs may very well be quit security critical.
Nevertheless:
I just traced a bug for some hours, where it eventually turned out
that dpkg-reconfigure ca-certificates doesn't cause the changes to
be picked up by ca-certificates-java.
In the following I do the opposite (where it appens, too):
# dpkg-reconfigure ca-certificates
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL
0 added, 140 removed; done.
Processing triggers for ca-certificates (20230311) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Processing triggers for ca-certificates-java (20230710~deb12u1) ...
done.
As you can see, I removed (actually all certs).
But looking at the actual JKS:
# keytool -list -v -keystore /etc/ssl/certs/java/cacerts 2>/dev/null | grep -i ^Owner:
Owner: OU=AC RAIZ FNMT-RCM, O=FNMT-RCM, C=ES
...
Owner: CN=XRamp Global Certification Authority, O=XRamp Security Services Inc, OU=www.xrampsecurity.com, C=US
One sees they're still all in.
When I remove it:
# rm /etc/ssl/certs/java/cacerts
# dpkg-reconfigure ca-certificates-java
done.
# ls /etc/ssl/certs/java/cacerts
ls: cannot access '/etc/ssl/certs/java/cacerts': No such file or directory
# dpkg-reconfigure ca-certificates
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Processing triggers for ca-certificates (20230311) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Processing triggers for ca-certificates-java (20230710~deb12u1) ...
done.
# ls /etc/ssl/certs/java/cacerts
ls: cannot access '/etc/ssl/certs/java/cacerts': No such file or directory
It's not recreated.
Only if I configure new certs, it actually decides to recreate the JKS, too:
# dpkg-reconfigure ca-certificates
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL
2 added, 0 removed; done.
Processing triggers for ca-certificates (20230311) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Processing triggers for ca-certificates-java (20230710~deb12u1) ...
Adding debian:USERTrust_ECC_Certification_Authority.pem
Adding debian:USERTrust_RSA_Certification_Authority.pem
done.
# keytool -list -v -keystore /etc/ssl/certs/java/cacerts 2>/dev/null | grep -i ^Owner:
Owner: CN=USERTrust ECC Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
Owner: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
this time with the correct content.
If I now add yet another cert:
# dpkg-reconfigure ca-certificates
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL
1 added, 0 removed; done.
Processing triggers for ca-certificates (20230311) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Processing triggers for ca-certificates-java (20230710~deb12u1) ...
done.
# keytool -list -v -keystore /etc/ssl/certs/java/cacerts 2>/dev/null | grep -i ^Owner:
Owner: CN=USERTrust ECC Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
Owner: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
That is again not added to the JKS.
Cheers,
Chris.