On 6/14/22 13:06, Christopher Schultz wrote:
Thanks so much for your perseverance.
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.
My server gets the locations from a properties file and uses
Connector connector = new Connector();
connector.setPort(tcport);
connector.setSecure(true);
addBaseConnectorConfig(connector);
connectorSetTest(connector, "SSLEnabled", "true");
connectorSetTest(connector, "sslProtocol", "TLS");
connectorSetTest(connector, "keyAlias",
System.getProperty("SGSSRVR_keystoreAlias"));
connectorSetTest(connector, "keystorePass",
System.getProperty("SGSSRVR_keystorePwd"));
connectorSetTest(connector, "keystoreFile",
keyFile.getAbsolutePath());
connectorSetTest(connector, "keystoreType",
System.getProperty("SGSSRVR_storeType"));
What is connectorSetTest()?
Sorry that's just a helper routine which tests the result of
Connector.setProperty()
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
My embedded tomcat is mainly there to mediate between db and analysis
clients. I just need the traffic between the two to be encrypted.
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).
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.
Thanks every so much.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
