Rob, On 6/14/22 15:38, Rob Sargent wrote:
On 6/14/22 13:06, Christopher Schultz wrote:Thanks so much for your perseverance.
No problem. Anything to avoid doing $work.
On 6/14/22 14:43, Rob Sargent wrote:Let's get one thing working at a time. I reviewed this thread, and I honestly can't figure out exactly what you are trying to do. Can you please clarify?1. "I want to get Tomcat working as a server with a TLS Certificate." This can be self-signed, or it can be signed by a real Certificate Authority. The process is almost the same, except you have to send something to the CA.2. "I want to get Tomcat working as a server with a TLS Certificate, AND I want to demand that all clients connecting also present a client-certificate to authenticate."Which of the above is it?I believe I can live with #1. I'm using a self-signed cert for sure.
Okay, that's good because it reduces the complexity of this whole operation by ~50%.
Because the server-side cert is self-signed, it likely means that each client will have to import the server-cert into the /client/ trust-store. Either that, of you can "ignore warnings" but IMO that's a significant reduction in security. We can talk about that, later.
Your server should not have to configure a trust store, full stop.
My embedded tomcat is mainly there to mediate between db and analysis clients. I just need the traffic between the two to be encrypted.and here we can see I don't actually use truststore.... so that puts the lie to have my claim.You might not need it. You only need a trust store if you want option #2 from above.The clients get them from command line -D properties defvs += F" -Djavax.net.ssl.keyStore=/ppr/certs/sgs10.0.2.118.p12 -Djavax.net.ssl.keyStoreType=PKCS12 -Djavax.net.ssl.keyStorePassword=changeit" defvs += F" -Djavax.net.ssl.trustStore=/ppr/certs/fullca.p12 -Djavax.net.ssl.trustStoreType=PKCS12 -Djavax.net.ssl.trustStorePassword=changeit" But as I said "It's working" so I'm likely to let sleeping dogs lie.Okay, so if your clients (connecting you your Tomcat, right?) are using keystores, then... it sounds like you want option #2
You mention 3 parties: HTTP clients, HTTP server (Tomcat), and db. Which links must be encrypted? (I would answer "all links should be encrypted", but encrypting between app <- -> db is a whole different process.)
Shortest route to that is all I'm after.10.0.2.118 is the server and that's where I make my (one and only) self-signed cert. That gets added to fullca.p12 (selfie + cacerts).
What is "cacerts" here? If it's self-signed, then you only need two things in the keystore: the key and the cert. Java's keytool will report this as "one entry" in the keystore with a single alias. It will say it's a "private key entry" and (somewhat surprisingly) give you a certificate for that entry if you do "keytool -list -v". I say "surprisingly" because private keys are NOT certificates. But keytool treats them as one thing because #reasons.
It all boils down to this: 1. Every pair of entities in a TLS connection are called "peers". 2. Any peer can choose to require the other one to authenticate.3. In practice, servers *always* authenticate to the clients by presenting a certificate. It's up to the client to decide if the cert is acceptable. (This is where self-signed versus CA-signed comes into play. If you control the client, don't bother paying a CA a bunch of money for what copy/paste can solve for you.) The client maintains a trust store for this purpose.The server manages this behind the scenes using a key store. A trust store is not required, because this part doesn't require clients to authenticate to servers.(Technically, Java calls these things KeyStores no matter what. A "trust store" is just a KeyStore used for trust. Don't let that confuse you. I will always refer to a file-containing-a-key-and-cert as a "key store" and a file-containing-a-bunch-of-certificates-to-be-trusted as a "trust store.)4. In public, clients almost never authenticate themselves. So you only need to deal with the "server part". If you want the server to authenticate the client, then you just flip everything backwards and layer it on top of what you already had:4a. Server needs a trust tore, filled with the certs from the clients 4b. Clients each need a key store, containing the client's key+cert That's pretty much it.That helps a lot. Basically I had the responsibilities reversed. I have a couple of other configuration annoyances to fix and will clean "stores" as well.
You should only need the embedded equivalent of this:
<Connector .. [other stuff you need like port, etc.]
SSLEnabled="true">
<SSLHostConfig>
<Certificate certificateKeystoreFile="keystore.p12" />
</SSLHostConfig>
</Connector>
I would recommend setting:
- honorCipherOrder="true" on the SSLHostConfig
- protocols="TLSv1.2,TLSv1.3" (or whatever the highest you can get away
with is)
- I used a .p12 file in <Certificate>. JKS files are a PITA; don't use them. You may need to set:- certificateKeystorePassword on <Certificate> (if keystore.p12 has a password) - certificateKeyPassword on <Certificate> (if keystore.p12 has a separate password on the key entry) - certificateKeyAlias on <Certificate> (if you have more than one PrivateKeyEntry in your keystore. But DON'T DO THIS because you'll confuse the hell out of yourself) - type on on <Certificate> if you have more than one <Certificate>. This is really only necessary is you want to provide both EC and RSA certs to clients. Save yourself some trouble and just pick one or the other and stick with it. EC is "faster" (measurably) and RSA is "safer" at higher key lengths (> 3072 bits) if you have a time-machine to go into the future and get one of those totally-gonna-happen quantum computers to cut keys
Note that if you ever get your server's cert signed by a CA, all you have to do is import that signed cert into your keystore and restart the connector. Clients will see the signed cert at that point. If you need a "chain" certificate, import *that* into the keystore as well, and youe clients will see the full chain and no clients will complain that the server isn't trusted.
If you've never attended Mark's presentation on SSL for Tomcat, it's very instructive and takes everything step-by-step, explaining the whole PKI trust model.
Look for "Introduction to TLS and Tomcat" and "Apache Tomcat and SSL" on the presentations page (https://tomcat.apache.org/presentations.html).
-chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
