-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Igor,
On 10/18/18 19:09, Igor Cicimov wrote: > On Fri, Oct 19, 2018 at 2:14 AM Christopher Schultz < > ch...@christopherschultz.net> wrote: Java has no notion of CAs, nor > does any trust store, really. > > >> Correct, but by loading all CAs in the trust store it kinda >> does, indirectly. > >> A > certificate is trusted if it is present in the trust store, full > stop. It not need be a "CA". The oly thing being a CA gets you is > ... in everyone's default trust stores. > > > The system property javax.net.ssl.trustStore only sets the default > trust store for the JVM and any components which choose to use it. > For example, if you use HttpURLConnection without any explicit > configuration, it will use that. Same with Apache httpclient. > > But both of those can be configured to use a different trust > store, which case they will *not* fall-back to the built-in trust > store (the one in JAVA_HOME/lib/security/cacerts. > >> Well I see couple of issues with this approach of the trsutstore >> being the only source of truth. First is the obvious one, when >> using a custom trust store I have to load *all* CA certificates >> that already exist somewhere else on the server (and in multiple >> places) in the trust store too otherwise no certificate will >> ever get validated. Why would you want to use a custom trust store that also includes the whole list of trusted certs from the vendor? Either you want to delegate everything to the vendor (e.g. Oracle) or you know who you are connecting to, and you only need one cert (or a small selection of them) in your trust store. I think the problem is that people rely on "the trust store for the JVM" as the trust store for everything, which is a Bad Idea. Use separate trust stores for different types of connections. > When overriding the default trust store for the JVM, the trust > store you specify should be the ONLY trust store consulted. It > should not fall back. I can confirm this is the case on Java 8 - > 11, at least the ones I happen to be using. Any other behavior > would be a security problem. > >> Not sure I can agree with this reasoning too. All apps on the >> server use the default system CA store so should we consider them >> insecure? I see no harm of Java looking in the default >> location(s) on the server when a cert can not be validated by >> looking in the trust store. Otherwise as noted above in case of >> custom trust store we need to load all those certificates anyway >> ending up with same certificates stored in multiple places, >> making the size of the trust store unnecessary big. You are talking about a web application connecting to an outside service like a REST service via HTTPS, right? How many of these services could you possibly be connecting to? Why don't you already know their CAs? The default trust store that ships with the JVM is really only good if you want to connect to an arbitrary service and inherit all the certs that e.g. Oracle trusts. That only makes sense if you don't know in advance who you'll be connecting to. > The proper way to validate a certificate chain is to perform the > following algorithm: > > 0. Start with the server's certificate (the leaf) 1. Is the > certificate in the trust store? Yes: chain is valid; stop 2. Is the > certificate signed by a cert in the trust store? Yes: chain is > valid; stop 3. Is the certificate signed by the next cert in the > chain? No: chain is invalid; stop 4. Move to the next cert in the > chain 5. Go to step 1 > > So if you use an empty trust store and try to connect to > https://www.google.com, you should find that you get an exception > thrown. Something like this: > > Exception in thread "main" javax.net.ssl.SSLHandshakeException: > sun.security.validator.ValidatorException: PKIX path building > failed: sun.security.provider.certpath.SunCertPathBuilderException: > unable to find valid certification path to requested target > > >> To conclude, the way I would expect the trust store to be used >> and the whole validation done: > >> 1. I use custom trust store because I need to load self signed >> certificates that I need to validate when connecting to lets say >> partner APIs that use self signed certificates and I know I can >> trust So... you just need to trust a self-signed certificate. That shouldn't be a problem. >> 2. I would expect nothing else needed in this store as every >> other valid certificate under the sun is already located in >> default locations on the server Java is running on And why do you need to be able to validate all those other certificates if you are only connecting to one service? >> 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. To behave otherwise would be a security problem: if you install your own trust store, falling-back into the JVM's default trust store means that trust is being misplaced. There would be no way to dis-trust any certificate without physically deleting the certificate from the system's default trust store. That may not be possible if the system isn't writable by e.g. the application operator. >> 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. Those errors aren't inexplicable: they occur because the certificate is not trusted. Java doesn't use the system trust store, ever. You can't even configure it to use the system's trust store. You'd have to build a custom TrustManager and wire it into the system's trust store yourself. If you want to trust both your own custom trust store plus the platform default, you'll have to write code to make that happen. It's possible, but it's not "free". [1] - -chris [1] https://stackoverflow.com/questions/24555890/using-a-custom-truststore-i n-java-as-well-as-the-default-one -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvOPUoACgkQHPApP6U8 pFh1EhAAtuI+UD5R6CcVL0NOoFZYqhoDppkMLaFAFTzu5PtCyFZXEX4sDZhzd1kp RqZCLXhliAbACnYk2AlkNKEgIaSZNoi5NxozmFQGka1o/dcQQqvJvTxYp1txj5dM LQSXDybEJeeHT10fAThuwnRaDcVaJdtv1ILri2/FsswP1ZBnjki5kXKiRBzBZyw5 NSH/wJTm2cx7no6B2JdvckKXjExFdjO/TT8i6KOmcKjG80fjRUVbSpH3lXhV01nN +tMQcJ/D3RVHLBR2tUKi/WhwVXgOxfx3Vkb43YAuOcrQYD+Fi0V2eQh7JdJhlvYD EAGOs8bzOSFEDx3oQBsXSP0BwGlBCL//erxDI9iKtyzOBsxEJk+dU1fKalayj7l0 VicN2p4smHnBbeYJDFuAGvSMywuLfxXNrJJ8gY/6bP30554ydDA5lDNdXmUmaR06 gnGWX2ZaGqn6Icijdm8VpKUnwUA2gHzXPknFnOI806V6SWJzVEmnwg1913jBbq0T FarSuVy+JuN/dkhIgBC90U9dstgnAhhjJBv920ia8wbjaCsewgpy74Yyf8UitU/Z GJYnmKYAqk1KLjXXTXmM2KsncsbMCWwSba/OqbLtOQSQ2GtQ3qBbxQ/C+OgZacMj Uysw7G6h8q0AeVRwN2wwDRwhfbmu2AsXN8dNSfSDU6bG6+kghE4= =z9/7 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
