Re: cert/key config woes
Chris, Back at my desk and going through you notes again. 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. It the moment it's name in the read-in properties file but not actually acted on in the code. TODO! 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. 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.) I am under an edict to encrypt ALL traffic within my AWS set-up. I have the tomcat-postgres using SSL (verify-full). This is NOT a high traffic situation. I'll re-re-read the rest of your message until I get it right. Thanks ever so much. rjs - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: cert/key config woes
> On Jun 15, 2022, at 7:45 AM, Christopher Schultz > wrote: > > 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. Away from my desk this morning but will retool accordingly asap Thank you rjs - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: cert/key config woes
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. 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. 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: 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 . JKS files are a PITA; don't use them. You may need to set: -
Re: cert/key config woes
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
Re: cert/key config woes
Rob,
On 6/14/22 14:43, Rob Sargent wrote:
I have my environment working again but not with supplying both keystore
and truststore to both the server and the client. Clearly scrogged
somewhere
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?
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()?
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
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.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: cert/key config woes
On 6/14/22 12:43, Rob Sargent wrote: On 6/2/22 16:06, Rob Sargent wrote: I'm starting both the server and the client with both key and trust. Does that bite? I would avoid giving access to the key to anything that doesn't absolutely need it. Usually, only the server needs access to the key. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Back from vacation but none the wiser for having visited Harvard! I have my environment working again but not with supplying both keystore and truststore to both the server and the client. Clearly scrogged somewhere EDIT but not WITHOUT supplying both... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: cert/key config woes
On 6/2/22 16:06, Rob Sargent wrote:
I'm starting both the server and the client with both key and trust.
Does that bite?
I would avoid giving access to the key to anything that doesn't
absolutely need it. Usually, only the server needs access to the key.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Back from vacation but none the wiser for having visited Harvard!
I have my environment working again but not with supplying both keystore
and truststore to both the server and the client. Clearly scrogged
somewhere
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"));
and here we can see I don't actually use truststore so that puts the
lie to have my claim.
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.
rjs
Re: cert/key config woes
I'm starting both the server and the client with both key and trust. Does that bite? I would avoid giving access to the key to anything that doesn't absolutely need it. Usually, only the server needs access to the key. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Roger that. I'll rejigger that when I get back mid june. Thanks a ton, rjs - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: cert/key config woes
Rob, On 6/2/22 14:19, Rob Sargent wrote: Caused by: java.lang.IllegalArgumentException: Alias name [sgsAgent] does not identify a key entry at > [...] but I believe the alias is in place, both places ## check, different files [ec2-user@ip-10-0-2-118 certs]ls -l fullca.p12 sgstrust.p12 -rw-rw-r-- 1 ec2-user ec2-user 281500 Jun 2 17:12 fullca.p12 -rw-rw-r-- 1 ec2-user ec2-user 2726 Jun 2 17:13 sgstrust.p12 ## checks for alias [ec2-user@ip-10-0-2-118 certs]$ keytool -storetype pkcs12 -list -keystore sgstrust.p12 -alias sgsAgent -storepass changeit sgsAgent, Jun 2, 2022, PrivateKeyEntry, Certificate fingerprint (SHA-256): 65:F1:9C:07:37:C4:13:A8:82:D5:09:E7:51:F9:C0:E2:94:E4:41:64:F1:41:86:E6:60:5F:50:87:A8:13:74:17 [ec2-user@ip-10-0-2-118 certs]$ keytool -storetype pkcs12 -list -keystore fullca.p12 -alias sgsAgent -storepass changeit sgsAgent, Jun 2, 2022, trustedCertEntry, Certificate fingerprint (SHA-256): 65:F1:9C:07:37:C4:13:A8:82:D5:09:E7:51:F9:C0:E2:94:E4:41:64:F1:41:86:E6:60:5F:50:87:A8:13:74:17 What does your configuration look like (specifically, what keystore is it pointing to)? Remember that ccan specify both keystore (for identifying itself) and truststore (for identifying clients, which you don't need AIUI). To your latest I add my cert to truststore. Which one? Are you using client certs for mutual-TLS or just plain-old "I only need to trust the server" checking? I add sgstrust to fullca. I think the latter mode is fine If it's vanilla, then you need: 1. Key + cert in the key store used by the Tomcat 2. cert in the trust store used by the client (optional if it's signed by a trusted CA) Remember if your key store from #1 has more than one cert+key in it, Tomcat will choose the first one (which is basically a crap-shoot, given the API) unless you specify the alias of the one to use. I think it's best to have only a single key+cert in each keystore (unless it's multiple flavors of the same thing, like RSA and ECDSA for the same server). That way you don't get confused by "too much stuff". I'm starting both the server and the client with both key and trust. Does that bite? I would avoid giving access to the key to anything that doesn't absolutely need it. Usually, only the server needs access to the key. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: cert/key config woes
java -Djavax.net.ssl.keyStore=/ppr/certs/sgstrust.p12
-Djavax.net.ssl.keyStoreType=PKCS12
-Djavax.net.ssl.keyStorePassword=p1
-Djavax.net.ssl.trustStore=/ppr/certs/fullca.p12
-Djavax.net.ssl.trustStoreType=PKCS12
-Djavax.net.ssl.trustStorePassword=p2
--oper=1 --seg=id --json-dir=/ppr/report --acc=10.0.2.118:15002
--dbn={dbn} --eff={dbu} -env=AWS
Does that launch your Tomcat JVM or your client? (Or both?)
Sorry, I missed this question. That's the client (on a new spun-up EC2)
The server also gets both key and trust.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: cert/key config woes
Hang on. I'm panicking. I have a plane to catch in 3 hours and need this working by then. ws s3 cp fullca.p12 s3://691459864434-sgs-source/certs/sgstrust.p12 splatting one file on top of the other Midway through this email when you last came in: "Not running" is spot-on becase... The current problem is actaully Jun 02, 2022 6:01:27 PM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["https-jsse-nio-10.0.2.118-15002"] Jun 02, 2022 6:01:27 PM org.apache.catalina.util.LifecycleBase handleSubClassException SEVERE: Failed to initialize component [Connector[HTTP/1.1-15002]] org.apache.catalina.LifecycleException: Protocol handler initialization failed at org.apache.catalina.connector.Connector.initInternal(Connector.java:1049) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:556) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1042) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:173) at org.apache.catalina.startup.Tomcat.start(Tomcat.java:486) at edu.utah.camplab.server.SGSSelector.kickOff(SGSSelector.java:175) at edu.utah.camplab.server.SGSSelector.run(SGSSelector.java:187) at java.base/java.lang.Thread.run(Thread.java:833) Caused by: java.lang.IllegalArgumentException: Alias name [sgsAgent] does not identify a key entry at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:107) at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:71) at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:234) at org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1227) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1240) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:603) at org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:80) at org.apache.catalina.connector.Connector.initInternal(Connector.java:1046) ... 10 more Caused by: java.io.IOException: Alias name [sgsAgent] does not identify a key entry at org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:337) at org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:247) at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:105) ... 17 more but I believe the alias is in place, both places ## check, different files [ec2-user@ip-10-0-2-118 certs]ls -l fullca.p12 sgstrust.p12 -rw-rw-r-- 1 ec2-user ec2-user 281500 Jun 2 17:12 fullca.p12 -rw-rw-r-- 1 ec2-user ec2-user 2726 Jun 2 17:13 sgstrust.p12 ## checks for alias [ec2-user@ip-10-0-2-118 certs]$ keytool -storetype pkcs12 -list -keystore sgstrust.p12 -alias sgsAgent -storepass changeit sgsAgent, Jun 2, 2022, PrivateKeyEntry, Certificate fingerprint (SHA-256): 65:F1:9C:07:37:C4:13:A8:82:D5:09:E7:51:F9:C0:E2:94:E4:41:64:F1:41:86:E6:60:5F:50:87:A8:13:74:17 [ec2-user@ip-10-0-2-118 certs]$ keytool -storetype pkcs12 -list -keystore fullca.p12 -alias sgsAgent -storepass changeit sgsAgent, Jun 2, 2022, trustedCertEntry, Certificate fingerprint (SHA-256): 65:F1:9C:07:37:C4:13:A8:82:D5:09:E7:51:F9:C0:E2:94:E4:41:64:F1:41:86:E6:60:5F:50:87:A8:13:74:17 ## upload to s3 [ec2-user@ip-10-0-2-118 certs]$ aws s3 cp fullca.p12 s3://691459864434-sgs-source/certs/fullca.p12 upload: ./fullca.p12 to s3://691459864434-sgs-source/certs/fullca.p12 [ec2-user@ip-10-0-2-118 certs]$ aws s3 cp sgstrust.p12 s3://691459864434-sgs-source/certs/sgstrust.p12 aws s3 cp sgstrust.p12 s3://691459864434-sgs-source/certs/sgstrust.p12 upload: ./sgstrust.p12 to s3://691459864434-sgs-source/certs/sgstrust.p12 ## program downloads p12 filesfrom s3 To your latest I add my cert to truststore. Which one? Are you using client certs for mutual-TLS or just plain-old "I only need to trust the server" checking? I add sgstrust to fullca. I think the latter mode is fine If it's vanilla, then you need: 1. Key + cert in the key store used by the Tomcat 2. cert in the trust store used by the client (optional if it's signed by a trusted CA) Remember if your key store from #1 has more than one cert+key in it, Tomcat will choose the first one (which is basically a crap-shoot,
Re: cert/key config woes
Rob,
On 6/2/22 13:43, Rob Sargent wrote:
I had this overall configuration working until I 'terminated' the AWS
server instance and am trying to rebuild.
Could a lack of network connectivity between client and server
present this same symptom?
Hmm. Your SAN looks okay to me. Are you 100% sure you have that
certificate configured in Tomcat? ARe you using some other component
in front of Tomcat? You should be able to connect using:
$ openssl s_client -showcerts -connect 10.0.2.118:443
This will dump the certificate actually presented by the server. You
can copy/paste that into:
$ openssl x509 -text
and get the details to make sure the SAN appears there.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Thanks Chris, given your vote of confidence I realized I had not updated
the keystore file with my recently regenerated cert.
Also forgot to mention this is tomcat 9.0.63 embedded in my app, running
java17 (correto) at AWS
But I think I'm going backwards.
my actual java command is pretty much this:
java -Djavax.net.ssl.keyStore=/ppr/certs/sgstrust.p12
-Djavax.net.ssl.keyStoreType=PKCS12 -Djavax.net.ssl.keyStorePassword=p1
-Djavax.net.ssl.trustStore=/ppr/certs/fullca.p12
-Djavax.net.ssl.trustStoreType=PKCS12
-Djavax.net.ssl.trustStorePassword=p2
--oper=1 --seg=id --json-dir=/ppr/report --acc=10.0.2.118:15002
--dbn={dbn} --eff={dbu} -env=AWS
Does that launch your Tomcat JVM or your client? (Or both?)
I add my cert to truststore.
Which one? Are you using client certs for mutual-TLS or just plain-old
"I only need to trust the server" checking?
If it's vanilla, then you need:
1. Key + cert in the key store used by the Tomcat
2. cert in the trust store used by the client (optional if it's signed
by a trusted CA)
Remember if your key store from #1 has more than one cert+key in it,
Tomcat will choose the first one (which is basically a crap-shoot, given
the API) unless you specify the alias of the one to use. I think it's
best to have only a single key+cert in each keystore (unless it's
multiple flavors of the same thing, like RSA and ECDSA for the same
server). That way you don't get confused by "too much stuff".
Do I need both trust and key stores on the
commandline. sgstrust.p12 is made by converting x509 key/cert.
fullca.p12 has the worlds CA certs plus mine.
But now I'm hitting
java.net.ConnectException
Probably not running?
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: cert/key config woes
On 6/2/22 11:43, Rob Sargent wrote: I had this overall configuration working until I 'terminated' the AWS server instance and am trying to rebuild. Could a lack of network connectivity between client and server present this same symptom? Hmm. Your SAN looks okay to me. Are you 100% sure you have that certificate configured in Tomcat? ARe you using some other component in front of Tomcat? You should be able to connect using: $ openssl s_client -showcerts -connect 10.0.2.118:443 This will dump the certificate actually presented by the server. You can copy/paste that into: $ openssl x509 -text and get the details to make sure the SAN appears there. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Thanks Chris, given your vote of confidence I realized I had not updated the keystore file with my recently regenerated cert. Also forgot to mention this is tomcat 9.0.63 embedded in my app, running java17 (correto) at AWS But I think I'm going backwards. Hang on. I'm panicking. I have a plane to catch in 3 hours and need this working by then. ws s3 cp fullca.p12 s3://691459864434-sgs-source/certs/sgstrust.p12 splatting one file on top of the other
Re: cert/key config woes
I had this overall configuration working until I 'terminated' the AWS
server instance and am trying to rebuild.
Could a lack of network connectivity between client and server
present this same symptom?
Hmm. Your SAN looks okay to me. Are you 100% sure you have that
certificate configured in Tomcat? ARe you using some other component
in front of Tomcat? You should be able to connect using:
$ openssl s_client -showcerts -connect 10.0.2.118:443
This will dump the certificate actually presented by the server. You
can copy/paste that into:
$ openssl x509 -text
and get the details to make sure the SAN appears there.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Thanks Chris, given your vote of confidence I realized I had not updated
the keystore file with my recently regenerated cert.
Also forgot to mention this is tomcat 9.0.63 embedded in my app, running
java17 (correto) at AWS
But I think I'm going backwards.
my actual java command is pretty much this:
java -Djavax.net.ssl.keyStore=/ppr/certs/sgstrust.p12
-Djavax.net.ssl.keyStoreType=PKCS12 -Djavax.net.ssl.keyStorePassword=p1
-Djavax.net.ssl.trustStore=/ppr/certs/fullca.p12
-Djavax.net.ssl.trustStoreType=PKCS12
-Djavax.net.ssl.trustStorePassword=p2
--oper=1 --seg=id --json-dir=/ppr/report --acc=10.0.2.118:15002
--dbn={dbn} --eff={dbu} -env=AWS
I add my cert to truststore. Do I need both trust and key stores on the
commandline. sgstrust.p12 is made by converting x509 key/cert.
fullca.p12 has the worlds CA certs plus mine.
But now I'm hitting
java.net.ConnectException
at
java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:573)
at
java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:123)
at
edu.utah.camplab.sgs.AbstractSGSRun.canConnect(AbstractSGSRun.java:386)
at
edu.utah.camplab.sgs.AbstractSGSRun.init(AbstractSGSRun.java:296)
at
edu.utah.camplab.sgs.AbstractSGSOptions.init(AbstractSGSOptions.java:37)
at edu.utah.camplab.sgs.SGSChase.init(SGSChase.java:76)
at edu.utah.camplab.sgs.SGSChase.init(SGSChase.java:85)
at edu.utah.camplab.app.SGSPValue.(SGSPValue.java:68)
at edu.utah.camplab.app.SGSPValue.main(SGSPValue.java:27)
Caused by: java.net.ConnectException
at
java.net.http/jdk.internal.net.http.common.Utils.toConnectException(Utils.java:1047)
at
java.net.http/jdk.internal.net.http.PlainHttpConnection.connectAsync(PlainHttpConnection.java:198)
at
java.net.http/jdk.internal.net.http.PlainHttpConnection.checkRetryConnect(PlainHttpConnection.java:230)
at
java.net.http/jdk.internal.net.http.PlainHttpConnection.lambda$connectAsync$1(PlainHttpConnection.java:206)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:934)
at
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:911)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510)
at
java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1773)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.nio.channels.ClosedChannelException
at
java.base/sun.nio.ch.SocketChannelImpl.ensureOpen(SocketChannelImpl.java:195)
at
java.base/sun.nio.ch.SocketChannelImpl.beginConnect(SocketChannelImpl.java:760)
at
java.base/sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:848)
at
java.net.http/jdk.internal.net.http.PlainHttpConnection.lambda$connectAsync$0(PlainHttpConnection.java:183)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:569)
at
java.net.http/jdk.internal.net.http.PlainHttpConnection.connectAsync(PlainHttpConnection.java:185)
... 9 more
in code unchanged since it last worked.
Re: cert/key config woes
Rob,
On 6/2/22 01:13, Rob Sargent wrote:
This part always confuses me
I supply the trust and key store files on the command line and I see the
SAN for the tomcat server IP (in ObjectId #3). I try to connect to
tomcat by host-IP and port. Here's the text of the keystore sent in.
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: sgsagent
Creation date: Jun 2, 2022
Entry type: trustedCertEntry
Owner: EMAILADDRESS=rob.sarg...@utah.edu,
CN=ip-10-0-2-118.us-west-2.compute.internal, OU=PPR, O=University of
Utah, L=Salt Lake City, ST=UT, C=US
Issuer: EMAILADDRESS=rob.sarg...@utah.edu,
CN=ip-10-0-2-118.us-west-2.compute.internal, OU=PPR, O=University of
Utah, L=Salt Lake City, ST=UT, C=US
Serial number: 2f543ea5b1ce847034a34dfb4d26ecbdac1959d5
Valid from: Thu Jun 02 03:12:01 UTC 2022 until: Sat Jul 02 03:12:01
UTC 2022
Certificate fingerprints:
SHA1:
61:92:93:E7:A1:05:85:ED:66:6F:BC:6C:76:7E:CA:E8:7F:A7:0D:93
SHA256:
23:85:E4:85:08:93:B1:4C:D7:40:47:E7:EF:3F:8F:5F:FC:FA:CA:57:0F:B1:4C:A8:3F:25:AE:D7:98:0C:4B:28
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
: F4 FC 13 D9 FC 1C C1 A0 DB 0A 81 28 C0 EF DC FF
...(
0010: 28 64 81 BE (d..
]
]
#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen: no limit
]
#3: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
IPAddress: 10.0.2.118
]
#4: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
: F4 FC 13 D9 FC 1C C1 A0 DB 0A 81 28 C0 EF DC FF
...(
0010: 28 64 81 BE (d..
]
]
but I get
javax.net.ssl.SSLHandshakeException: No subject alternative names
matching IP address 10.0.2.118 found
at
java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:578)
at
java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:123)
at
edu.utah.camplab.sgs.AbstractSGSRun.canConnect(AbstractSGSRun.java:386)
at
edu.utah.camplab.sgs.AbstractSGSRun.init(AbstractSGSRun.java:296)
at
edu.utah.camplab.sgs.AbstractSGSOptions.init(AbstractSGSOptions.java:37)
at edu.utah.camplab.sgs.SGSChase.init(SGSChase.java:76)
at edu.utah.camplab.sgs.SGSChase.init(SGSChase.java:85)
at edu.utah.camplab.app.SGSPValue.(SGSPValue.java:68)
at edu.utah.camplab.app.SGSPValue.main(SGSPValue.java:27)
Caused by: javax.net.ssl.SSLHandshakeException: No subject
alternative names matching IP address 10.0.2.118 found
Then comes my summary log:
03:52:04.752 [main] ERROR edu.utah.camplab.sgs.AbstractSGSRun -
cannot get to saver, trying 10.0.2.118:15002
Could not establish connection to 10.0.2.118:15002
from
if (! canConnect() ) {
logger.error("cannot get to saver, trying {}:{}",
getAccumulationHost(), getAccumulationPort());
throw new RuntimeException(String.format("Could not establish
connection to %s:%d", getAccumulationHost(), getAccumulationPort()));
}
protected boolean canConnect() {
boolean retval = false;
String weburl = String.format("https://%s:%d;,
getAccumulationHost(), getAccumulationPort());
try {
HttpRequest request = HttpRequest.newBuilder()
.header("dbrole", getProjectName())
.header("dbname", getDbName())
.header("dbhost", System.getProperty("SGSSRVR_databaseHost",
"localhost"))
.uri(URI.create(weburl+"/sgs/webmonitor"))
.build();
HttpResponse response = getHttpClient().send(request,
HttpResponse.BodyHandlers.ofString());
retval = response.statusCode() == 200;
}
catch (IOException | InterruptedException ie) {
retval = false;
ie.printStackTrace();
}
return retval;
}
I had this overall configuration working until I 'terminated' the AWS
server instance and am trying to rebuild.
Could a lack of network connectivity between client and server present
this same symptom?
Hmm. Your SAN looks okay to me. Are you 100% sure you have that
certificate configured in Tomcat? ARe you using some other component in
front of Tomcat? You should be able to connect using:
$ openssl s_client -showcerts -connect 10.0.2.118:443
This will dump the certificate actually presented by the server. You can
copy/paste that into:
$ openssl x509 -text
and get the details to make sure the
cert/key config woes
This part always confuses me
I supply the trust and key store files on the command line and I see the
SAN for the tomcat server IP (in ObjectId #3). I try to connect to
tomcat by host-IP and port. Here's the text of the keystore sent in.
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: sgsagent
Creation date: Jun 2, 2022
Entry type: trustedCertEntry
Owner: EMAILADDRESS=rob.sarg...@utah.edu,
CN=ip-10-0-2-118.us-west-2.compute.internal, OU=PPR, O=University of
Utah, L=Salt Lake City, ST=UT, C=US
Issuer: EMAILADDRESS=rob.sarg...@utah.edu,
CN=ip-10-0-2-118.us-west-2.compute.internal, OU=PPR, O=University of
Utah, L=Salt Lake City, ST=UT, C=US
Serial number: 2f543ea5b1ce847034a34dfb4d26ecbdac1959d5
Valid from: Thu Jun 02 03:12:01 UTC 2022 until: Sat Jul 02 03:12:01
UTC 2022
Certificate fingerprints:
SHA1:
61:92:93:E7:A1:05:85:ED:66:6F:BC:6C:76:7E:CA:E8:7F:A7:0D:93
SHA256:
23:85:E4:85:08:93:B1:4C:D7:40:47:E7:EF:3F:8F:5F:FC:FA:CA:57:0F:B1:4C:A8:3F:25:AE:D7:98:0C:4B:28
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
: F4 FC 13 D9 FC 1C C1 A0 DB 0A 81 28 C0 EF DC FF ...(
0010: 28 64 81 BE (d..
]
]
#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen: no limit
]
#3: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
IPAddress: 10.0.2.118
]
#4: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
: F4 FC 13 D9 FC 1C C1 A0 DB 0A 81 28 C0 EF DC FF ...(
0010: 28 64 81 BE (d..
]
]
but I get
javax.net.ssl.SSLHandshakeException: No subject alternative names
matching IP address 10.0.2.118 found
at
java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:578)
at
java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:123)
at
edu.utah.camplab.sgs.AbstractSGSRun.canConnect(AbstractSGSRun.java:386)
at
edu.utah.camplab.sgs.AbstractSGSRun.init(AbstractSGSRun.java:296)
at
edu.utah.camplab.sgs.AbstractSGSOptions.init(AbstractSGSOptions.java:37)
at edu.utah.camplab.sgs.SGSChase.init(SGSChase.java:76)
at edu.utah.camplab.sgs.SGSChase.init(SGSChase.java:85)
at edu.utah.camplab.app.SGSPValue.(SGSPValue.java:68)
at edu.utah.camplab.app.SGSPValue.main(SGSPValue.java:27)
Caused by: javax.net.ssl.SSLHandshakeException: No subject
alternative names matching IP address 10.0.2.118 found
Then comes my summary log:
03:52:04.752 [main] ERROR edu.utah.camplab.sgs.AbstractSGSRun -
cannot get to saver, trying 10.0.2.118:15002
Could not establish connection to 10.0.2.118:15002
from
if (! canConnect() ) {
logger.error("cannot get to saver, trying {}:{}",
getAccumulationHost(), getAccumulationPort());
throw new RuntimeException(String.format("Could not establish
connection to %s:%d", getAccumulationHost(), getAccumulationPort()));
}
protected boolean canConnect() {
boolean retval = false;
String weburl = String.format("https://%s:%d;,
getAccumulationHost(), getAccumulationPort());
try {
HttpRequest request = HttpRequest.newBuilder()
.header("dbrole", getProjectName())
.header("dbname", getDbName())
.header("dbhost", System.getProperty("SGSSRVR_databaseHost",
"localhost"))
.uri(URI.create(weburl+"/sgs/webmonitor"))
.build();
HttpResponse response = getHttpClient().send(request,
HttpResponse.BodyHandlers.ofString());
retval = response.statusCode() == 200;
}
catch (IOException | InterruptedException ie) {
retval = false;
ie.printStackTrace();
}
return retval;
}
I had this overall configuration working until I 'terminated' the AWS
server instance and am trying to rebuild.
Could a lack of network connectivity between client and server present
this same symptom?
