Hi Guido, On Tue, Oct 23, 2018 at 7:49 PM Jäkel, Guido <g.jae...@dnb.de> wrote:
> Dear Igor, > > >> 3. In case JAVA_HOME/lib/security/cacerts is my trust store (the > default) I would > >> expect Java to use the system store(s) too in case a certificate can > not be validated > >> simply because a CA is missing in the Java store. Example, DigiCert > Global > >> Root G2 CA is missing in the Java versions older than 8u91 causing > inexplicable > >> PKIX exceptions but can be found in the system store, both under > /etc/ssl/certs and > >> /usr/share/ca-certificates which are (much) more frequently updated > with new certs than Java versions. > >> This actually applies to the case of custom trust store even more so > >> > >> Thoughts? > > Because Java is platform-independent, it have an own store and don't use > any of the underlying OS. But one told me that on some Linux distributions, > there's a script tool to update the Java cert store from the > CA-Certificates-Package. Using such a tool you get the update more > frequently. > > But actually you probably don't need. You wrote about using Java8u91, > which is simply complete out of date because the latest is Java8u192. I you > complain about security things like an outdated certificate store, you > simply should install a Java version as recent as the CA-Certificates > package of the hosting OS. Any you will catch other JAVA bugs and security > issues by the way, too. > Just to make it clear, when I mentioned Java8u91 as an example I meant for the time when lets say Java8u81 was latest at that moment. In that case when using the built in JVM store you would encounter failed connections to servers with G2 signed certificates. Then as you said you would need to import it into the JVM store by yourself or wait for the next Java release that would include it by default i.e. Java8u91
