Trying to understand How Tomcat uses Keystore for SSL

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Don,

Post by Don Flinn
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.

Post by Don Flinn
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.

Post by Don Flinn
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.

Post by Don Flinn
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.

Post by Don Flinn
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.

Post by Don Flinn
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.

Post by Don Flinn
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
Keystore type: PKCS12 Keystore provider: SunJSSE
Your keystore contains 1 entry
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...

Post by Don Flinn
CN=info.finwoks.com

Okay, this is traditionally called the "subject": info.finworks.com.
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.

Post by Don Flinn
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:
https://www.ssllabs.com/ssltest/

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:
http://people.apache.org/~markt/presentations/2017-05-16-b-tomcat-ssl.pd
f

http://people.apache.org/~schultz/ApacheCon%20NA%202017/Let's%20Encrypt%
20Apache%20Tomcat.pdf

Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloLYUYdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjtxRAAisLpBKPg9VFN5dPH
tEeZQs7Bd6hM3NDBjRXE7RYAJhvBlOE2ImDkWXjRkJGedf00nTTQly6zKWHrusbC
VlJMoEK+T72XeJIv2y5up3K+VmartQZLK6twMCqDEVZBv0gaEz1T7yfe6WC6/G4W
oqGCkcDAF61P2u0K4QXldXBl1I83VCfEWWGpI7Bc1/5u7c/SE3kEN0D/V8Gs0H1r
8/LF2MzPSpGoJqSuRhyPWzklaK/ks+LSv1d7ur+ZrHHobSeMFtIHuhk6KakbheIL
3APEHZw3vHv70SFjvhviYg873CYOT52/x8zfzqpxc1z3X9JC/hAqzZUL7qKHPSMd
bbWTSu8Tv7XWARe2BdyRQDKFJSTPnUNFxvyWviekNK5HkJx2sSgcH8iiTJN5lrMQ
uEDZ4RukyT/b3VWn0RWtqvHnxZrLmXjWyV3MWNPFI0LYNuorJu6cROy4WnO7NFOV
dmvDKC79qJ/XOziOmaGKgL11hNGwqYB2pn/aS7G+VCLCG0UGp8B/64j/5mNd9BL5
a4DZXmonIPoKhjO/OP5H7hte2uqQAprrQgVI1JzKlYAb6wV+f4123nctlM+UeFBM
ytYYVpwyD/TXxeVr0SnmNpOlyPHnO6RRXPXfmiNEbdsjMef+Inljc4DlcLnlbdvK
Fc/zRGoUIB8+LN0T8NxVvXMAGGc=
=IHty
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

Don Flinn

2017-11-26 20:15:27 UTC

Chris

Thank you for your excellent reply and references.

I've been doing a lot of reading on SSL, certificates, keys, algorithms,
etc. Woo! However I still don't have it correct.

I've retrieved certificates from letsencrypt and following your suggestions
did the following.

Created a pkcs12 store using the following command line.
openssl pkcs12 -export -in "domain-chain.crt" -inkey "domain.key" -certfile
"ICDTrustRoot.crt" -out "MM.p12" -name tomcat -passout "pass:changeit"

where the domain-chain.crt contains two certificates and ICDTrustRoot
contains one as shown below -
PS C:\users\don\security\letsenc5> openssl x509 -noout -subject -issuer -in
domaincert1.crt (the first cert in domain-chain.crt)
subject= /CN=info.finwoks.com
issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

PS C:\users\don\security\letsenc5> openssl x509 -noout -subject -issuer -in
domaincert2.crt (the second cert in domain-chain.crt)
subject= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3

PS C:\users\don\security\letsenc4> openssl x509 -noout -subject -issuer -in
ICDTrustRoot.crt
subject= /O=Digital Signature Trust Co./CN=DST Root CA X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
so I have the three certificates and the private key which is shared with
letsencrypt called domain.key
My server.xml contains:
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
sslImplementationName="org.apache.tomcat.util.net.
openssl.OpenSSLImplementation"
port="8443" maxThreads="200"
scheme="https" secure="true" SSLEnabled="true" keystoreType="PKCS12"
keystoreFile="/users/don/Security/MM.p12" keystorePass="changeit"
clientAuth="false" sslProtocol="TLS"
/>

However when I restart Tomcat is get the following error in the Tomcat
error log and of course it fails in the handshake with the browser

org.apache.catalina.core.StandardService.initInternal Failed to initialize
connector [Connector[HTTP/1.1-8443]]
org.apache.catalina.LifecycleException: Failed to initialize component
[Connector[HTTP/1.1-8443]]
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
at org.apache.catalina.core.StandardService.initInternal(
StandardService.java:549)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.core.StandardServer.initInternal(
StandardServer.java:873)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.startup.Catalina.load(Catalina.java:606)
at org.apache.catalina.startup.Catalina.load(Catalina.java:629)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
Caused by: java.lang.UnsatisfiedLinkError: org.apache.tomcat.jni.Pool.
create(J)J
at org.apache.tomcat.jni.Pool.create(Native Method)
at org.apache.tomcat.util.net.openssl.OpenSSLEngine.<clinit>
(OpenSSLEngine.java:75)
at org.apache.tomcat.util.net.openssl.OpenSSLUtil.getImplementedProtocols(
OpenSSLUtil.java:61)
at org.apache.tomcat.util.net.SSLUtilBase.<init>(SSLUtilBase.java:46)
at org.apache.tomcat.util.net.openssl.OpenSSLUtil.<init>(
OpenSSLUtil.java:41)
at org.apache.tomcat.util.net.openssl.OpenSSLImplementation.getSSLUtil(
OpenSSLImplementation.java:36)
at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(
AbstractJsseEndpoint.java:82)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:261)
at org.apache.tomcat.util.net.AbstractEndpoint.init(
AbstractEndpoint.java:798)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:547)
at org.apache.coyote.http11.AbstractHttp11Protocol.init(
AbstractHttp11Protocol.java:66)
at org.apache.catalina.connector.Connector.initInternal(Connector.java:1010)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
... 12 more

I'm running Tomcat 9 in Amazon Web services using Windows Server. I don't
know what I'm doing wrong. Further help will be appreciated. It appears I
have the pkcs12 wrong.

Don

On Tue, Nov 14, 2017 at 4:33 PM, Christopher Schultz <

Post by Christopher Schultz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Don,

Post by Don Flinn
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.

Post by Don Flinn
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.

Post by Don Flinn
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.

Post by Don Flinn
Concatenate the CA cert, the private key and the user cert then put
these in keystore.

Post by Don Flinn
CN=info.finwoks.com

Post by Don Flinn
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).
https://www.ssllabs.com/ssltest/
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
$ 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
$ 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.
http://people.apache.org/~markt/presentations/2017-05-16-b-tomcat-ssl.pd
f
http://people.apache.org/~schultz/ApacheCon%20NA%202017/Let's%20Encrypt%
20Apache%20Tomcat.pdf
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloLYUYdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjtxRAAisLpBKPg9VFN5dPH
tEeZQs7Bd6hM3NDBjRXE7RYAJhvBlOE2ImDkWXjRkJGedf00nTTQly6zKWHrusbC
VlJMoEK+T72XeJIv2y5up3K+VmartQZLK6twMCqDEVZBv0gaEz1T7yfe6WC6/G4W
oqGCkcDAF61P2u0K4QXldXBl1I83VCfEWWGpI7Bc1/5u7c/SE3kEN0D/V8Gs0H1r
8/LF2MzPSpGoJqSuRhyPWzklaK/ks+LSv1d7ur+ZrHHobSeMFtIHuhk6KakbheIL
3APEHZw3vHv70SFjvhviYg873CYOT52/x8zfzqpxc1z3X9JC/hAqzZUL7qKHPSMd
bbWTSu8Tv7XWARe2BdyRQDKFJSTPnUNFxvyWviekNK5HkJx2sSgcH8iiTJN5lrMQ
uEDZ4RukyT/b3VWn0RWtqvHnxZrLmXjWyV3MWNPFI0LYNuorJu6cROy4WnO7NFOV
dmvDKC79qJ/XOziOmaGKgL11hNGwqYB2pn/aS7G+VCLCG0UGp8B/64j/5mNd9BL5
a4DZXmonIPoKhjO/OP5H7hte2uqQAprrQgVI1JzKlYAb6wV+f4123nctlM+UeFBM
ytYYVpwyD/TXxeVr0SnmNpOlyPHnO6RRXPXfmiNEbdsjMef+Inljc4DlcLnlbdvK
Fc/zRGoUIB8+LN0T8NxVvXMAGGc=
=IHty
-----END PGP SIGNATURE-----
---------------------------------------------------------------------

Don Flinn

2017-11-26 21:54:01 UTC

Didn't read closely enough. The protocol that I used is no longer
applicable for Tomcat 9.

Don

Post by Don Flinn
Chris
Thank you for your excellent reply and references.
I've been doing a lot of reading on SSL, certificates, keys, algorithms,
etc. Woo! However I still don't have it correct.
I've retrieved certificates from letsencrypt and following your
suggestions did the following.
Created a pkcs12 store using the following command line.
openssl pkcs12 -export -in "domain-chain.crt" -inkey "domain.key"
-certfile "ICDTrustRoot.crt" -out "MM.p12" -name tomcat -passout
"pass:changeit"
where the domain-chain.crt contains two certificates and ICDTrustRoot
contains one as shown below -
PS C:\users\don\security\letsenc5> openssl x509 -noout -subject -issuer
-in domaincert1.crt (the first cert in domain-chain.crt)
subject= /CN=info.finwoks.com
issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
PS C:\users\don\security\letsenc5> openssl x509 -noout -subject -issuer
-in domaincert2.crt (the second cert in domain-chain.crt)
subject= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
PS C:\users\don\security\letsenc4> openssl x509 -noout -subject -issuer
-in ICDTrustRoot.crt
subject= /O=Digital Signature Trust Co./CN=DST Root CA X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
so I have the three certificates and the private key which is shared with
letsencrypt called domain.key
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
sslImplementationName="org.apache.tomcat.util.net.openssl.
OpenSSLImplementation"
port="8443" maxThreads="200"
scheme="https" secure="true" SSLEnabled="true" keystoreType="PKCS12"
keystoreFile="/users/don/Security/MM.p12" keystorePass="changeit"
clientAuth="false" sslProtocol="TLS"
/>
However when I restart Tomcat is get the following error in the Tomcat
error log and of course it fails in the handshake with the browser
org.apache.catalina.core.StandardService.initInternal Failed to
initialize connector [Connector[HTTP/1.1-8443]]
org.apache.catalina.LifecycleException: Failed to initialize component
[Connector[HTTP/1.1-8443]]
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
at org.apache.catalina.core.StandardService.initInternal(Standa
rdService.java:549)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.core.StandardServer.initInternal(Standar
dServer.java:873)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.startup.Catalina.load(Catalina.java:606)
at org.apache.catalina.startup.Catalina.load(Catalina.java:629)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
Caused by: java.lang.UnsatisfiedLinkError: org.apache.tomcat.jni.Pool.cre
ate(J)J
at org.apache.tomcat.jni.Pool.create(Native Method)
at org.apache.tomcat.util.net.openssl.OpenSSLEngine.<clinit>(
OpenSSLEngine.java:75)
at org.apache.tomcat.util.net.openssl.OpenSSLUtil.getImplemente
dProtocols(OpenSSLUtil.java:61)
at org.apache.tomcat.util.net.SSLUtilBase.<init>(SSLUtilBase.java:46)
at org.apache.tomcat.util.net.openssl.OpenSSLUtil.<init>(OpenSS
LUtil.java:41)
at org.apache.tomcat.util.net.openssl.OpenSSLImplementation.get
SSLUtil(OpenSSLImplementation.java:36)
at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSs
l(AbstractJsseEndpoint.java:82)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:261)
at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEnd
point.java:798)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:547)
at org.apache.coyote.http11.AbstractHttp11Protocol.init(Abstrac
tHttp11Protocol.java:66)
at org.apache.catalina.connector.Connector.initInternal(Connect
or.java:1010)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
... 12 more
I'm running Tomcat 9 in Amazon Web services using Windows Server. I don't
know what I'm doing wrong. Further help will be appreciated. It appears I
have the pkcs12 wrong.
Don
On Tue, Nov 14, 2017 at 4:33 PM, Christopher Schultz <

Post by Christopher Schultz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Don,

Post by Don Flinn
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.

Post by Don Flinn
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.

Post by Don Flinn
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.

Post by Don Flinn
Concatenate the CA cert, the private key and the user cert then put
these in keystore.

Post by Don Flinn
CN=info.finwoks.com

Post by Don Flinn
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).
https://www.ssllabs.com/ssltest/
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
$ 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
$ 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.
http://people.apache.org/~markt/presentations/2017-05-16-b-tomcat-ssl.pd
f
<http://people.apache.org/~markt/presentations/2017-05-16-b-tomcat-ssl.pdf>
http://people.apache.org/~schultz/ApacheCon%20NA%202017/Let's%20Encrypt%
20Apache%20Tomcat.pdf
<http://people.apache.org/~schultz/ApacheCon%20NA%202017/Let's%20Encrypt%20Apache%20Tomcat.pdf>
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloLYUYdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjtxRAAisLpBKPg9VFN5dPH
tEeZQs7Bd6hM3NDBjRXE7RYAJhvBlOE2ImDkWXjRkJGedf00nTTQly6zKWHrusbC
VlJMoEK+T72XeJIv2y5up3K+VmartQZLK6twMCqDEVZBv0gaEz1T7yfe6WC6/G4W
oqGCkcDAF61P2u0K4QXldXBl1I83VCfEWWGpI7Bc1/5u7c/SE3kEN0D/V8Gs0H1r
8/LF2MzPSpGoJqSuRhyPWzklaK/ks+LSv1d7ur+ZrHHobSeMFtIHuhk6KakbheIL
3APEHZw3vHv70SFjvhviYg873CYOT52/x8zfzqpxc1z3X9JC/hAqzZUL7qKHPSMd
bbWTSu8Tv7XWARe2BdyRQDKFJSTPnUNFxvyWviekNK5HkJx2sSgcH8iiTJN5lrMQ
uEDZ4RukyT/b3VWn0RWtqvHnxZrLmXjWyV3MWNPFI0LYNuorJu6cROy4WnO7NFOV
dmvDKC79qJ/XOziOmaGKgL11hNGwqYB2pn/aS7G+VCLCG0UGp8B/64j/5mNd9BL5
a4DZXmonIPoKhjO/OP5H7hte2uqQAprrQgVI1JzKlYAb6wV+f4123nctlM+UeFBM
ytYYVpwyD/TXxeVr0SnmNpOlyPHnO6RRXPXfmiNEbdsjMef+Inljc4DlcLnlbdvK
Fc/zRGoUIB8+LN0T8NxVvXMAGGc=
=IHty
-----END PGP SIGNATURE-----
---------------------------------------------------------------------

Don Flinn

2017-11-27 03:35:12 UTC

IT WORKS!!!!

My next question is whether the Tomcat team would want this Java program
that does the heavy lifting for letsencrypt, which I would be happy to
clean up and make available as open source. The guts of the program comes
from - http://acme4j.shredzone.org, which is under the Apache license.

I've made a number of enhancements, e;g. a GUI front end; the ability to do
the letsencrypt authorization without any user intervention; the ability to
sit on an admin node retrieve and install the retrieved letsencrypt SSL
certificates on a remote tomcat node.

If the answer is yes, let me know the procedure to make it available as
open sourcce.

Don

Post by Don Flinn
Didn't read closely enough. The protocol that I used is no longer
applicable for Tomcat 9.
Don

Post by Don Flinn
Chris
Thank you for your excellent reply and references.
I've been doing a lot of reading on SSL, certificates, keys, algorithms,
etc. Woo! However I still don't have it correct.
I've retrieved certificates from letsencrypt and following your
suggestions did the following.
Created a pkcs12 store using the following command line.
openssl pkcs12 -export -in "domain-chain.crt" -inkey "domain.key"
-certfile "ICDTrustRoot.crt" -out "MM.p12" -name tomcat -passout
"pass:changeit"
where the domain-chain.crt contains two certificates and ICDTrustRoot
contains one as shown below -
PS C:\users\don\security\letsenc5> openssl x509 -noout -subject -issuer
-in domaincert1.crt (the first cert in domain-chain.crt)
subject= /CN=info.finwoks.com
issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
PS C:\users\don\security\letsenc5> openssl x509 -noout -subject -issuer
-in domaincert2.crt (the second cert in domain-chain.crt)
subject= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
PS C:\users\don\security\letsenc4> openssl x509 -noout -subject -issuer
-in ICDTrustRoot.crt
subject= /O=Digital Signature Trust Co./CN=DST Root CA X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
so I have the three certificates and the private key which is shared with
letsencrypt called domain.key
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
sslImplementationName="org.apache.tomcat.util.net.openssl.O
penSSLImplementation"
port="8443" maxThreads="200"
scheme="https" secure="true" SSLEnabled="true" keystoreType="PKCS12"
keystoreFile="/users/don/Security/MM.p12" keystorePass="changeit"
clientAuth="false" sslProtocol="TLS"
/>
However when I restart Tomcat is get the following error in the Tomcat
error log and of course it fails in the handshake with the browser
org.apache.catalina.core.StandardService.initInternal Failed to
initialize connector [Connector[HTTP/1.1-8443]]
org.apache.catalina.LifecycleException: Failed to initialize component
[Connector[HTTP/1.1-8443]]
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
at org.apache.catalina.core.StandardService.initInternal(Standa
rdService.java:549)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.core.StandardServer.initInternal(Standar
dServer.java:873)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.startup.Catalina.load(Catalina.java:606)
at org.apache.catalina.startup.Catalina.load(Catalina.java:629)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
Caused by: java.lang.UnsatisfiedLinkError: org.apache.tomcat.jni.Pool.cre
ate(J)J
at org.apache.tomcat.jni.Pool.create(Native Method)
at org.apache.tomcat.util.net.openssl.OpenSSLEngine.<clinit>(Op
enSSLEngine.java:75)
at org.apache.tomcat.util.net.openssl.OpenSSLUtil.getImplemente
dProtocols(OpenSSLUtil.java:61)
at org.apache.tomcat.util.net.SSLUtilBase.<init>(SSLUtilBase.java:46)
at org.apache.tomcat.util.net.openssl.OpenSSLUtil.<init>(OpenSS
LUtil.java:41)
at org.apache.tomcat.util.net.openssl.OpenSSLImplementation.get
SSLUtil(OpenSSLImplementation.java:36)
at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSs
l(AbstractJsseEndpoint.java:82)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:261)
at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEnd
point.java:798)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:547)
at org.apache.coyote.http11.AbstractHttp11Protocol.init(Abstrac
tHttp11Protocol.java:66)
at org.apache.catalina.connector.Connector.initInternal(Connect
or.java:1010)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
... 12 more
I'm running Tomcat 9 in Amazon Web services using Windows Server. I
don't know what I'm doing wrong. Further help will be appreciated. It
appears I have the pkcs12 wrong.
Don
On Tue, Nov 14, 2017 at 4:33 PM, Christopher Schultz <

Post by Christopher Schultz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Don,

Post by Don Flinn
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.

Post by Don Flinn
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.

Post by Don Flinn
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.

Post by Don Flinn
Concatenate the CA cert, the private key and the user cert then put
these in keystore.

Post by Don Flinn
CN=info.finwoks.com

Post by Don Flinn
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).
https://www.ssllabs.com/ssltest/
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
$ 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
$ 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.
http://people.apache.org/~markt/presentations/2017-05-16-b-tomcat-ssl.pd
f
<http://people.apache.org/~markt/presentations/2017-05-16-b-tomcat-ssl.pdf>
http://people.apache.org/~schultz/ApacheCon%20NA%202017/Let's%20Encrypt%
20Apache%20Tomcat.pdf
<http://people.apache.org/~schultz/ApacheCon%20NA%202017/Let's%20Encrypt%20Apache%20Tomcat.pdf>
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloLYUYdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjtxRAAisLpBKPg9VFN5dPH
tEeZQs7Bd6hM3NDBjRXE7RYAJhvBlOE2ImDkWXjRkJGedf00nTTQly6zKWHrusbC
VlJMoEK+T72XeJIv2y5up3K+VmartQZLK6twMCqDEVZBv0gaEz1T7yfe6WC6/G4W
oqGCkcDAF61P2u0K4QXldXBl1I83VCfEWWGpI7Bc1/5u7c/SE3kEN0D/V8Gs0H1r
8/LF2MzPSpGoJqSuRhyPWzklaK/ks+LSv1d7ur+ZrHHobSeMFtIHuhk6KakbheIL
3APEHZw3vHv70SFjvhviYg873CYOT52/x8zfzqpxc1z3X9JC/hAqzZUL7qKHPSMd
bbWTSu8Tv7XWARe2BdyRQDKFJSTPnUNFxvyWviekNK5HkJx2sSgcH8iiTJN5lrMQ
uEDZ4RukyT/b3VWn0RWtqvHnxZrLmXjWyV3MWNPFI0LYNuorJu6cROy4WnO7NFOV
dmvDKC79qJ/XOziOmaGKgL11hNGwqYB2pn/aS7G+VCLCG0UGp8B/64j/5mNd9BL5
a4DZXmonIPoKhjO/OP5H7hte2uqQAprrQgVI1JzKlYAb6wV+f4123nctlM+UeFBM
ytYYVpwyD/TXxeVr0SnmNpOlyPHnO6RRXPXfmiNEbdsjMef+Inljc4DlcLnlbdvK
Fc/zRGoUIB8+LN0T8NxVvXMAGGc=
=IHty
-----END PGP SIGNATURE-----
---------------------------------------------------------------------

Joleen Barker

2017-11-27 10:52:58 UTC

Hello Don,

I'm trying to understand these as well. I had a question regarding the data
and commands you used to display the certificate information. You wrote
that you used the following command to create a pkcs12 store:

openssl pkcs12 -export -in "domain-chain.crt" -inkey "domain.key" -certfile
"ICDTrustRoot.crt" -out "MM.p12" -name tomcat -passout "pass:changeit"

To display the 2 certs you show one example command to see the first one as:

openssl x509 -noout -subject -issuer -in domaincert1.crt subject= /CN=
info.finwoks.com issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

Where did the "domaincert1.crt" come from? I did not see anything in the
first command reference this and I was not sure how someone would know this
name and the second one called domaincert2.crt.

Thank you,

Joleen

Post by Don Flinn
IT WORKS!!!!
My next question is whether the Tomcat team would want this Java program
that does the heavy lifting for letsencrypt, which I would be happy to
clean up and make available as open source. The guts of the program comes
from - http://acme4j.shredzone.org, which is under the Apache license.
I've made a number of enhancements, e;g. a GUI front end; the ability to do
the letsencrypt authorization without any user intervention; the ability to
sit on an admin node retrieve and install the retrieved letsencrypt SSL
certificates on a remote tomcat node.
If the answer is yes, let me know the procedure to make it available as
open sourcce.
Don

Post by Don Flinn
Didn't read closely enough. The protocol that I used is no longer
applicable for Tomcat 9.
Don

with

Post by Don Flinn
letsencrypt called domain.key
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
sslImplementationName="org.apache.tomcat.util.net.openssl.O
penSSLImplementation"
port="8443" maxThreads="200"
scheme="https" secure="true" SSLEnabled="true" keystoreType="PKCS12"
keystoreFile="/users/don/Security/MM.p12" keystorePass="changeit"
clientAuth="false" sslProtocol="TLS"
/>
However when I restart Tomcat is get the following error in the Tomcat
error log and of course it fails in the handshake with the browser
org.apache.catalina.core.StandardService.initInternal Failed to
initialize connector [Connector[HTTP/1.1-8443]]
org.apache.catalina.LifecycleException: Failed to initialize component
[Connector[HTTP/1.1-8443]]
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
at org.apache.catalina.core.StandardService.initInternal(Standa
rdService.java:549)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.core.StandardServer.initInternal(Standar
dServer.java:873)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
at org.apache.catalina.startup.Catalina.load(Catalina.java:606)
at org.apache.catalina.startup.Catalina.load(Catalina.java:629)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)

org.apache.tomcat.jni.Pool.cre

Post by Don Flinn
ate(J)J
at org.apache.tomcat.jni.Pool.create(Native Method)
at org.apache.tomcat.util.net.openssl.OpenSSLEngine.<clinit>(Op
enSSLEngine.java:75)
at org.apache.tomcat.util.net.openssl.OpenSSLUtil.getImplemente
dProtocols(OpenSSLUtil.java:61)
at org.apache.tomcat.util.net.SSLUtilBase.<init>(SSLUtilBase.java:46)
at org.apache.tomcat.util.net.openssl.OpenSSLUtil.<init>(OpenSS
LUtil.java:41)
at org.apache.tomcat.util.net.openssl.OpenSSLImplementation.get
SSLUtil(OpenSSLImplementation.java:36)
at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSs
l(AbstractJsseEndpoint.java:82)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:261)
at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEnd
point.java:798)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:547)
at org.apache.coyote.http11.AbstractHttp11Protocol.init(Abstrac
tHttp11Protocol.java:66)
at org.apache.catalina.connector.Connector.initInternal(Connect
or.java:1010)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
... 12 more
I'm running Tomcat 9 in Amazon Web services using Windows Server. I
don't know what I'm doing wrong. Further help will be appreciated. It
appears I have the pkcs12 wrong.
Don
On Tue, Nov 14, 2017 at 4:33 PM, Christopher Schultz <

Post by Christopher Schultz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Don,

Post by Don Flinn
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.

Post by Don Flinn
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.

Post by Don Flinn
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.

Post by Don Flinn
Concatenate the CA cert, the private key and the user cert then put
these in keystore.

Post by Don Flinn
CN=info.finwoks.com

Post by Don Flinn
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).
https://www.ssllabs.com/ssltest/
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
$ 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
$ 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.
http://people.apache.org/~markt/presentations/2017-05-

16-b-tomcat-ssl.pd

Post by Christopher Schultz
f
<http://people.apache.org/~markt/presentations/2017-05-

16-b-tomcat-ssl.pdf>

Post by Christopher Schultz
http://people.apache.org/~schultz/ApacheCon%20NA%202017/

Let's%20Encrypt%

Post by Christopher Schultz
20Apache%20Tomcat.pdf
<http://people.apache.org/~schultz/ApacheCon%20NA%202017/

Let's%20Encrypt%20Apache%20Tomcat.pdf>

Post by Christopher Schultz
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloLYUYdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjtxRAAisLpBKPg9VFN5dPH
tEeZQs7Bd6hM3NDBjRXE7RYAJhvBlOE2ImDkWXjRkJGedf00nTTQly6zKWHrusbC
VlJMoEK+T72XeJIv2y5up3K+VmartQZLK6twMCqDEVZBv0gaEz1T7yfe6WC6/G4W
oqGCkcDAF61P2u0K4QXldXBl1I83VCfEWWGpI7Bc1/5u7c/SE3kEN0D/V8Gs0H1r
8/LF2MzPSpGoJqSuRhyPWzklaK/ks+LSv1d7ur+ZrHHobSeMFtIHuhk6KakbheIL
3APEHZw3vHv70SFjvhviYg873CYOT52/x8zfzqpxc1z3X9JC/hAqzZUL7qKHPSMd
bbWTSu8Tv7XWARe2BdyRQDKFJSTPnUNFxvyWviekNK5HkJx2sSgcH8iiTJN5lrMQ
uEDZ4RukyT/b3VWn0RWtqvHnxZrLmXjWyV3MWNPFI0LYNuorJu6cROy4WnO7NFOV
dmvDKC79qJ/XOziOmaGKgL11hNGwqYB2pn/aS7G+VCLCG0UGp8B/64j/5mNd9BL5
a4DZXmonIPoKhjO/OP5H7hte2uqQAprrQgVI1JzKlYAb6wV+f4123nctlM+UeFBM
ytYYVpwyD/TXxeVr0SnmNpOlyPHnO6RRXPXfmiNEbdsjMef+Inljc4DlcLnlbdvK
Fc/zRGoUIB8+LN0T8NxVvXMAGGc=
=IHty
-----END PGP SIGNATURE-----
---------------------------------------------------------------------

Don Flinn

2017-11-27 15:47:04 UTC

Hi Joleen,

My previous mail was cryptic. Below is a fuller explanation of what I did
to get things running.

First, I'm using Tomcat 9 and the protocol for the Tomcat 8.5 and up has
been expanded. Chris suggested that I use PKCS12 rather than JDK keystore,
which I have done. I'm also using the APR configuration. So redirected
connector that I'm using looks like:

<Connector
protocol="org.apache.coyote.http11.Http11NioProtocol"
port="8443" maxThreads="150" SSLEnabled="true">

<SSLHostConfig>
keystoreType="PKCS12"
<Certificate certificateKeyFile="C:/users/don/Security/domain.key"
certificateFile="C:/users/don/Security/domain-chain.crt"
certificateChainFile="C:/users/don/Security/ICDTrustRoot.crt"
type="RSA" />
</SSLHostConfig>

</Connector>

The domain key is the private key I used when getting the certificates from
letsencrypt. The certificate I got from letsencrypt I called
domain-chain.crt. Lastly I downloaded the ICDTrustRoot.crt from the
letsencrypt at https://letsencrypt.org/certificates. You will notice that
I'm using Window's syntax, which is just for the pathname where the
certificates live. You would use a Linux path syntax if you are running
Linux. You need three certificates for letsencrypt; a cert for your
domain, one for the intermediate and finally the root certificate.

What I call domain-chain.crt holds two certificates; my domain certificate
and the intermediate. In order to see what these were I separated them in
a text editor and called them domaincert1.crt and the second domaincert2.crt
Then I used openssl to see what was in them. For example:

openssl x509 -noout -subject -issuer -in domaincert1.crt
this printed out
subject= /CN=info.finwoks.com
issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

So that one was my domain cert issued by the letsencrypt intermediate

The second one certificate gave
subject= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3

which is the intermediate.

I downloaded the certificates using the java program mentioned in my
previous e-mail. Depending on your particular setup, you can get the four
items using different methods. I would suggest that you check what the
various certificates contain by using the ssl commands. I've also read that
the order of the certificates should be

Your domain
Intermediate
Known Root

So that's the order I used. A caution, in my reading I have found some
directions not to be accurate.

If what I have written is not clear, please let me know and I'll try to
clear it up.

Don

Post by Joleen Barker
Hello Don,
I'm trying to understand these as well. I had a question regarding the data
openssl pkcs12 -export -in "domain-chain.crt" -inkey "domain.key" -certfile
"ICDTrustRoot.crt" -out "MM.p12" -name tomcat -passout "pass:changeit"
openssl x509 -noout -subject -issuer -in domaincert1.crt subject= /CN=
info.finwoks.com issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Where did the "domaincert1.crt" come from? I did not see anything in the
first command reference this and I was not sure how someone would know this
name and the second one called domaincert2.crt.
Thank you,
Joleen

comes

Post by Don Flinn
from - http://acme4j.shredzone.org, which is under the Apache license.
I've made a number of enhancements, e;g. a GUI front end; the ability to

Post by Don Flinn
the letsencrypt authorization without any user intervention; the ability

Post by Don Flinn
sit on an admin node retrieve and install the retrieved letsencrypt SSL
certificates on a remote tomcat node.
If the answer is yes, let me know the procedure to make it available as
open sourcce.
Don

Post by Don Flinn
Didn't read closely enough. The protocol that I used is no longer
applicable for Tomcat 9.
Don

Post by Don Flinn
Chris
Thank you for your excellent reply and references.
I've been doing a lot of reading on SSL, certificates, keys,

algorithms,

Post by Don Flinn
etc. Woo! However I still don't have it correct.
I've retrieved certificates from letsencrypt and following your
suggestions did the following.
Created a pkcs12 store using the following command line.
openssl pkcs12 -export -in "domain-chain.crt" -inkey "domain.key"
-certfile "ICDTrustRoot.crt" -out "MM.p12" -name tomcat -passout
"pass:changeit"
where the domain-chain.crt contains two certificates and ICDTrustRoot
contains one as shown below -
PS C:\users\don\security\letsenc5> openssl x509 -noout -subject

-issuer

Post by Don Flinn
-in domaincert1.crt (the first cert in domain-chain.crt)
subject= /CN=info.finwoks.com
issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
PS C:\users\don\security\letsenc5> openssl x509 -noout -subject

-issuer

Post by Don Flinn
-in domaincert2.crt (the second cert in domain-chain.crt)
subject= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
PS C:\users\don\security\letsenc4> openssl x509 -noout -subject

-issuer

Post by Don Flinn
-in ICDTrustRoot.crt
subject= /O=Digital Signature Trust Co./CN=DST Root CA X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
so I have the three certificates and the private key which is shared

with

Post by Don Flinn
letsencrypt called domain.key
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
sslImplementationName="org.apache.tomcat.util.net.

openssl.O

Post by Don Flinn
penSSLImplementation"
port="8443" maxThreads="200"
scheme="https" secure="true" SSLEnabled="true"

keystoreType="PKCS12"

Post by Don Flinn
keystoreFile="/users/don/Security/MM.p12" keystorePass="changeit"
clientAuth="false" sslProtocol="TLS"
/>
However when I restart Tomcat is get the following error in the Tomcat
error log and of course it fails in the handshake with the browser
org.apache.catalina.core.StandardService.initInternal Failed to
initialize connector [Connector[HTTP/1.1-8443]]
org.apache.catalina.LifecycleException: Failed to initialize

component

Post by Don Flinn
[Connector[HTTP/1.1-8443]]
at org.apache.catalina.util.LifecycleBase.init(

LifecycleBase.java:112)

Post by Don Flinn
at org.apache.catalina.core.StandardService.initInternal(Standa
rdService.java:549)
at org.apache.catalina.util.LifecycleBase.init(

LifecycleBase.java:107)

Post by Don Flinn
at org.apache.catalina.core.StandardServer.initInternal(Standar
dServer.java:873)
at org.apache.catalina.util.LifecycleBase.init(

LifecycleBase.java:107)

Post by Don Flinn
at org.apache.catalina.startup.Catalina.load(Catalina.java:606)
at org.apache.catalina.startup.Catalina.load(Catalina.java:629)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)

org.apache.tomcat.jni.Pool.cre

LifecycleBase.java:107)

Post by Don Flinn
... 12 more
I'm running Tomcat 9 in Amazon Web services using Windows Server. I
don't know what I'm doing wrong. Further help will be appreciated. It
appears I have the pkcs12 wrong.
Don
On Tue, Nov 14, 2017 at 4:33 PM, Christopher Schultz <

Post by Christopher Schultz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Don,

Post by Don Flinn
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.

That message may be misleading. If the certificate is self-signed

than

Post by Christopher Schultz
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.

Post by Don Flinn
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.

Post by Don Flinn
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.

Post by Don Flinn
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

Post by Christopher Schultz
together. This only works with PEM-encoded files like OpenSSL likes

Post by Christopher Schultz
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.

Post by Don Flinn
CN=info.finwoks.com

Post by Don Flinn
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

Post by Christopher Schultz
your keystore, which will be required for most browsers to trust the
certificate (chain).
https://www.ssllabs.com/ssltest/
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
$ 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
$ 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.

Post by Christopher Schultz
http://people.apache.org/~markt/presentations/2017-05-

16-b-tomcat-ssl.pd

Post by Christopher Schultz
f
<http://people.apache.org/~markt/presentations/2017-05-

16-b-tomcat-ssl.pdf>

Post by Christopher Schultz
http://people.apache.org/~schultz/ApacheCon%20NA%202017/

Let's%20Encrypt%

Post by Christopher Schultz
20Apache%20Tomcat.pdf
<http://people.apache.org/~schultz/ApacheCon%20NA%202017/

Let's%20Encrypt%20Apache%20Tomcat.pdf>

---------

Joleen Barker

2017-11-27 16:32:30 UTC

Perfect. Thank you for the clarification I was having a problem putting it
all together. I got it now.

-Joleen

Post by Don Flinn
Hi Joleen,
My previous mail was cryptic. Below is a fuller explanation of what I did
to get things running.
First, I'm using Tomcat 9 and the protocol for the Tomcat 8.5 and up has
been expanded. Chris suggested that I use PKCS12 rather than JDK keystore,
which I have done. I'm also using the APR configuration. So redirected
<Connector
protocol="org.apache.coyote.http11.Http11NioProtocol"
port="8443" maxThreads="150" SSLEnabled="true">
<SSLHostConfig>
keystoreType="PKCS12"
<Certificate certificateKeyFile="C:/users/don/Security/domain.key"
certificateFile="C:/users/don/Security/domain-chain.crt"
certificateChainFile="C:/users/don/Security/ICDTrustRoot.crt"
type="RSA" />
</SSLHostConfig>
</Connector>
The domain key is the private key I used when getting the certificates from
letsencrypt. The certificate I got from letsencrypt I called
domain-chain.crt. Lastly I downloaded the ICDTrustRoot.crt from the
letsencrypt at https://letsencrypt.org/certificates. You will notice that
I'm using Window's syntax, which is just for the pathname where the
certificates live. You would use a Linux path syntax if you are running
Linux. You need three certificates for letsencrypt; a cert for your
domain, one for the intermediate and finally the root certificate.
What I call domain-chain.crt holds two certificates; my domain certificate
and the intermediate. In order to see what these were I separated them in
a text editor and called them domaincert1.crt and the second
domaincert2.crt
openssl x509 -noout -subject -issuer -in domaincert1.crt
this printed out
subject= /CN=info.finwoks.com
issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
So that one was my domain cert issued by the letsencrypt intermediate
The second one certificate gave
subject= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
which is the intermediate.
I downloaded the certificates using the java program mentioned in my
previous e-mail. Depending on your particular setup, you can get the four
items using different methods. I would suggest that you check what the
various certificates contain by using the ssl commands. I've also read that
the order of the certificates should be
Your domain
Intermediate
Known Root
So that's the order I used. A caution, in my reading I have found some
directions not to be accurate.
If what I have written is not clear, please let me know and I'll try to
clear it up.
Don

Post by Joleen Barker
Hello Don,
I'm trying to understand these as well. I had a question regarding the

data

Post by Joleen Barker
openssl pkcs12 -export -in "domain-chain.crt" -inkey "domain.key"

-certfile

Post by Joleen Barker
"ICDTrustRoot.crt" -out "MM.p12" -name tomcat -passout "pass:changeit"
openssl x509 -noout -subject -issuer -in domaincert1.crt subject= /CN=
info.finwoks.com issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt

Authority

Post by Joleen Barker
X3
Where did the "domaincert1.crt" come from? I did not see anything in the
first command reference this and I was not sure how someone would know

this

Post by Joleen Barker
name and the second one called domaincert2.crt.
Thank you,
Joleen

Post by Don Flinn
IT WORKS!!!!
My next question is whether the Tomcat team would want this Java

program

Post by Don Flinn
that does the heavy lifting for letsencrypt, which I would be happy to
clean up and make available as open source. The guts of the program

comes

Post by Don Flinn
from - http://acme4j.shredzone.org, which is under the Apache

license.

Post by Don Flinn
I've made a number of enhancements, e;g. a GUI front end; the ability

Post by Joleen Barker
do

Post by Don Flinn
the letsencrypt authorization without any user intervention; the

ability

Post by Joleen Barker
to

Post by Don Flinn
Didn't read closely enough. The protocol that I used is no longer
applicable for Tomcat 9.
Don

Post by Don Flinn
Chris
Thank you for your excellent reply and references.
I've been doing a lot of reading on SSL, certificates, keys,

algorithms,

ICDTrustRoot

Post by Don Flinn
contains one as shown below -
PS C:\users\don\security\letsenc5> openssl x509 -noout -subject

-issuer

-issuer

-issuer

with

Post by Don Flinn
letsencrypt called domain.key
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
sslImplementationName="org.apache.tomcat.util.net.

openssl.O

Post by Don Flinn
penSSLImplementation"
port="8443" maxThreads="200"
scheme="https" secure="true" SSLEnabled="true"

keystoreType="PKCS12"

Post by Don Flinn
keystoreFile="/users/don/Security/MM.p12"

keystorePass="changeit"

Post by Don Flinn
clientAuth="false" sslProtocol="TLS"
/>
However when I restart Tomcat is get the following error in the

Tomcat

Post by Don Flinn
error log and of course it fails in the handshake with the browser
org.apache.catalina.core.StandardService.initInternal Failed to
initialize connector [Connector[HTTP/1.1-8443]]
org.apache.catalina.LifecycleException: Failed to initialize

component

Post by Don Flinn
[Connector[HTTP/1.1-8443]]
at org.apache.catalina.util.LifecycleBase.init(

LifecycleBase.java:112)

Post by Don Flinn
at org.apache.catalina.core.StandardService.initInternal(Standa
rdService.java:549)
at org.apache.catalina.util.LifecycleBase.init(

LifecycleBase.java:107)

Post by Don Flinn
at org.apache.catalina.core.StandardServer.initInternal(Standar
dServer.java:873)
at org.apache.catalina.util.LifecycleBase.init(

LifecycleBase.java:107)

org.apache.tomcat.jni.Pool.cre

SSLUtilBase.java:46)

Post by Don Flinn
at org.apache.tomcat.util.net.openssl.OpenSSLUtil.<init>(OpenSS
LUtil.java:41)
at org.apache.tomcat.util.net.openssl.OpenSSLImplementation.get
SSLUtil(OpenSSLImplementation.java:36)
at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSs
l(AbstractJsseEndpoint.java:82)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.

java:261)

Post by Don Flinn
at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEnd
point.java:798)
at org.apache.coyote.AbstractProtocol.init(

AbstractProtocol.java:547)

Post by Don Flinn
at org.apache.coyote.http11.AbstractHttp11Protocol.init(Abstrac
tHttp11Protocol.java:66)
at org.apache.catalina.connector.Connector.initInternal(Connect
or.java:1010)
at org.apache.catalina.util.LifecycleBase.init(

LifecycleBase.java:107)

Post by Don Flinn
... 12 more
I'm running Tomcat 9 in Amazon Web services using Windows Server. I
don't know what I'm doing wrong. Further help will be appreciated.

Post by Don Flinn
appears I have the pkcs12 wrong.
Don
On Tue, Nov 14, 2017 at 4:33 PM, Christopher Schultz <

Post by Christopher Schultz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Don,

Post by Don Flinn
I've done some reading on SSL and understand the protocol is as
follows; Client/Browser sends ClientHello and server Tomcat

replies

Post by Don Flinn
with ServerHello. This establishes the protocol they will use.

The

Post by Don Flinn
server then sends the certificate and the public key - in the
clear The browser encrypts a message containing the servers

domain,

Post by Don Flinn
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

Post by Christopher Schultz
never has the client's private key. The handshake is done using
public-key/asymmetric encryption and part of that handshake

includes

Post by Christopher Schultz
establishing the keys to be used for the bulk encryption -- the
encryption used after the handshake.

Post by Don Flinn
The browser and Tomcat then establish a secret key to send

messages

Post by Don Flinn
back and forth.

That's the bulk encryption key. Note that it can be re-negotiated

Post by Christopher Schultz
intervals during the conversation if necessary.

Post by Don Flinn
If I have the above correct, I must have keystore set up
incorrectly, since running my scenario I get an error in the

Chrome

Post by Don Flinn
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

Post by Don Flinn
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

Post by Don Flinn
certificate?

That message may be misleading. If the certificate is self-signed

than

Post by Christopher Schultz
of course the certificate signer is "known" to the client (Chrome)
because it's just identified itself (as itself!). What it means to

Post by Christopher Schultz
"unknown" is that it is /untrusted/. You haven't told Chrome that

you

Post by Christopher Schultz
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,

Post by Christopher Schultz
DigiCert, Let's Encrypt, etc. -- then the browser /will/ recognize

it.

Post by Don Flinn
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

Post by Christopher Schultz
LE's tools to obtain a signed certificate.

Post by Don Flinn
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

Post by Don Flinn
I did following their instructions.

OpenSSL will do DER/PEM files and also PKCS12 keystores, but they

are

Post by Christopher Schultz
interchangeable and contain the same types of key material... just

Post by Christopher Schultz
different kinds of packages.

Post by Don Flinn
Concatenate the CA cert, the private key and the user cert then

put

Post by Don Flinn
these in keystore.

Be careful with terms. Concatenation usually means just slamming

bytes

Post by Christopher Schultz
together. This only works with PEM-encoded files like OpenSSL likes

Post by Christopher Schultz
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.

Post by Don Flinn
The result is shown below. Tomcat isn't able to use this

keystore

Post by Don Flinn
to communicate with the browser for some reason. Why? What's
missing or incorrect?
C:\Users\don\Security\letsenc>%keytool% -list -keystore

MMcert.p12

Post by Don Flinn
Keystore type: PKCS12 Keystore provider: SunJSSE
Your keystore contains 1 entry
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

Post by Christopher Schultz
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...

Post by Don Flinn
CN=info.finwoks.com

info.finworks.com.

Post by Christopher Schultz
This is *your certificate*, usually called the "server

certificate".

Post by Christopher Schultz
It's usually the last link in a chain of trust going from the CA

down

Post by Christopher Schultz
to the server cert.

Post by Don Flinn
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

Post by Christopher Schultz
your keystore, which will be required for most browsers to trust

the

Post by Christopher Schultz
certificate (chain).
https://www.ssllabs.com/ssltest/
It probably would have told you that you have a single certificate

Post by Christopher Schultz
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
$ 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

Post by Christopher Schultz
to pick-up the changes.
You can do this in a single operation to convert from the

PEM-encoded

Post by Christopher Schultz
$ 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.

Post by Christopher Schultz
Then you can convert that into a Java keystore. Or just use PKCS12

Post by Christopher Schultz
your keystore type from Tomcat and avoid the use of keytool

altogether.

Post by Christopher Schultz
http://people.apache.org/~markt/presentations/2017-05-

16-b-tomcat-ssl.pd

Post by Christopher Schultz
f
<http://people.apache.org/~markt/presentations/2017-05-

16-b-tomcat-ssl.pdf>

Post by Christopher Schultz
http://people.apache.org/~schultz/ApacheCon%20NA%202017/

Let's%20Encrypt%

Post by Christopher Schultz
20Apache%20Tomcat.pdf
<http://people.apache.org/~schultz/ApacheCon%20NA%202017/

Let's%20Encrypt%20Apache%20Tomcat.pdf>

---------

Christopher Schultz

2017-11-28 17:59:18 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Don,

Post by Don Flinn
My previous mail was cryptic. Below is a fuller explanation of
what I did to get things running.
First, I'm using Tomcat 9 and the protocol for the Tomcat 8.5 and
up has been expanded. Chris suggested that I use PKCS12 rather
than JDK keystore, which I have done.

Actually, at this point, I'd be using the PEM-encoded DER files (just
like httpd does) instead of a packaged cert/key bundle, just because I
find those easier to deal with.

Post by Don Flinn
I'm also using the APR configuration. So redirected connector that
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
port="8443" maxThreads="150" SSLEnabled="true">
<SSLHostConfig> keystoreType="PKCS12" <Certificate
certificateKeyFile="C:/users/don/Security/domain.key"
certificateFile="C:/users/don/Security/domain-chain.crt"
certificateChainFile="C:/users/don/Security/ICDTrustRoot.crt"
type="RSA" /> </SSLHostConfig>
</Connector>

In fact, I think you are using PEM-encoded DER files and not a
packaged keystore, even though your SSLHostConfig's keystoreType is
set to "PKCS12".

Post by Don Flinn
The domain key is the private key I used when getting the
certificates from letsencrypt. The certificate I got from
letsencrypt I called domain-chain.crt. Lastly I downloaded the
ICDTrustRoot.crt from the letsencrypt at
https://letsencrypt.org/certificates.

If you use a tool like certbot-auto (which may or may not be available
for Windows), all of this is done automatically for you.

Post by Don Flinn
You will notice that I'm using Window's syntax, which is just for
the pathname where the certificates live. You would use a Linux
path syntax if you are running Linux. You need three certificates
for letsencrypt; a cert for your domain, one for the intermediate
and finally the root certificate.

Post by Don Flinn
What I call domain-chain.crt holds two certificates; my domain
certificate and the intermediate. In order to see what these were
I separated them in a text editor and called them domaincert1.crt
and the second domaincert2.crt Then I used openssl to see what was
openssl x509 -noout -subject -issuer -in domaincert1.crt this
printed out subject= /CN=info.finwoks.com issuer= /C=US/O=Let's
Encrypt/CN=Let's Encrypt Authority X3
So that one was my domain cert issued by the letsencrypt
intermediate
The second one certificate gave subject= /C=US/O=Let's
Encrypt/CN=Let's Encrypt Authority X3 issuer= /O=Digital Signature
Trust Co./CN=DST Root CA X3
which is the intermediate.

I'll have to triple-check, but I believe you can put all certificates
into a single file like you can do with httpd. Just make sure that
your server's certificate (leaf) is listed first, then the
intermediate certificate(s), then the root certificate. Usually you do
not need to supply the root certificate since most clients should have
the root certificates available already.

Use SSL Labs' SSLTest[1] to help make sure you don't have too little
or too much in your certificate. Too little and your clients will get
trust errors. Too much and you'll be wasting bandwidth sending the
root CA certificate to clients who don't need it.

Post by Don Flinn
I downloaded the certificates using the java program mentioned in
my previous e-mail. Depending on your particular setup, you can get
the four items using different methods. I would suggest that you
check what the various certificates contain by using the ssl
commands. I've also read that the order of the certificates should
be
Your domain Intermediate Known Root
So that's the order I used. A caution, in my reading I have found
some directions not to be accurate.

If there's anything inaccurate on the Tomcat site, please post here.
If there's anything inaccurate with the httpd site, please post to the
httpd-users list ... or here if you are super lazy and maybe one of
the lurking httpd committers will take care of the problem.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlodo/YdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFhuYQ//Tigpqew5deTYJQkv
fQDyNFReS+G4jfv2RqX9a01xOVPTz3lvHjD3HbKnvSAMDf96fBkoF6WNNz7i0wEH
hnbOw1ETh8AWDVrkyT1nQkqPOpYEGIP+me53q2d1FpSAtgjedHQQ4ccGDOlM2ygn
fgtaKZ1fyvvNdqAnUw2vFE17UFQnkNsMpfG51l12GxJkd3HyxqQTXUd19qxqsqKg
FhWvTdL4HYEyRF8U+8aNhyrOQvDFx0NKaP22YsHX3HuIEKknnOl9B+1QXx0WtwO0
G6txDUgS9bkU5vCZsdaJ+26BaMhGA+ndm+mGAOmmEjdLVNEHQUSxCxqYg5SO0Uby
yY0pF4cXzyy8LJxtLuvTKAq4bxB0Pl/zpYmwq84+E7DB99m87kmRF3/2rdavfoQY
Fz94kM8zK5+cJszh/Y7d14iRHBlSi8fxQxiZ7eIbHyE55cB9HP7RbG/AtN2Grlti
qCsI8rX+KAYFohpjZVb4dz74SUjdtjVl7j+ZESQDdgR+HoMt9T199THOiSHb23OY
ahGOtGdsA0QWOwfkfx+P+HlXyngRe60NFhn/mSSpKVbkfXsS0fP7H3xBjhWat0Uo
AVkmuSXBS+DjNQiJR6pVcAfTZM5cBHnx/dmaCmdf/+cUWGhBjetBx5psRUisAwrI
XzH0Rm64sFKBMBqw7DstT7Z6pgk=
=DsYU
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

Don Flinn

2017-11-28 21:55:33 UTC

Chris,

Thanks for the corrections.

Post by Christopher Schultz
In fact, I think you are using PEM-encoded DER files and not a
packaged keystore, even though your SSLHostConfig's keystoreType is
set to "PKCS12".

Yes, I am using PEM files. Got to read more on DER files. So do I just
drop the keystoreType="PKCS12" from the connector?

Post by Christopher Schultz
I'll have to triple-check, but I believe you can put all certificates
into a single file like you can do with httpd. Just make sure that
your server's certificate (leaf) is listed first, then the
intermediate certificate(s), then the root certificate. Usually you do
not need to supply the root certificate since most clients should have
the root certificates available already.

I'll give that a try.

Post by Christopher Schultz
Use SSL Labs' SSLTest[1] to help make sure you don't have too little
or too much in your certificate. Too little and your clients will get
trust errors. Too much and you'll be wasting bandwidth

Will do

Post by Christopher Schultz
If there's anything inaccurate on the Tomcat site

No, I was talking about other sites, not the Tomcat site. I've been
reading all over the internet for that which seems related. My statement
was a caution to not believe everything you read. 'Trust but verify'

Your e-mail has been very helpful, not only to me, but I believe to
others. With respect to the Tomcat site, I think a
lot of what you wrote would be very helpful there. For example, the Tomcat
write up on SSL describes how to do self signed certificates and
fleetingly mentions
that if you have a certificate from a CA that you could use e.g. openssl
and then refers the reader to their java documentation and openssl
documentation. Not too helpful to the security/Tomcat novice.

Thanks for your patience and help.
Don

On Tue, Nov 28, 2017 at 12:59 PM, Christopher Schultz <

Post by Christopher Schultz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Don,

Post by Christopher Schultz
My previous mail was cryptic. Below is a fuller explanation of
what I did to get things running.
First, I'm using Tomcat 9 and the protocol for the Tomcat 8.5 and
up has been expanded. Chris suggested that I use PKCS12 rather
than JDK keystore, which I have done.

Actually, at this point, I'd be using the PEM-encoded DER files (just
like httpd does) instead of a packaged cert/key bundle, just because I
find those easier to deal with.

Post by Christopher Schultz
I'm also using the APR configuration. So redirected connector that
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
port="8443" maxThreads="150" SSLEnabled="true">
<SSLHostConfig> keystoreType="PKCS12" <Certificate
certificateKeyFile="C:/users/don/Security/domain.key"
certificateFile="C:/users/don/Security/domain-chain.crt"
certificateChainFile="C:/users/don/Security/ICDTrustRoot.crt"
type="RSA" /> </SSLHostConfig>
</Connector>

In fact, I think you are using PEM-encoded DER files and not a
packaged keystore, even though your SSLHostConfig's keystoreType is
set to "PKCS12".

Post by Christopher Schultz
The domain key is the private key I used when getting the
certificates from letsencrypt. The certificate I got from
letsencrypt I called domain-chain.crt. Lastly I downloaded the
ICDTrustRoot.crt from the letsencrypt at
https://letsencrypt.org/certificates.

If you use a tool like certbot-auto (which may or may not be available
for Windows), all of this is done automatically for you.

Post by Christopher Schultz
You will notice that I'm using Window's syntax, which is just for
the pathname where the certificates live. You would use a Linux
path syntax if you are running Linux. You need three certificates
for letsencrypt; a cert for your domain, one for the intermediate
and finally the root certificate.

Post by Christopher Schultz
What I call domain-chain.crt holds two certificates; my domain
certificate and the intermediate. In order to see what these were
I separated them in a text editor and called them domaincert1.crt
and the second domaincert2.crt Then I used openssl to see what was
openssl x509 -noout -subject -issuer -in domaincert1.crt this
printed out subject= /CN=info.finwoks.com issuer= /C=US/O=Let's
Encrypt/CN=Let's Encrypt Authority X3
So that one was my domain cert issued by the letsencrypt
intermediate
The second one certificate gave subject= /C=US/O=Let's
Encrypt/CN=Let's Encrypt Authority X3 issuer= /O=Digital Signature
Trust Co./CN=DST Root CA X3
which is the intermediate.

I'll have to triple-check, but I believe you can put all certificates
into a single file like you can do with httpd. Just make sure that
your server's certificate (leaf) is listed first, then the
intermediate certificate(s), then the root certificate. Usually you do
not need to supply the root certificate since most clients should have
the root certificates available already.
Use SSL Labs' SSLTest[1] to help make sure you don't have too little
or too much in your certificate. Too little and your clients will get
trust errors. Too much and you'll be wasting bandwidth sending the
root CA certificate to clients who don't need it.

Post by Christopher Schultz
I downloaded the certificates using the java program mentioned in
my previous e-mail. Depending on your particular setup, you can get
the four items using different methods. I would suggest that you
check what the various certificates contain by using the ssl
commands. I've also read that the order of the certificates should
be
Your domain Intermediate Known Root
So that's the order I used. A caution, in my reading I have found
some directions not to be accurate.

If there's anything inaccurate on the Tomcat site, please post here.
If there's anything inaccurate with the httpd site, please post to the
httpd-users list ... or here if you are super lazy and maybe one of
the lurking httpd committers will take care of the problem.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlodo/YdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFhuYQ//Tigpqew5deTYJQkv
fQDyNFReS+G4jfv2RqX9a01xOVPTz3lvHjD3HbKnvSAMDf96fBkoF6WNNz7i0wEH
hnbOw1ETh8AWDVrkyT1nQkqPOpYEGIP+me53q2d1FpSAtgjedHQQ4ccGDOlM2ygn
fgtaKZ1fyvvNdqAnUw2vFE17UFQnkNsMpfG51l12GxJkd3HyxqQTXUd19qxqsqKg
FhWvTdL4HYEyRF8U+8aNhyrOQvDFx0NKaP22YsHX3HuIEKknnOl9B+1QXx0WtwO0
G6txDUgS9bkU5vCZsdaJ+26BaMhGA+ndm+mGAOmmEjdLVNEHQUSxCxqYg5SO0Uby
yY0pF4cXzyy8LJxtLuvTKAq4bxB0Pl/zpYmwq84+E7DB99m87kmRF3/2rdavfoQY
Fz94kM8zK5+cJszh/Y7d14iRHBlSi8fxQxiZ7eIbHyE55cB9HP7RbG/AtN2Grlti
qCsI8rX+KAYFohpjZVb4dz74SUjdtjVl7j+ZESQDdgR+HoMt9T199THOiSHb23OY
ahGOtGdsA0QWOwfkfx+P+HlXyngRe60NFhn/mSSpKVbkfXsS0fP7H3xBjhWat0Uo
AVkmuSXBS+DjNQiJR6pVcAfTZM5cBHnx/dmaCmdf/+cUWGhBjetBx5psRUisAwrI
XzH0Rm64sFKBMBqw7DstT7Z6pgk=
=DsYU
-----END PGP SIGNATURE-----
---------------------------------------------------------------------

Christopher Schultz

2017-11-29 14:37:26 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Don,

Post by Christopher Schultz
In fact, I think you are using PEM-encoded DER files and not a
packaged keystore, even though your SSLHostConfig's
keystoreType is set to "PKCS12".

Yes, I am using PEM files. Got to read more on DER files.

PEM is an encoding, while DER is really the file format. It's like
saying "is this file text/plain or UTF-8?"

This is a great read for almost anyone who cares about x509 certificates
:

https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs-ce
r-vs-pem-certificates-and-how-to-convert-them

Post by Don Flinn
So do I just drop the keystoreType="PKCS12" from the connector?

Theoretically, yes. The keystoreType is only used when there is a
keystore and not "certificate files", etc.

Post by Christopher Schultz
If there's anything inaccurate on the Tomcat site

Mark has given a number of presentations on TLS and they are very
accessible. Have a look at the slides (and some audio/video) on the
"presentations" page on the Tomcat site. Each of them has a varying
level of "introductoryness", but I think the more recent ones like
"Introduction to Tomcat and TLS" from TomcatCon in Miami are probably
the best ones to see for beginners.

Post by Don Flinn
Your e-mail has been very helpful, not only to me, but I believe
to others. With respect to the Tomcat site, I think a lot of what
you wrote would be very helpful there. For example, the Tomcat
write up on SSL describes how to do self signed certificates and
fleetingly mentions that if you have a certificate from a CA that
you could use e.g. openssl and then refers the reader to their java
documentation and openssl documentation. Not too helpful to the
security/Tomcat novice.

Agreed. Would you care to write some new documentation and/or prepare
a patch for the site? IT's usually best when beginners write for their
own audience. I, for example, understand it backwards and forwards so
when I write I have a skewed perspective. Writing as a beginner can
re-focus the narrative for a different audience.

If you need any help grabbing the site from svn, etc. please just ask.

Post by Don Flinn
Thanks for your patience and help.

You are more important than the software. No, really:
https://blogs.apache.org/foundation/entry/asf_15_community_over_code

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloexiYdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFiY1Q//SLRGAzEuc2QzyvK9
svCG+s0HKA1QY+ubtdmoy+czFtm1b857uQ6L0Zo8KCp+edzYvTyd7iupGjPngEqr
5B9qRV3bcu3jsvMUcXEFe779MjjKsSX+m0jF8/9A1RtOvtEqqemlC6Q5AVuSZZUf
usSrTjXV2XyVlEtv0J5Rw+hMtLUpRwppg1LKAX5ZflHdhA1Zdq+TH6NSbLQlPr1z
WRzpLuOfSpt6Cnx2Kfqcwgop0EqCyPFcIqC3o2V+ONDQh4Z7FOdUNn70O03ympDg
fRMZbo8o0mX6RyjSk0nDFEfXLv2lafPoOrE5OUMvnuN4bZ472Jpq3nDtl0ZwYSIy
IcjXnfw+NUNTcIkJVz0K009/K/U8U4O4NBm5IBW4uFa2yapx717pB8H/Fmr6LvEr
FuIZG6wODc7YtN3kqbHR8J/3N1n3q6SM3CXyyjfazN0Kur0e4FOIE5WagzZTwQSm
K7LJsuIu84sVEShPcTB2CvTsaawJQj7clCM+eZngejuvuxSiwiC0u0zWKfoPDD8Z
bbXY69RJ0F1iKw7rgj+tr1KOxoNaDyHV8ys7CKinuG32hb37qzntygLrGZ0ZPOQZ
pUTuSsm1Zn/Zd/3oLWIhXJ9UZA5OfwhYYt6YwaTo4JYLhB1IsiVl9qqdzo2CQLIY
UHuG7kdiTBEig/ej+/RBOLZSI0k=
=6iU6
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

Don Flinn

2017-12-01 08:14:24 UTC

Chris

I'll be happy to accept your challenge to try to write some documentation
for the site from a newbee's point of view. It will be on the slow side as
my 'day job' will interfere somewhat. It also will require some correction
of errors.

Don

On Wed, Nov 29, 2017 at 9:37 AM, Christopher Schultz <

Post by Christopher Schultz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Don,

Post by Christopher Schultz
In fact, I think you are using PEM-encoded DER files and not a
packaged keystore, even though your SSLHostConfig's
keystoreType is set to "PKCS12".

Yes, I am using PEM files. Got to read more on DER files.

PEM is an encoding, while DER is really the file format. It's like
saying "is this file text/plain or UTF-8?"
This is a great read for almost anyone who cares about x509 certificates
https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs-ce
r-vs-pem-certificates-and-how-to-convert-them

Post by Don Flinn
So do I just drop the keystoreType="PKCS12" from the connector?

Theoretically, yes. The keystoreType is only used when there is a
keystore and not "certificate files", etc.

Post by Christopher Schultz
If there's anything inaccurate on the Tomcat site

Agreed. Would you care to write some new documentation and/or prepare
a patch for the site? IT's usually best when beginners write for their
own audience. I, for example, understand it backwards and forwards so
when I write I have a skewed perspective. Writing as a beginner can
re-focus the narrative for a different audience.
If you need any help grabbing the site from svn, etc. please just ask.

Post by Don Flinn
Thanks for your patience and help.

https://blogs.apache.org/foundation/entry/asf_15_community_over_code
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloexiYdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFiY1Q//SLRGAzEuc2QzyvK9
svCG+s0HKA1QY+ubtdmoy+czFtm1b857uQ6L0Zo8KCp+edzYvTyd7iupGjPngEqr
5B9qRV3bcu3jsvMUcXEFe779MjjKsSX+m0jF8/9A1RtOvtEqqemlC6Q5AVuSZZUf
usSrTjXV2XyVlEtv0J5Rw+hMtLUpRwppg1LKAX5ZflHdhA1Zdq+TH6NSbLQlPr1z
WRzpLuOfSpt6Cnx2Kfqcwgop0EqCyPFcIqC3o2V+ONDQh4Z7FOdUNn70O03ympDg
fRMZbo8o0mX6RyjSk0nDFEfXLv2lafPoOrE5OUMvnuN4bZ472Jpq3nDtl0ZwYSIy
IcjXnfw+NUNTcIkJVz0K009/K/U8U4O4NBm5IBW4uFa2yapx717pB8H/Fmr6LvEr
FuIZG6wODc7YtN3kqbHR8J/3N1n3q6SM3CXyyjfazN0Kur0e4FOIE5WagzZTwQSm
K7LJsuIu84sVEShPcTB2CvTsaawJQj7clCM+eZngejuvuxSiwiC0u0zWKfoPDD8Z
bbXY69RJ0F1iKw7rgj+tr1KOxoNaDyHV8ys7CKinuG32hb37qzntygLrGZ0ZPOQZ
pUTuSsm1Zn/Zd/3oLWIhXJ9UZA5OfwhYYt6YwaTo4JYLhB1IsiVl9qqdzo2CQLIY
UHuG7kdiTBEig/ej+/RBOLZSI0k=
=6iU6
-----END PGP SIGNATURE-----
---------------------------------------------------------------------

Christopher Schultz

2017-12-01 16:32:18 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Don,

Post by Don Flinn
I'll be happy to accept your challenge to try to write some
documentation for the site from a newbee's point of view. It will
be on the slow side as my 'day job' will interfere somewhat. It
also will require some correction of errors.

No problem at all. Just reach-out to the group if you need any
hand-holding.

- -chris

Post by Don Flinn
On Wed, Nov 29, 2017 at 9:37 AM, Christopher Schultz <
Don,

Post by Christopher Schultz
In fact, I think you are using PEM-encoded DER files and
not a packaged keystore, even though your
SSLHostConfig's keystoreType is set to "PKCS12".

Yes, I am using PEM files. Got to read more on DER files.

PEM is an encoding, while DER is really the file format. It's like
saying "is this file text/plain or UTF-8?"
This is a great read for almost anyone who cares about x509
https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs-

ce
r-vs-pem-certificates-and-how-to-convert-them

Post by Don Flinn
So do I just drop the keystoreType="PKCS12" from the
connector?

Theoretically, yes. The keystoreType is only used when there is a
keystore and not "certificate files", etc.

Post by Christopher Schultz
If there's anything inaccurate on the Tomcat site

Mark has given a number of presentations on TLS and they are very
accessible. Have a look at the slides (and some audio/video) on
the "presentations" page on the Tomcat site. Each of them has a
varying level of "introductoryness", but I think the more recent
ones like "Introduction to Tomcat and TLS" from TomcatCon in Miami
are probably the best ones to see for beginners.

Post by Don Flinn
Your e-mail has been very helpful, not only to me, but I
believe to others. With respect to the Tomcat site, I think
a lot of what you wrote would be very helpful there. For
example, the Tomcat write up on SSL describes how to do self
signed certificates and fleetingly mentions that if you have
a certificate from a CA that you could use e.g. openssl and
then refers the reader to their java documentation and
openssl documentation. Not too helpful to the
security/Tomcat novice.

Agreed. Would you care to write some new documentation and/or
prepare a patch for the site? IT's usually best when beginners
write for their own audience. I, for example, understand it
backwards and forwards so when I write I have a skewed perspective.
Writing as a beginner can re-focus the narrative for a different
audience.
If you need any help grabbing the site from svn, etc. please just ask.

Post by Don Flinn
Thanks for your patience and help.

https://blogs.apache.org/foundation/entry/asf_15_community_over_code
-chris

Post by Christopher Schultz
---------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlohhBIdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjrXxAApjseUCOZqro7Hutg
qXYaLdy6KD4ws4A5abYWnCMHvgO2oJxfxXAxnM5YNDgVgPR3r579ZF/zjLBsdYbx
kANY/4bMNse3LkJCkrwy1PclAyWDAMHVLIcc4iKEHL0dsCyGp7qIXHfx4eKv3Jnb
h4wsaoCi7QVk2TUOecOKKEiWRQ2tV1B6W4pAhCACAd0OSG/vYqdxVP2xzPE4AFe9
vaIi5VwHNU+o/yYMhc5Qy5b+rHs7d1xNS0hr1jiJ4amzNfKUaUTjVAl1U9u9mZb7
FI3sOIuEvtmXoBEfjWgohFC9XW2lS/EiQKptPT0HzLPUDfNXWi9QD9Ii1OI3sTMH
mw57kST/uz68S4MEiP4os/Cr4O0gnXSzc2uHQQHdqvsOBHbNnBAO9doL07lLzc8B
nktNwbl7G4aAp463gL6H8wk+pRQTUXTnm/oxTtROTF/TYaoYTpcsLdBB0PvMFV0N
lpasDBNvIu+4AR6kv8/i1oqjhcAfL3Y8c8H7Av2nF7/HPOwqhbs15CV9DJLPxoKx
rZh+MwSoAepx19fsWn+i4rYwUHjjka/BSbumTlkQYGlIhOkpSCjnX6l4tgneTOUG
aX82hHfzROxAqHj8DxXtJ3axZJ4kPewQIIJbJqk685YsRrCj0DR4QdAZsx/ntpY3
pDS0b1ShEv1e9EdMTlojrYMTy78=
=+sZ1
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

Don Flinn

2017-12-04 01:49:27 UTC

Chris,

Attached is a first cut at setting up SSL for Tomcat. It is in MicroSoft
Word. Hopefully people have that. If not I'll send it in another format
that is acceptable.

I tried to achieve a balance between completeness and brevity by only going
deep enough to give the reader enough information to understand what is
needed to use SSL/TLS with Tomcat. When it got down to keystore I
effectively just repeated what was on the Tomcat SSL website. A weak point
in the writeup (among many others) is getting Tomcat to listen on port 80
for letsencrpy.

If this might be useful please comment and correct.

Don

On Fri, Dec 1, 2017 at 11:32 AM, Christopher Schultz <

Post by Christopher Schultz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Don,

No problem at all. Just reach-out to the group if you need any
hand-holding.
- -chris

Post by Don Flinn
On Wed, Nov 29, 2017 at 9:37 AM, Christopher Schultz <
Don,

Post by Christopher Schultz
In fact, I think you are using PEM-encoded DER files and
not a packaged keystore, even though your
SSLHostConfig's keystoreType is set to "PKCS12".

Yes, I am using PEM files. Got to read more on DER files.

ce
r-vs-pem-certificates-and-how-to-convert-them

Post by Don Flinn
So do I just drop the keystoreType="PKCS12" from the
connector?

Theoretically, yes. The keystoreType is only used when there is a
keystore and not "certificate files", etc.

Post by Christopher Schultz
If there's anything inaccurate on the Tomcat site

Mark has given a number of presentations on TLS and they are very
accessible. Have a look at the slides (and some audio/video) on
the "presentations" page on the Tomcat site. Each of them has a
varying level of "introductoryness", but I think the more recent
ones like "Introduction to Tomcat and TLS" from TomcatCon in Miami
are probably the best ones to see for beginners.

Post by Don Flinn
Your e-mail has been very helpful, not only to me, but I
believe to others. With respect to the Tomcat site, I think
a lot of what you wrote would be very helpful there. For
example, the Tomcat write up on SSL describes how to do self
signed certificates and fleetingly mentions that if you have
a certificate from a CA that you could use e.g. openssl and
then refers the reader to their java documentation and
openssl documentation. Not too helpful to the
security/Tomcat novice.

Agreed. Would you care to write some new documentation and/or
prepare a patch for the site? IT's usually best when beginners
write for their own audience. I, for example, understand it
backwards and forwards so when I write I have a skewed perspective.
Writing as a beginner can re-focus the narrative for a different
audience.
If you need any help grabbing the site from svn, etc. please just ask.

Post by Don Flinn
Thanks for your patience and help.

https://blogs.apache.org/foundation/entry/asf_15_community_over_code
-chris

Post by Christopher Schultz
---------------------------------------------------------------------

Caldarale, Charles R

2017-12-04 02:13:07 UTC

Subject: Re: Trying to understand How Tomcat uses Keystore for SSL
Attached is a first cut at setting up SSL for Tomcat. It is in MicroSoft

Word.

Most attachments are automatically stripped by the mailing list server. You
can either send it in plain text or post it somewhere publicly accessible.

- Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.

Don Flinn

2017-12-04 03:07:29 UTC

This post might be inappropriate. Click to display it.

Christopher Schultz

2017-12-04 19:06:11 UTC

Nicolas Therrien

2017-12-04 19:20:41 UTC

Post by Caldarale, Charles R

" Asymmetric encryption uses a public and a

private encryption key. The public key, which as its name states, is
public, i.e. it is available to all. The private key is and must be
closely guarded. A message encrypted with the private key can be
decrypted by the public key and vis-a-versa."

This is not true.

The principle of asymmetric encryption is based on the fact that this is a one-way communication channel. Only the public key can encrypt data, and only the private key can decrypt data.

This is not reversible. The private key cannot be used to encrypt and the public key cannot be used to decrypt.

This is why it is called asymmetric, as opposed to symmetric where both ends can both encrypt and decrypt.

Of course this text would require some rewrite, but in my opinion I think that, once fixed, the text would be useful and welcome. I give a lot of training about encryption and SSL within my company and I think there is not enough "end-to-end" articles on the subject. SSL implies a lot of complex concepts all put together so, yes, it is hard and it deserves additional vulgarization.

You can send me updates of your text if you need a reviewer.

Nicolas Therrien ing.
Senior Software Engineer

Airbus DS Communications
home of VESTA®
200 Boul. de la Technologie, Suite 300
Gatineau, QC J8Z 3H6
Canada
819.931.2139 (DIRECT)
www.Airbus-DSComm.com

-----Original Message-----
From: Christopher Schultz [mailto:***@christopherschultz.net]
Sent: Monday, December 4, 2017 2:06 PM
To: ***@tomcat.apache.org
Subject: Re: Trying to understand How Tomcat uses Keystore for SSL

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Don,

I haven't really read this, yet, but my first impression is that it provides a lot of background that we have tried NOT to repeat on the Tomcat site. The world doesn't need "another TLS background page."

As a beginning user, what would you think about having to be sent to other "background resources" before reading the Tomcat documentation?
I'd prefer not to "re-write the wheel", if you know what I mean.

- -chris

Thanks Chuck
In plain text
Please comment on the following write-up.
Setting Up SSL for TomCat 1) Overview of Security for Tomcat
Security is hard, which by extension means setting up SSL is hard.
One of the things that make this difficult is that there are multiple
layers of specifications. In this explanation we are only go as deep
into the technical description as is necessary for you to understand
what is going on.
At the bottom layer of security is cryptography, which is based on
encryption. We won’t go into encryption except to say that all
encryption protocols are breakable, except the One Time Pad, which is
impracticable. The principal of computer security is to make it very
difficult to break the encryption. Using a modern desktop computer it
would take a little over 6.4 quadrillion years to crack the encryption
of a 2048 bit RSA certificate. Note: practical quantum computers
large enough to negate this time estimate don't exist, yet
There are two encryption schemes that are of interest, asymmetric and
symmetric encryption. Asymmetric encryption uses a public and a
private encryption key. The public key, which as its name states, is
public, i.e. it is available to all. The private key is and must be
closely guarded. A message encrypted with the private key can be
decrypted by the public key and vis-a-versa.
SSL or Secure Sockets Layer, is the high level security layer that we
are attempting to implement for for our implementation of Tomcat. SSL
uses both asymmetric and symmetric encryption, but at the level we are
interested in we only deal with the former, while Tomcat and the other
parties like the browser deal with both.
In the scenario that we are addressing there are three parties
involved * your installation of Tomcat * the browser with whom you
wish to communicate and * the Certificate Authority or CA, e.g.
letsencrypt, Comodo, etc.
In cryptography, a certificate authority or certification authority
(CA) is an entity that issues digital certificates. A digital
certificate certifies the ownership of a public key by the named
subject of the certificate. This allows others (relying parties) to
rely upon signatures or on assertions made about the private key that
corresponds to the certified public key. A CA acts as a trusted third
party—trusted both by the subject (owner) of the certificate and by
the party relying upon the certificate. The format of these
certificates is specified by the X.509 standard.
In order to set up SSL, you want to get a private/public key pair and
what is called a Security Certificate or more properly, an X509
certificate. The Security Certificate contains information about who
you are and is attested to by the CA, whom the browser trusts.
In some cases, like the CA letsencrypt, the trust of the CA by all
browser is not yet there, so the certificate contains an intermediate
CA whom the browsers trust and who attests for the CA who trusts your
domain. Each of the CA's, the root CA, who trusts us and intermediate
who trusts the root CA, digitally sign (another
specification) the certificate with their private keys, so that the
browsers and other interested parties can verify the subject of the
certificate. This is accomplished by using the CA's public key to
assure that this certificate was signed by the root or intermediate CA
with their private key.
The certificates and keys have specified binary structures so that
they can be machine read. This structure is defined by using an
abstract notation called ASN.1, Abstract Syntax Notation One, which
defines data types in a binary format. A subset of ASN.1, BER defines
how to encode each value type. BER has more than one way to encode a
data type, so there is DER, which gives a unique encoding to each of
the BER data types.
A DER encoded certificate is an encoded binary form of the
certificate. Binary data can not be sent over the internet, so for
transportation they are base64 encoded, which transforms the binary
bits into ASCII, which can then be sent over the internet. Note
base64 is not human readable but is NOT encryption. Encoding and
decoding can be done using a well known algorithm. In essence PEM
files are just base64 encoded versions of the DER encoded data.
Before we leave this section there is another distinction. We use the
term SSL, Secure Sockets Layer. SSL has been replaced by TLS,
Transport Layer Security. TLS is more secure than SSL, which is
affectedly dead. The bad guys are continually working to break
security, whereas the good guys are working to beat the bad guys.
Consequently, for a secure system you must continually upgrade to the
latest security protocols. 2) How to Create and See what You Have
There is an open source set of commands called openssl which will
allow you to look inside the various certificates and keys
that you have as well as other functionality. You can download
openssl at https://www.openssl.org/source/ . Openssl comes as a
set of command line functions and an API.
Some of the common openssl commands that you might use are (reproduced
#### Generate RSA private key (2048 bit) openssl genrsa -out
private.pem 2048
#### Generate a Certificate Signing Request (CSR) openssl req
-sha256 -new -key private.pem -out csr.pem
#### Generate RSA private key (2048 bit) and a Certificate Signing
Request (CSR) with a single command openssl req -new -newkey
rsa:2048 -nodes -keyout server.key -out server.csr
#### Convert private key to PEM format openssl rsa -in server.key
-outform PEM -out server.pem
#### Generate a self-signed certificate that is valid for a year with
sha256 hash openssl x509 -req -sha256 -days 365 -in csr.pem -signkey
private.pem -out certificate.pem
#### View details of a RSA private key openssl rsa -in private.pem
-text -noout
#### View details of a CSR openssl req -in csr.pem -text -noout
#### View details of a Certificate openssl x509 -in certificate.pem
-text -noout
#### View details of a Certificate in DER format openssl x509 -inform
der -in certificate.cer -text -noout
#### Convert a DER file (.crt .cer .der) to PEM openssl x509 -inform
der -in certificate.cer -out certificate.pem
#### Convert a PEM file to DER openssl x509 -outform der -in
certificate.pem -out certificate.cer An example of using an openssl
-----BEGIN CERTIFICATE-----
MIIFAzCCA+ugAwIBAgISA+3lA2/GXmArkvSKMxVexUebMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xNzExMjYwNDM2MDBaFw0x
<more data>
-----END CERTIFICATE-----
Running the openssl command openssl x509 -in <certificate file> -text
-noout displays information such as the following abbreviated
03:ed:e5:03:6f:c6:5e:60:2b:92:f4:8a:33:15:5e:c5:47:9b Signature
Algorithm: sha256WithRSAEncryption Issuer: C=US, O=Let's Encrypt,
CN=Let's Encrypt Authority X3 Validity Not Before: Nov 26 04:36:00
2017 GMT Not After : Feb 24 04:36:00 2018 GMT Subject: CN=<your
<skipped data>
Authority Information Access: OCSP -
URI:http://ocsp.int-x3.letsencrypt.org CA Issuers -
URI:http://cert.int-x3.letsencrypt.org/
X509v3 Subject Alternative Name: DNS:<your domain name> X509v3
1.3.6.1.4.1.44947.1.1.1 CPS: http://cps.letsencrypt.org User
Notice: Explicit Text: This Certificate may only be relied upon by
Rely
Signature Algorithm: sha256WithRSAEncryption <skipped signature
information>
Looking at the above you can see that the certificate contains * the
public key; * who issued the certificate; * to whom the certificate
was issued, * <your domain>; * when the certificate is valid and * the
digital signature of the certificate. (Yet another
specification)
There is another tool that comes with your java implementation called
keystore. The java keystore is installed with your implementation of
Java. Specifically, the jdk<version>/bin directory contains an
executable called keytool. Using keytool you can construct a file
database called keystore and operate on and use that database for
setting up SSL for Tomcat.
For example, common keytool commands are: * Generate a Java keystore
and key pair keytool -genkey -alias mydomain -keyalg RSA -keystore
keystore.jks -keysize 2048 * Generate a certificate signing request
(CSR) for an existing Java keystore keytool -certreq -alias mydomain
-keystore keystore.jks -file mydomain.csr
* Import a root or intermediate CA certificate to an existing Java
keystore keytool -import -trustcacerts -alias root -file Thawte.crt
-keystore keystore.jks * Import a signed primary certificate to an
existing Java keystore keytool -import -trustcacerts -alias mydomain
-file mydomain.crt -keystore keystore.jks * Generate a keystore and
self-signed certificate (see How to Create a Self Signed Certificate
using Java Keytool for more info) keytool -genkey -keyalg RSA -alias
selfsigned -keystore keystore.jks -storepass password -validity 360
-keysize 2048 * Check a stand-alone certificate keytool -printcert -v
-file mydomain.crt * Check which certificates are in a Java keystore
keytool -list -v -keystore keystore.jks * Check a particular keystore
entry using an alias keytool -list -v -keystore keystore.jks -alias
mydomain * Delete a certificate from a Java Keytool keystore keytool
-delete -alias mydomain -keystore keystore.jks * Change a Java
keystore password keytool -storepasswd -new new_storepass -keystore
keystore.jks * Export a certificate from a keystore keytool -export
-alias mydomain -file mydomain.crt -keystore keystore.jks * List
Trusted CA Certs keytool -list -v -keystore
$JAVA_HOME/jre/lib/security/cacerts * Import New CA into Trusted Certs
keytool -import -trustcacerts -file /path/to/ca/ca.pem -alias CA_ALIAS
-keystore $JAVA_HOME/jre/lib/security/cacerts
3) Trust
There are various levels of trust – Browsers trust certain CAs, the
CAs trust various domains and you trust certain CAs.
All browsers contain a list of CAs with whom they have established
trust. You can examine this list by reading the documentation of a
particular browser. This trust establishment is between the browser
and the CA. You, in turn, trust that the browser has indeed
faithfully established that trust.
The CA establishes trust in your domain. Different CAs use different
methods for establishing that trust and charge you depending on the
the method of establishing that trust. For example letsencrypt
certificates are free whereas Verisign Secure Site Pro costs $1,199
per year. Note: Semantic bought Verisign's identity and
authentication security business. Chrome plans to drop Semantic
certificates in 2018. Again, keep aware of what is
happening in the security world. Its up to you to establish and
maintain trust in the CA you choose.
Some CAs use an intermediate CA, which is trusted by the browser to
cross sign their certificates. In this case the browser trusts the
intermediate and the intermediate trusts your CA, who trusts your
domain. The establishment of the browser CA trust is out of your
control, with the caution that you keep up with the literature and
reports on these relationships as noted above.
CAs use various means of establishing trust in your domain, from
personal inspection to some digital check, to confirm that you have
legitimate control of the domain and charge you accordingly.
4) Obtaining the Certificate
There are three steps in obtaining a certificate 1. Create a public
private key pair 2. Create and send a request to the CA, called a
Certificate Signing Request or CSR 3. Prove to the CA that you
own/control domain for the request
You create the key pair using openssl or using the java keystore as
shown in the commands above. You then create a CSR and digitally sign
it with your private key. The CSR contains information about your
company and your public key. The CSR may also contain other
information to prove your identity and/or the CA may contact you for
further information. For example, letsencrypt sends you a unique
token which you place in <your
domain>/.well-known/acme-challenge. If letsencrypt can retrieve
that token, it is proof that you control the domain. .The CA of your
choice may have tools that you can use to obtain a certificate. Note
that you must make your domain available to a call to your domain.
Since the call will be to port 80 and Tomcat normally runs on port
8080 you must transfer the port 80 call to Tomcat. One way is to set
Tomcat to run on port 80. Another way on Linux is to use iptables. On
windows use netsh. Chrome’s distrust of Symantic’s Extended Value
Certificates is based on what Google called sloppiness in validating
their clients when requesting certificates. 5) Securing Tomcat
Once you have your certificate, you set up Tomcat to use that
certificate. Here you can use keystore or PKCS12. In either case you
want to import your certificate chain as follows: 1. Your certificate
2. Intermediate certificates (if applicable) 3. Root certificate
Tomcat currently operates only on JKS, PKCS11 or PKCS12 format
keystores. The JKS format is Java's standard "Java KeyStore"
format, and is the format created by the keytool command-line utility.
This tool is included in the JDK. The PKCS12 format is an internet
standard, and can be manipulated via (among other things) OpenSSL and
Microsoft's Key-Manager. 6) Using PKCS12 Using Tomcat greater than
version 8.5 you can directly use the PKCS12 files created by openssl.
First edit the <Catelina>/config/server.xml> as follows: <Connector
protocol="org.apache.coyote.http11.Http11NioProtocol" port="8443"
maxThreads="150" SSLEnabled="true"> <SSLHostConfig> <Certificate
certificateKeyFile= “<path to your key file> certificateFile=<path to
your domain-chain.crt > certificateChainFile=<path to the root.crt >
type="RSA" /> </SSLHostConfig> </Connector> The domain-chain.crt is
that returned by your CA. Use openssl to
examine what is in the domain-chain.crt. First cat the file to
see how many certificates it contains. You can identify a
certificate by the opening clear text -----BEGIN CERTIFICATE----- and
the end by -----END CERTIFICATE----- with base64 data encoded data in
between. If you have more than one certificate run the openssl
command as described above in the section How to Create on each
certificate to see what it contains. If there is a second certificate
it may contain the intermediate information. As for the root
certificate, the CA may download it to you as part of the response to
the csr or you may have to get it separately from the CA’s site. The
CA document will tell you what you should get.
You will also have to edit web.xnl as follows: Edit web.xml Add a
security-constraint to web.xml for the subdirectories that you wish to
protect with SSS. <web-app> ... <security-constraint>
<web-resource-collection> <web-resource-name>Subdirectories you wish
to protect</web-resource-name> <url-pattern>/*</url-pattern>
</web-resource-collection> <user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint> </security-constraint> </web-app> The
url-pattern in the example means all the directories under the
subdirectories in webapps chosen for protection. Setting the
transport- guarantee to NONE turns off security. 7) Using keystore
Each entry in a keystore is identified by an alias string. While many
keystore implementations treat aliases in a case insensitive manner,
case sensitive implementations are available. The PKCS11
specification, for example, requires that aliases are case sensitive.
To avoid issues related to the case sensitivity of aliases, it is not
recommended to use aliases that differ only in case. Use the JKS
format create a keystore as follows: keytool -import -trustcacerts
-alias mydomain -file mydomain.crt -keystore keystore.jks keytool
-import -trustcacerts -alias root -file <intermediate crt) -keystore
keystore.jks (if applicable and may be multiple intermediates)
keytool -import -trustcacerts -alias root -file (root.crt) -keystore
keystore.jks 8) Edit the Tomcat Configuration File Tomcat can use
three different implementations of SSL: * JSSE implementation provided
as part of the Java runtime
* JSSE implementation that uses OpenSSL * APR implementation, which
uses the OpenSSL engine by default The exact configuration details
depend on which implementation is being used. If you configured
Connector by specifying generic protocol="HTTP/1.1"then the
implementation used by Tomcat is chosen automatically. If the
installation uses APR - i.e. you have installed the Tomcat native
library - then it will use the JSSE OpenSSL implementation, otherwise
it will use the Java JSSE implementation. Auto-selection of
implementation can be avoided if needed. It is done by specifying a
classname in the protocol attribute of the Connector.
To define a Java (JSSE) connector, regardless of whether the APR
library is loaded or not, use one of the following: 
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementat

ion"
port="8443" .../>

<Connector
protocol="org.apache.coyote.http11.Http11Nio2Protocol"
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementat

ion"
port="8443" .../>

The OpenSSL JSSE implementation can also be configured explicitly if
needed. If the APR library is installed (as for using the APR
connector), using the sslImplementationName attribute allows enabling
it. When using the OpenSSL JSSE implementation, the configuration can
use either the JSSE attributes or the OpenSSL attributes (as used for
the APR connector), but must not mix attributes from both types in the
same SSLHostConfig or Connector element. 
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol" port="8443"
sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImple

mentation"
.../>

Alternatively, to specify an APR connector (the APR library must be
available) use:  <Connector
protocol="org.apache.coyote.http11.Http11AprProtocol" port="8443"
.../> If you are using APR or JSSE OpenSSL, you have the option of
configuring an alternative engine to OpenSSL. <Listener
className="org.apache.catalina.core.AprLifecycleListener"
SSLEngine="someengine" SSLRandomSeed="somedevice" /> The default value
is <Listener className="org.apache.catalina.core.AprLifecycleListener"
SSLEngine="on" SSLRandomSeed="builtin" /> Also the useAprConnector
attribute may be used to have Tomcat default to using the APR
connector rather than the NIO connector: <Listener
className="org.apache.catalina.core.AprLifecycleListener"
useAprConnector="true" SSLEngine="on" SSLRandomSeed="builtin" /> So to
enable OpenSSL, make sure the SSLEngine attribute is set to something
other than off. The default value is on and if you specify another
value, it has to be a valid OpenSSL engine name.
SSLRandomSeed allows specifying a source of entropy. Productive system
needs a reliable source of entropy but entropy may need a lot of time
to be collected therefore test systems could use no blocking entropy
sources like "/dev/urandom" that will allow quicker starts of Tomcat.
The final step is to configure two files in Tomcat - the Connector in
the $CATALINA_BASE/conf/server.xml file, where $CATALINA_BASE
represents the base directory for the Tomcat instance and the web.xml
file. An example <Connector> element for an SSL connector is included
in the default server.xml file installed with Tomcat. To configure an
SSL connector that uses JSSE, you will need to remove the comments and
edit it so it looks something like this:  <Connector
protocol="org.apache.coyote.http11.Http11NioProtocol" port="8443"
maxThreads="200" scheme="https" secure="true" SSLEnabled="true"
keystoreFile="${user.home}/.keystore" keystorePass="changeit"
clientAuth="false" sslProtocol="TLS"/> Note: If tomcat-native is
installed, the configuration will use JSSE with an OpenSSL
implementation, which supports either this configuration or the APR
configuration example given below. The APR connector uses different
attributes for many SSL settings, particularly keys and certificates.
An example of an APR configuration is:  <Connector
protocol="org.apache.coyote.http11.Http11AprProtocol" port="8443"
maxThreads="200" scheme="https" secure="true" SSLEnabled="true"
SSLCertificateFile="/usr/local/ssl/server.crt"
SSLCertificateKeyFile="/usr/local/ssl/server.pem"
SSLVerifyClient="optional" SSLProtocol="TLSv1+TLSv1.1+TLSv1.2"/>
The configuration options and information on which attributes are
mandatory, are documented in the SSL Support section of the HTTP
connectorconfiguration reference. Make sure that you use the correct
attributes for the connector you are using. The NIO and
NIO2 connectors use JSSE unless the JSSE OpenSSL implementation is
installed (in which case it supports either the JSSE or OpenSSL
configuration styles), whereas the APR/native connector uses APR.
The port attribute is the TCP/IP port number on which Tomcat will
listen for secure connections. You can change this to any port number
you wish (such as to the default port for https communications, which
is 443). However, special setup (outside the scope of this document)
is necessary to run Tomcat on port numbers lower than 1024 on many
operating systems. If you change the port number here, you should also
change the value specified for the redirectPort attribute on the
non-SSL connector. This allows Tomcat to automatically redirect users
who attempt to access a page with a security constraint specifying
that SSL is required, as required by the Servlet Specification. After
completing these configuration changes, you must restart Tomcat as you
normally do, and you should be in business. You should be able to
https://localhost:8443/ and you should see the usual Tomcat splash
page (unless you have modified the ROOT web application). If this does
not work, the following section contains some troubleshooting tips.
Edit web.xml as described above. 9) Installing a Certificate from a
Certificate Authority To obtain and install a Certificate from a
Certificate Authority (like verisign.com, thawte.com or
trustcenter.de), read the previous section and then follow these
instructions: 10) Create a local Certificate Signing Request (CSR)
In order to obtain a Certificate from the Certificate Authority of
your choice you have to create a Certificate Signing Request (CSR).
That CSR will be used by the Certificate Authority to create a
Certificate that will identify your website as "secure". To create a
CSR follow these steps: * Create a local self-signed Certificate (as
described in the previous section): * keytool -genkey -alias tomcat
-keyalg RSA -keystore <your_keystore_filename> Note: In some cases you
will have to enter the domain of your website (i.e.
www.myside.org) in the field "first- and lastname" in order to create
a working Certificate. * The CSR is then created with: * keytool
-certreq -keyalg RSA -alias tomcat -file certreq.csr -keystore
<your_keystore_filename> Now you have a file called certreq.csr that
you can submit to the Certificate Authority (look at the documentation
of the Certificate Authority website on how to do this). In return you
get a Certificate. 11) Importing the Certificate Now that you have
your Certificate you can import it into you local keystore. First of
all you have to import a so called Chain Certificate or Root
Certificate into your keystore.
After that you can proceed with importing your Certificate. * Download
a Chain Certificate from the Certificate Authority you obtained the
http://www.verisign.com/support/install/intermediate.html For
http://www.verisign.com/support/verisign-intermediate-ca/Trial_Secure_

Server_Root/index.html

http://www.trustcenter.de/certservices/cacerts/en/en.htm#server For
Thawte.com go to: http://www.thawte.com/certs/trustmap.html * Import
the Chain Certificate into your keystore * keytool -import -alias root
-keystore <your_keystore_filename> -trustcacerts -file
<filename_of_the_chain_certificate> * And finally import your new
Certificate * keytool -import -alias tomcat -keystore
<your_keystore_filename> -file <your_certificate_filename>
Restart Tomcat and run a test case.
12) References
Applied Cryptography (Second Edition) Bruce Schneier 1996 Old but
still a great book for learning the details of cryptography. Long at
758 pages
A Layman's Guide to a Subset of ASN.1, BER, and DER Burton S.
Kaliski Jr. Revised November 1, 1993
http://luca.ntop.org/Teaching/Appunti/asn1.html A layman's
introduction to a subset of OSI's Abstract Syntax Notation One
(ASN.1), Basic Encoding Rules (BER), and Distinguished Encoding Rules (DER).
Festy Duck OpenSSL Cookbook by Ivan Risti?
https://www.feistyduck.com/library/openssl-cookbook/ Free download of
a detailed description of all aspects of OpenSSL
On Sun, Dec 3, 2017 at 9:13 PM, Caldarale, Charles R <

Post by Nicolas Therrien
understand How Tomcat uses Keystore for SSL
Attached is a first cut at setting up SSL for Tomcat. It is in MicroSoft

Word.
Most attachments are automatically stripped by the mailing list
server. You can either send it in plain text or post it somewhere
publicly accessible.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
PROPRIETARY MATERIAL and is thus for use only by the intended
recipient. If you received this in error, please contact the sender
and delete the e-mail and its attachments from all computers.

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlolnKMACgkQHPApP6U8
pFhMXA//eLF8ePwsz806EN3y6QTmBskcZwMjW9nrBySkP0dpgcmA0rgL/LAKh9Ns
FnBJ+3RyleVhizER/I03G1f96G5rWFPsmkq+GFfWY9q3IaH/RRH+nUAhlBwgdqMI
cMttUPjMKpc+AdF0PNKhO94DRz3K+7EtRb2ETv6JxC7K3Xq/cWaBKzBrOBpMDuRP
lkc62SV2DS/SDvpij8pzmKu9H7dcwvGQEOHJBBeG4DYMQFaUczw/YyfwpPye9ltb
qxN3gFT6GjYkInf4df+K38TxdImMvnXKVolXTSaJdcl6XQCu4PWkuvSpJ8Pc0KAK
f2O4d0s4lvg4irsj9a8uOSdR/uNWgAZtNoYxlZ0wJgGkNt7fFy0TWeBhNaHqL55/
5b0H1kt3VpnfAgrTi8c5xdvDSjqJBN0wWIUTpvEQA7FuZkGpUsdlVA9JbhAyXF2s
JEHKOHYHLHxpvUCT/cMJKi62+8sXT+zJhE8a4Fkx0+Bu6NiYtaaNfTRQP9LqMTtn
688PKwaCSQj6KDOKG2E2ijyjAbKGPcwJ7eQ+yj+HGsJkDy932IXPIWN+j9Tadj0V
i+58qrIfXtlo/iGRf5qLuvxGgOzTWkafg6QNR6RSZMIPbNxlGmaxWDgztqZKDJY/
SGrdyj/j7TevcQ/nT+f2aKjMjXrAMrJlasRZuGE3JCurbRpJ94A=
=9m5U
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB��[��X��ܚX�KK[XZ[�\�\��][��X��ܚX�P�X�]�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[

Christopher Schultz

2017-12-04 19:30:04 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Nicolas,

Post by Nicolas Therrien
" Asymmetric encryption uses a public and a

private encryption key. The public key, which as its name
states, is public, i.e. it is available to all. The private key
is and must be closely guarded. A message encrypted with the
private key can be decrypted by the public key and vis-a-versa."

While you are right that "this is not reversible" you are incorrect
that the private key cannot be used to encrypt. In fact, the private
key MUST be used to encrypt. This is the foundation of the TLS handshake
.

Post by Nicolas Therrien
This is why it is called asymmetric, as opposed to symmetric where
both ends can both encrypt and decrypt.

No, it's called asymmetric because there are two keys involved instead
of a single key.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlolojsACgkQHPApP6U8
pFiG4Q/9Hd+pIZgD8OOGVwhuBxPJIttzdSrypDwNVbecz9K4PjBR0ECSc5eiwteb
TLn4lbI5Rgrf0DkCnUa8mdc4Ej3ZMpUBpWCJztk9dMHgRBNQgZ0xzq3M2eTmmpI2
Pk7dDpp0H5m2dDASbCYOYe2q/i8FP2VxJuqa0cg0gVLkonEusU2WgfkoAB6uNDCQ
imiEjK5KoqNlZCK5AZJzmEE0ekD/R1d+JmOMjteDwtk9yF5JFJIFf9mYrRbsUz1U
ViEpWlQ9U0NbJ4wk7zboSjkzgUJdigNCzpHkqGa7aAwJM+yNEIbYw4Ipe1csdI9K
R7rzvoqx9bgb1U3LS5SO81nzlhCM7/8jVWYp4uIT6FqotAJcufUZ8tGgPzRV7WAe
ofrdBkn8UOY0A7P6yQ5KVkx2ADbenVQBCAzwrjhsBKdzG63bloyrwtOcyQ3evXR0
59zpAnNVz4fwebXAeO0MatKjfJbpWYEPUFBXW2L/++Zw1tUDcxn2exdvwzrN1QLz
Q2oFgX3vrc7zl5USTYoE/rtfomG94vwMjYPsILBE/E95gLazfTFszZ6PmOGonFEP
SZ0IBsqdYpC/mvJ0yNK3yukS2XYFIR03+dujSGkOVeHZqNe7EDhZWztJxCpX+yaE
H9DcNR2nU79pT8LjKwkvq8r2JNOVPtLEa3qBGWLqmq47u6Wx5OQ=
=HcjO
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

Mark Thomas

2017-12-04 19:57:39 UTC

Post by Nicolas Therrien
" Asymmetric encryption uses a public and a

This is not true.

Yes, it is true.

Post by Nicolas Therrien
The principle of asymmetric encryption is based on the fact that this is a one-way communication channel. Only the public key can encrypt data, and only the private key can decrypt data.

The above statement is incorrect.

Post by Nicolas Therrien
This is not reversible. The private key cannot be used to encrypt and the public key cannot be used to decrypt.

So is the statement above.

Post by Nicolas Therrien
This is why it is called asymmetric, as opposed to symmetric where both ends can both encrypt and decrypt.

Nicolas Therrien

2017-12-04 20:04:22 UTC

Agreed. I was thinking in terms of the TLS exchange during which the client uses the public key to send a symmetric key to the server.

I should have read the text further and more literally. Sorry about the confusion.

Nicolas Therrien ing.
Senior Software Engineer

Airbus DS Communications
home of VESTA®
200 Boul. de la Technologie, Suite 300
Gatineau, QC J8Z 3H6
Canada
819.931.2139 (DIRECT)
www.Airbus-DSComm.com

-----Original Message-----
From: Mark Thomas [mailto:***@apache.org]
Sent: Monday, December 4, 2017 2:58 PM
To: ***@tomcat.apache.org
Subject: Re: Trying to understand How Tomcat uses Keystore for SSL

Post by Nicolas Therrien
" Asymmetric encryption uses a public and a

This is not true.

Yes, it is true.

The above statement is incorrect.

Post by Nicolas Therrien
This is not reversible. The private key cannot be used to encrypt and the public key cannot be used to decrypt.

So is the statement above.

Post by Nicolas Therrien
This is why it is called asymmetric, as opposed to symmetric where both ends can both encrypt and decrypt.

Again, no.

It is called asymmetric because whichever key you use to encrypt, you
must use the other key to decrypt.

In symmetric encryption there is a single key that encrypts and decrypts.

As an aside, encrypting with the private key and decrypting with the
public key is a key element of how digital signatures work.

I recommend viewing the "Introduction to Tomcat and TLS" presentation
from this page:
https://urldefense.proofpoint.com/v2/url?u=http-3A__tomcat.apache.org_presentations.html&d=DwICaQ&c=V9FsLrJ7wYRfgsJ_KHoq2BENyO08hg3hD97KYyc_QQg&r=ZZk8MXVrcZaLkCc_2C7UFhVW7Nb2LjIIa0VSNP2uvtnzxufjwl_gt-oLYrhgql55&m=-88nWY3ukSpK6pjmbNDfKWWcmr0DUrFdu3QQktOfMLI&s=rGi1lxExpzMxuwq6pykrS5RJosFgcea37gIQJyaFiCg&e=

It is a little simplistic, but it covers the basics.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB��[��X��ܚX�KK[XZ[�\�\��][��X��ܚX�P�X�]�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[

Nicolas Therrien

2017-11-14 21:40:35 UTC