-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Igor,
Post by Igor CicimovOn Fri, Oct 19, 2018 at 2:14 AM Christopher Schultz <
does any trust store, really.
Post by Igor CicimovCorrect, 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.
Post by Igor CicimovWell 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.
Post by Igor CicimovWhen 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.
Post by Igor CicimovNot 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.
Post by Igor CicimovThe proper way to validate a certificate chain is to perform the
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
sun.security.validator.ValidatorException: PKIX path building
unable to find valid certification path to requested target
Post by Igor CicimovTo conclude, the way I would expect the trust store to be used
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.
Post by Igor CicimovPost by Igor Cicimov2. 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?
Post by Igor CicimovPost by Igor Cicimov3. 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.
Post by Igor CicimovPost by Igor CicimovExample, 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-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org