tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Trying to understand How Tomcat uses Keystore for SSL
Date Tue, 14 Nov 2017 21:33:58 GMT
Hash: SHA256


On 11/14/17 1:57 AM, Don Flinn wrote:
> I've done some reading on SSL and understand the protocol is as
> follows; Client/Browser sends ClientHello and server Tomcat replies
> with ServerHello.  This establishes the protocol they will use. The
> server then sends the certificate and the public key - in the
> clear The browser encrypts a message containing the servers domain,
> all encrypted with the server's public key to the CA which the
> browser trusts.  The public key is in the certificate. The CA
> de-crypts the message with the server's private key.  So the 
> server's name/ domain must be not encrypted. If the server can
> decrypt the message it knows the server and it then sends a ack
> message back to the browser encrypted with the client's private
> key.

Most of that is correct (enough) except for the last part: the server
never has the client's private key. The handshake is done using
public-key/asymmetric encryption and part of that handshake includes
establishing the keys to be used for the bulk encryption -- the
encryption used after the handshake.

> The browser and Tomcat then establish a secret key to send messages
> back and forth.

That's the bulk encryption key. Note that it can be re-negotiated at
intervals during the conversation if necessary.

> If I have the above correct, I must have keystore set up
> incorrectly, since running my scenario I get an error in the Chrome
> debugger,which says
> This page is not secure "Valid certificate The connection to this
> site is using a valid, trusted server certificate issued by unknown
> name. Secure resources All resources on this page are served
> securely. "
> Note the 'the certificate is valid and it is issued by unknown
> name"  Why is the issuer unknown, since the issuer's name is in the
> certificate?

That message may be misleading. If the certificate is self-signed than
of course the certificate signer is "known" to the client (Chrome)
because it's just identified itself (as itself!). What it means to be
"unknown" is that it is /untrusted/. You haven't told Chrome that you
specifically trust the certificate that signed the server's
certificate. If you e.g. self-sign then the self-signature isn't
recognized as authoritative. If a real CA signs it -- e.g. Verisign,
DigiCert, Let's Encrypt, etc. -- then the browser /will/ recognize it.

> letsencrypt has an online web site from which one can download a
> ca_bundle, a private key and a certificate for your domain

Theoretically, you should generate your own private key and then use
LE's tools to obtain a signed certificate.

> Oracle has an article on keytool which says that keytool  can not
> create a pkcs12 keystore but can read it and to use openssl, which
> I did following their instructions.

OpenSSL will do DER/PEM files and also PKCS12 keystores, but they are
interchangeable and contain the same types of key material... just in
different kinds of packages.

> Concatenate the CA cert, the private key and the user cert then put
> these in keystore.

Be careful with terms. Concatenation usually means just slamming bytes
together. This only works with PEM-encoded files like OpenSSL likes to
use -- the ones that start with e.g. "---- BEGIN CERTIFICATE ----".
The other types of files have a very specific format and you can't
just slam them together.

> The result is shown below.  Tomcat isn't able to use this keystore
> to communicate with the browser for some reason. Why? What's
> missing or incorrect?
> C:\Users\don\Security\letsenc>%keytool% -list -keystore MMcert.p12
> -v -storetype pkcs12 Enter keystore password:
> Keystore type: PKCS12 Keystore provider: SunJSSE
> Your keystore contains 1 entry
> Alias name: tomcat Creation date: Nov 13, 2017 Entry type:
> PrivateKeyEntry

So this is one of the things that makes me angry about keytool: it
tells you there is only a single entry in the keystore and tells you
that it's a "private key". Well... there is also a certificate in
there and it's got signatures on it and stuff. I'd count that as at
least 2 items. Anyway...

> Certificate chain length: 1 Certificate[1]: Owner:

Okay, this is traditionally called the "subject":
This is *your certificate*, usually called the "server certificate".
It's usually the last link in a chain of trust going from the CA down
to the server cert.

> Issuer: CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US

Good: you have a certificate that has been issued (aka signed) by
Let's Encrypt.

You appear to be missing the Let's Encrypt intermediate certificate in
your keystore, which will be required for most browsers to trust the
certificate (chain).

Might I recommend using Qualys's fine SSL server test tool:

It probably would have told you that you have a single certificate in
your chain and that you need to have an intermediate certificate.

It turns out that it's fairly easy to fix this: just import LE's
intermediate certificate into your keystore, like this:

$ keytool -import -alias [Authority.intermediate] -trustcacerts \
   -file [authority's intermediate cert file] \
   -keystore yourkeystore.jks

Once you add this certificate, you will likely have to restart Tomcat
to pick-up the changes.

You can do this in a single operation to convert from the PEM-encoded
files that LE gives to you into a PKCS12 package like this:

$  openssl pkcs12 -export -in "${LE_BASE}/cert.pem" \
          -inkey "${LE_BASE}/privkey.pem" \
          -certfile "${LE_BASE}/fullchain.pem" \
          -out "${CATALINA_BASE}/${HOSTNAME}.p12" -name tomcat \
          -passout "pass:changeit"

Note that this command imports all 3 items (server key, server
certificate, and CA intermediate certs) into a single PKCS12 bundle.
Then you can convert that into a Java keystore. Or just use PKCS12 as
your keystore type from Tomcat and avoid the use of keytool altogether.

You might find these two presentations informative:

Hope that helps,
- -chris
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message