You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by David Weisgerber <da...@ms-gmbh.de> on 2020/09/08 07:58:28 UTC
Truststore in HTTPS Connector does not work with Linux
Hi,
I have some weird problem or bug with the HTTPS Connector. In our product, that ships with tomcat we want to achieve the following:
There is one keystore where the customer puts its server certificate for HTTPs as well as (if intended) zero or one certificate for client authentication. The certificate for client authentication can be self-signed and the customer can setup its own certificate authority for this.
For this I put the following code for configuring the connector in the server.xml:
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true" bindOnInit="false"
clientAuth="false" sslProtocol="TLS" keystoreFile="/diagdata/keystore.jks" keystorePass="custo1234" keyAlias="main" truststoreFile="/diagdata/keystore.jks" truststorePassword="custo1234" />
(The real clientAuth is done in the deployed application because it is more complicated, I just need the feature to be enabled).
This gives me the following error:
org.apache.catalina.LifecycleException: Protocol handler start failed
<2> at org.apache.catalina.connector.Connector.startInternal(Connector.java:1038)
<2> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
<2> at org.apache.catalina.core.StandardService.startInternal(StandardService.java:438)
<2> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
<2> at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930)
<2> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
<2> at org.apache.catalina.startup.Catalina.start(Catalina.java:633)
<2> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
<2> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
<2> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
<2> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
<2> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
<2> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:478)
<2>Caused by: java.lang.IllegalArgumentException: the trustAnchors parameter must be non-empty
<2> at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:99)
<2> at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:71)
<2> at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:217)
<2> at org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1141)
<2> at org.apache.tomcat.util.net.AbstractEndpoint.start(AbstractEndpoint.java:1227)
<2> at org.apache.coyote.AbstractProtocol.start(AbstractProtocol.java:592)
<2> at org.apache.catalina.connector.Connector.startInternal(Connector.java:1035)
<2> ... 12 more
<2>Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
<2> at java.base/java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
<2> at java.base/java.security.cert.PKIXParameters.<init>(PKIXParameters.java:157)
<2> at java.base/java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:130)
<2> at org.apache.tomcat.util.net.SSLUtilBase.getParameters(SSLUtilBase.java:494)
<2> at org.apache.tomcat.util.net.SSLUtilBase.getTrustManagers(SSLUtilBase.java:425)
<2> at org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:247)
<2> at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:97)
<2> ... 18 more
The error goes away when I remove truststoreFile and truststorePassword.
Now comes the interesting part: The same configuration works under Windows (with other paths of course) using the Windows-Store as truststore for HTTPS connections to other servers. The same configuration worked with Tomcat 8.5.4 and the error just popped up from version 8.5.5. The error also seems not to be based on the java version, I tried it with Java 8 and Java 14. Under Windows we use Java 9...
Is this a Linux specific bug? What is a trust anchor anyway?
Thanks in advance,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Truststore in HTTPS Connector does not work with Linux
Posted by Daniel Savard <da...@gmail.com>.
Le jeu. 17 sept. 2020 à 11:31, David Weisgerber <da...@ms-gmbh.de>
a écrit :
> I think I was able to figure out the problem (more or less):
> Using two distinct keystores for trusted certificates and server keys
> solves the problem. But don't ask me why there is a difference between
> Windows and Linux on this topic.
> It also does not work to use an empty keystore (on Linux).
>
>
I have one setup among many where the trust and key stores are merged into
a single key store on Linux with Tomcat 8.5.x and it is working just fine.
I don't know why it doesn't work for you and I don't see any reason for
such a behavior.
Regards,
-----------------
Daniel Savard
Re: Truststore in HTTPS Connector does not work with Linux
Posted by Christopher Schultz <ch...@christopherschultz.net>.
David,
On 9/17/20 11:31, David Weisgerber wrote:
> I think I was able to figure out the problem (more or less):
>
> Using two distinct keystores for trusted certificates and server keys
> solves the problem. But don't ask me why there is a difference
> between Windows and Linux on this topic.
That *is* odd.
> It also does not work to use an empty keystore (on Linux).
That would never be expected to work, as the secure connector requires a
key to start successfully.
I think it's worth filing a bug to see if there is a way to get that
handled via Tomcat. There is no conceptual reason you should be unable
to use the same foostore as both keystore and truststore. It's just
uncommon because the keystore is usually considered a high-security
asset from a "read" perspective while the truststore should really only
be protected from a "write" perspective.
I never put trusted certificates into a keystore mostly because I don't
want to bugger-up my keystore and break the server itself. (I also
happen to hate keystores, but that's kind of beside the point.)
-chris
> -----Original Message-----
> From: David Weisgerber <da...@ms-gmbh.de>
> Sent: Thursday, 17 September 2020 09:29
> To: Tomcat Users List <us...@tomcat.apache.org>
> Subject: RE: Truststore in HTTPS Connector does not work with Linux
>
> Hi,
>
>> Ugh. That *does* point toward a bug in Tomcat itself or something odd with the JVM.
>
> Yep.
>
>>> No, we automatically ship the latest 8.5 tomcat version. However for
>>> our docker based distribution I was sure that this feature worked at
>>> some time (I think I used tomcat 8.0 for this). I tried it with the
>>> latest 8.5.57 on Windows, there everything works correctly. I just
>>> checked all the versions to see when the "bug"
>>> was introduced.
>
>> Did you find it? I took a quick look at the 8.5.x changelog and nothing jumped-out at me.
>
> I think it is
> Fix: Refactor the JSSE client certificate validation so that the effectiveness of the certificateVerificationDepth configuration attribute does not depend on the presence of a certificate revocation list. (markt) From the 8.5.5 changelog
>
> Shall I file a bug? Are there any other people that can confirm this? I guess client certificates is a more rarely used feature.
>
> Best regards,
> David
> B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB [ X ܚX KK[XZ[
> \ \ ][ X ܚX P X ]
> \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[
> \ \ Z[ X ]
> \X K ܙ B
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Truststore in HTTPS Connector does not work with Linux
Posted by David Weisgerber <da...@ms-gmbh.de>.
I think I was able to figure out the problem (more or less):
Using two distinct keystores for trusted certificates and server keys solves the problem. But don't ask me why there is a difference between Windows and Linux on this topic.
It also does not work to use an empty keystore (on Linux).
-----Original Message-----
From: David Weisgerber <da...@ms-gmbh.de>
Sent: Thursday, 17 September 2020 09:29
To: Tomcat Users List <us...@tomcat.apache.org>
Subject: RE: Truststore in HTTPS Connector does not work with Linux
Hi,
> Ugh. That *does* point toward a bug in Tomcat itself or something odd with the JVM.
Yep.
>> No, we automatically ship the latest 8.5 tomcat version. However for
>> our docker based distribution I was sure that this feature worked at
>> some time (I think I used tomcat 8.0 for this). I tried it with the
>> latest 8.5.57 on Windows, there everything works correctly. I just
>> checked all the versions to see when the "bug"
>> was introduced.
> Did you find it? I took a quick look at the 8.5.x changelog and nothing jumped-out at me.
I think it is
Fix: Refactor the JSSE client certificate validation so that the effectiveness of the certificateVerificationDepth configuration attribute does not depend on the presence of a certificate revocation list. (markt) From the 8.5.5 changelog
Shall I file a bug? Are there any other people that can confirm this? I guess client certificates is a more rarely used feature.
Best regards,
David
B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB [ X ܚX KK[XZ[
\ \ ][ X ܚX P X ]
\X K ܙ B ܈Y][ۘ[ [X[ K[XZ[
\ \ Z[ X ]
\X K ܙ B
RE: Truststore in HTTPS Connector does not work with Linux
Posted by David Weisgerber <da...@ms-gmbh.de>.
Hi,
> Ugh. That *does* point toward a bug in Tomcat itself or something odd with the JVM.
Yep.
>> No, we automatically ship the latest 8.5 tomcat version. However for
>> our docker based distribution I was sure that this feature worked at
>> some time (I think I used tomcat 8.0 for this). I tried it with the
>> latest 8.5.57 on Windows, there everything works correctly. I just
>> checked all the versions to see when the "bug"
>> was introduced.
> Did you find it? I took a quick look at the 8.5.x changelog and nothing jumped-out at me.
I think it is
Fix: Refactor the JSSE client certificate validation so that the effectiveness of the certificateVerificationDepth configuration attribute does not depend on the presence of a certificate revocation list. (markt)
From the 8.5.5 changelog
Shall I file a bug? Are there any other people that can confirm this? I guess client certificates is a more rarely used feature.
Best regards,
David
Re: Truststore in HTTPS Connector does not work with Linux
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
David,
On 9/9/20 02:46, David Weisgerber wrote:
> Hi Christopher,
>
>> This should be okay, though it is a little unusual to use the
>> same keystore for both "keys" and "trusted certs". Can you
>> confirm the contents + types of everything in the keystore?
>
> After your approach from the end of your response, I exported the
> certificate of main and stored it as dummy:
> root@d3bf84b82698:/diagdata# keytool -list -keystore keystore.jks
> Enter keystore password: Keystore type: PKCS12 Keystore provider:
> SUN
>
> Your keystore contains 2 entries
>
> dummy, Sep 9, 2020, trustedCertEntry, Certificate fingerprint
> (SHA-256):
> 07:C1:D4:06:AC:0E:55:C2:25:41:FE:0E:35:9D:9C:8C:03:42:E4:D2:AA:74:1E:0
E:21:11:3A:97:CE:A2:AD:22
>
>
main, Sep 8, 2020, PrivateKeyEntry,
> Certificate fingerprint (SHA-256):
> 07:C1:D4:06:AC:0E:55:C2:25:41:FE:0E:35:9D:9C:8C:03:42:E4:D2:AA:74:1E:0
E:21:11:3A:97:CE:A2:AD:22
>
>
root@d3bf84b82698:/diagdata#
>
> This gives me the same error message as before.
Ugh. That *does* point toward a bug in Tomcat itself or something odd
with the JVM.
>> Are you really using Tomcat 8.5.4 and 8.5.5? If so, you are like
>> 4 years out of date and there are published security
>> vulnerabilities affecting your Tomcat version. Can you try with
>> 8.5.latest which is currently 8.5.57?
>
> No, we automatically ship the latest 8.5 tomcat version. However
> for our docker based distribution I was sure that this feature
> worked at some time (I think I used tomcat 8.0 for this). I tried
> it with the latest 8.5.57 on Windows, there everything works
> correctly. I just checked all the versions to see when the "bug"
> was introduced.
Did you find it? I took a quick look at the 8.5.x changelog and
nothing jumped-out at me.
>>> Is this a Linux specific bug?
>
>> That would be unusual, but certainly possible. Are you *sure*
>> this works with no other changes other than:
>>
>> 1. Switching to Windows or 2. Switching to Tomcat 8.5.4?
>>
>> My guess is that the keystore is not bit-for-bit identical to
>> your Windows or Tomcat 8.5.4 environments.
>
> Yes, I copied the keystore that works for Windows and copied it to
> the docker test environment. The windows keystore gives me the
> same error message.
Rats. Thanks for confirming.
>> $ keytool -exportcert -alias 'www.example.com' -rfc -keystore
>> /diagdata/keystore.jks ====BEGIN CERTIFICATE===== blah blah blah
>> =====END CERTIFICATE=====
>>
>> $ keytool -importcert -alias 'dummy' -keystore
>> /diagdata/keystore.jks [paste cert here]
>
> I tried this but it did not help...
Grr. The good news is that the latest version does work, so it must
have been fixed at some point. :)
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9Yz04ACgkQHPApP6U8
pFhHBg//fZf2gI1jEa4r4aXeBOu+i1B2cSwUUChQACPWw6wVFf2KbP8K2XNpz3Dh
f3eEk1QQ8ApeZUDq2FfdT9twH4tTfzuYPJZF44Mzig/CNF9hR8VB18hGt+ezuIdk
pqGcoYECM6OnE2B1wKwFm18NZkyZ87XKXOgMCqjkApH/KgmzYgLnbSw7ZnoH9lZG
hhBYKS1pqcDOgfIbFgV7TS9LnooJlkr2f2IXzx5ohXeAbBQ7/uSWZJ3KmZa/eXIk
lquqCgluuPh21vlhhXDERS0I+Eogto8BNpIQZaRnjsv4SAXu4VnhV7RGB4n4RhjW
v9bowgAqR4El4UI+CXhE5UJnxAtmXQ3LvEyAtLQ53BEDNiLpHl1Gub/u14QDbHUW
3dXXGNhpWTB7TVm3ILmRFFQWLTmPFgMSwplWSB3Z9goHsshy6PgVTx/aUkPdUOLS
6f9A5pBAfG0PvaGxUEgfvvrMGX3uDYu9yFtnQmoX1ooDCOdGOvGWJDXpb6uf3Byg
n/vHSjpaFGqnNm9uRVcT01sqEt5sBBRO/m8oIQJK7sSV8kGojaYRTDlE0zOX0Ydd
E5h0B7sp4CKhfCLBH88/SUoP1V2/o5Z1VwyquqW6+UsmI/nsaopIe0A/jmT8eDcI
2YavTgS9OdKZRFYOeed1IzWU0VKsog2TWmJT5s7Vuj29SBHknP0=
=j+Ie
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Truststore in HTTPS Connector does not work with Linux
Posted by David Weisgerber <da...@ms-gmbh.de>.
Hi Christopher,
> This should be okay, though it is a little unusual to use the same keystore for both "keys" and "trusted certs".
> Can you confirm the contents + types of everything in the keystore?
After your approach from the end of your response, I exported the certificate of main and stored it as dummy:
root@d3bf84b82698:/diagdata# keytool -list -keystore keystore.jks
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 2 entries
dummy, Sep 9, 2020, trustedCertEntry,
Certificate fingerprint (SHA-256): 07:C1:D4:06:AC:0E:55:C2:25:41:FE:0E:35:9D:9C:8C:03:42:E4:D2:AA:74:1E:0E:21:11:3A:97:CE:A2:AD:22
main, Sep 8, 2020, PrivateKeyEntry,
Certificate fingerprint (SHA-256): 07:C1:D4:06:AC:0E:55:C2:25:41:FE:0E:35:9D:9C:8C:03:42:E4:D2:AA:74:1E:0E:21:11:3A:97:CE:A2:AD:22
root@d3bf84b82698:/diagdata#
This gives me the same error message as before.
> Are you really using Tomcat 8.5.4 and 8.5.5? If so, you are like 4 years out of date and there are published security vulnerabilities affecting your Tomcat version. Can you try with 8.5.latest which is currently 8.5.57?
No, we automatically ship the latest 8.5 tomcat version. However for our docker based distribution I was sure that this feature worked at some time (I think I used tomcat 8.0 for this). I tried it with the latest 8.5.57 on Windows, there everything works correctly.
I just checked all the versions to see when the "bug" was introduced.
>> Is this a Linux specific bug?
> That would be unusual, but certainly possible. Are you *sure* this works with no other changes other than:
>
> 1. Switching to Windows
> or
> 2. Switching to Tomcat 8.5.4?
>
> My guess is that the keystore is not bit-for-bit identical to your Windows or Tomcat 8.5.4 environments.
Yes, I copied the keystore that works for Windows and copied it to the docker test environment. The windows keystore gives me the same error message.
> $ keytool -exportcert -alias 'www.example.com' -rfc -keystore /diagdata/keystore.jks ====BEGIN CERTIFICATE===== blah blah blah =====END CERTIFICATE=====
>
> $ keytool -importcert -alias 'dummy' -keystore /diagdata/keystore.jks [paste cert here]
I tried this but it did not help...
Thanks, David
Re: Truststore in HTTPS Connector does not work with Linux
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
David,
On 9/8/20 03:58, David Weisgerber wrote:
> I have some weird problem or bug with the HTTPS Connector. In our
> product, that ships with tomcat we want to achieve the following:
>
> There is one keystore where the customer puts its server
> certificate for HTTPs as well as (if intended) zero or one
> certificate for client authentication. The certificate for client
> authentication can be self-signed and the customer can setup its
> own certificate authority for this.
>
> For this I put the following code for configuring the connector in
> the server.xml:> <Connector port="8443"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
> bindOnInit="false" clientAuth="false" sslProtocol="TLS"
> keystoreFile="/diagdata/keystore.jks" keystorePass="custo1234"
> keyAlias="main" truststoreFile="/diagdata/keystore.jks"
> truststorePassword="custo1234" />
This should be okay, though it is a little unusual to use the same
keystore for both "keys" and "trusted certs".
Can you confirm the contents + types of everything in the keystore?
> (The real clientAuth is done in the deployed application because it
> is more complicated, I just need the feature to be enabled). This
> gives me the following error:
> org.apache.catalina.LifecycleException: Protocol handler start
> failed <2> at
> org.apache.catalina.connector.Connector.startInternal(Connector.java:1
038)
>
>
<2> at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> <2> at
> org.apache.catalina.core.StandardService.startInternal(StandardService
.java:438)
>
>
<2> at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> <2> at
> org.apache.catalina.core.StandardServer.startInternal(StandardServer.j
ava:930)
>
>
<2> at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> <2> at
> org.apache.catalina.startup.Catalina.start(Catalina.java:633) <2>
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) <2> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeM
ethodAccessorImpl.java:62)
>
>
<2> at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Deleg
atingMethodAccessorImpl.java:43)
> <2> at
> java.base/java.lang.reflect.Method.invoke(Method.java:564) <2>
> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
> <2> at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:478)
> <2>Caused by: java.lang.IllegalArgumentException: the trustAnchors
> parameter must be non-empty <2> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstr
actJsseEndpoint.java:99)
>
>
<2> at
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJs
seEndpoint.java:71)
> <2> at
> org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:217)
> <2> at
> org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEn
dpoint.java:1141)
>
>
<2> at
org.apache.tomcat.util.net.AbstractEndpoint.start(AbstractEndpoint.java:
1227)
> <2> at
> org.apache.coyote.AbstractProtocol.start(AbstractProtocol.java:592)
>
>
<2> at
org.apache.catalina.connector.Connector.startInternal(Connector.java:103
5)
> <2> ... 12 more <2>Caused by:
> java.security.InvalidAlgorithmParameterException: the trustAnchors
> parameter must be non-empty <2> at
> java.base/java.security.cert.PKIXParameters.setTrustAnchors(PKIXParame
ters.java:200)
>
>
<2> at
java.base/java.security.cert.PKIXParameters.<init>(PKIXParameters.java:1
57)
> <2> at
> java.base/java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderP
arameters.java:130)
>
>
<2> at
org.apache.tomcat.util.net.SSLUtilBase.getParameters(SSLUtilBase.java:49
4)
> <2> at
> org.apache.tomcat.util.net.SSLUtilBase.getTrustManagers(SSLUtilBase.ja
va:425)
>
>
<2> at
org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java
:247)
> <2> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstr
actJsseEndpoint.java:97)
>
>
<2> ... 18 more
>
> The error goes away when I remove truststoreFile and
> truststorePassword. Now comes the interesting part: The same
> configuration works under Windows (with other paths of course)
> using the Windows-Store as truststore for HTTPS connections to
> other servers. The same configuration worked with Tomcat 8.5.4 and
> the error just popped up from version 8.5.5. The error also seems
> not to be based on the java version, I tried it with Java 8 and
> Java 14. Under Windows we use Java 9...
Are you really using Tomcat 8.5.4 and 8.5.5? If so, you are like 4
years out of date and there are published security vulnerabilities
affecting your Tomcat version. Can you try with 8.5.latest which is
currently 8.5.57?
> Is this a Linux specific bug?
That would be unusual, but certainly possible. Are you *sure* this
works with no other changes other than:
1. Switching to Windows
or
2. Switching to Tomcat 8.5.4?
My guess is that the keystore is not bit-for-bit identical to your
Windows or Tomcat 8.5.4 environments.
> What is a trust anchor anyway?
A trust anchor is a certificate which establishes trust in other
certificates (which it has signed), or just to itself.
Usually "trust anchors parameter must be non-empty" means that you
have loaded a trust store which only contains "private keys" (which
always contain a public key/certificate in a JKS file, which is really
confusing) and no trusted-certificates.
This would happen if you did "keytool -genkey blah blah" and didn't
add any trusted certificates.
If that's the problem, there are several ways to handle it:
1. Generate a dummy certificate and import it into your keystore:
$ keytool -importcert -alias 'dummy' -keystore /diagdata/keystore.jks
[paste cert here]
2. Export the server certificate and import it to trust itself
$ keytool -exportcert -alias 'www.example.com' -rfc -keystore
/diagdata/keystore.jks
====BEGIN CERTIFICATE=====
blah blah blah
=====END CERTIFICATE=====
$ keytool -importcert -alias 'dummy' -keystore /diagdata/keystore.jks
[paste cert here]
3. Import a "legitimate" certificate for client trust
This is the thing you said should be "optional" for your clients. It
may not be optional if Java gets really upset about it. You may want
to tell your clients to use a dummy certificate if you don't feel
comfortable doing it yourself.
Theoretically, Tomcat could scan the trust store to see if there are
any trusted certificates in there and, if not, wave its hands to make
the problem go away. The problem is that maybe Tomcat doesn't know
what your preferences are for fall-back plans. So, it's best to pick
one of the above alternatives (or remove the trustStore-related
configuration settings and allow the JVM to use the default trust store)
.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9XyDoACgkQHPApP6U8
pFijUQ/8DU5GP3iuQX2cJNkuIbKb7XwieU8ImwM4k7TI5Btj8d9eOtNqdpbinxge
5t6hhMfooY25hBC8RZDG/ZfBzdmqYUdv6sUvkf9hD+b5t5aOW7rQ8adfNnfPkO6S
TaVSKbOqP5wXWg2YIvuvmHSmLZg6tJVzwJU1W52hOdnz7NsWxBxBRSJUheUaZ87i
PKJcko/Km3dchTkWEV8TCTVvK0VAlpRKZIhl6D/s38z/JZ2cpzwLfTK+yB7mDRGs
DbYw85tcTh3oxVaSU2V1YfX7i6GaIgtdx/N7yh5InSWP4w98VpT3odJrdc7WMc8+
8KxP3jsS6TlPVm4r0sFeEK8adEO7ZX6l9CZ3JxIVoZbkxG/IRnZ8Oe1y7ghDRGxL
wWsfKGMfri2Ijac3mpnvQLwVocrDxSPrTkBntis/r/hN+ups9Vp3WPGBP200Xg2Q
InthJpId1AreiXITGrW73QoxgCcja9yS8rJ866ydH68/LiX8mN7SU5ZwuZzOQqol
Q7TuwaAbQmzDezNOaa26qWFXZusQaye08mQOxaDMJoRC13oM07HeVfY8mmxw1YY6
6V2kQZf1BhsmVocUwKN1+rLRnxHYXgbJVZ1cRHc0l9XrTTOUbdpiyrVxjlTYAeQy
q8RtRXwlq/Fnb/pssium9Wl1f+eJPutx26Pq77BG5k89gLXbrLc=
=Dhwx
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
AW: Truststore in HTTPS Connector does not work with Linux
Posted by David Weisgerber <da...@ms-gmbh.de>.
Hi Luis,
My keystore (for HTTPs):
-rw-r--r-- 1 root root 4067 Sep 8 10:27 /diagdata/keystore.jks
General Java Keystore:
-rw-r--r-- 1 root root 149549 Sep 8 09:32 /etc/ssl/certs/java/cacerts
lrwxrwxrwx 1 root root 27 Apr 18 14:25 /usr/lib/jvm/java-14-openjdk-amd64/lib/security/cacerts -> /etc/ssl/certs/java/cacerts
<6>Starting ProtocolHandler ["https-openssl-nio-8443"]
javax.net.ssl|DEBUG|01|main|2020-09-08 10:39:18.507 CEST|SunX509KeyManagerImpl.java:160|found key for : main (
"certificate" : {
"version" : "v3",
"serial number" : "00 FC 1F BA 70 76 61 59 05",
"signature algorithm": "SHA256withRSA",
"issuer" : "CN=localhost",
"not before" : "2020-09-08 10:27:50.000 CEST",
"not after" : "2023-06-29 10:27:50.000 CEST",
"subject" : "CN=localhost",
"subject public key" : "RSA",
"extensions" : [
{
ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 81 53 CD 0B 4F 48 05 13 43 BF 30 59 0C 85 A3 20 .S..OH..C.0Y...
0010: 44 7D 01 9D D...
]
]
}
]}
)
<2>Failed to start component [Connector[HTTP/1.1-8443]]
[...]
keystore.jks is created by keytool -genkey -alias main -keyalg RSA -keysize 4096 -sigalg SHA256withRSA -dname "CN=localhost" -validity 1024 -keypass custo1234 -storepass custo1234 -keystore /diagdata/keystore.jks
The interesting part, all of this works under Windows by using -Djavax.net.ssl.trustStoreType=WINDOWS-ROOT
________________________________________
Von: Luis Rodríguez Fernández [uo67113@gmail.com]
Gesendet: Dienstag, 8. September 2020 10:16
An: Tomcat Users List
Betreff: Re: Truststore in HTTPS Connector does not work with Linux
Hello David,
That error usually happens when the java process (tomcat) can not access
the truststore file. May I ask you to check permissions and ownership of
the truststore file? You can always add -Djavax.net.debug=all to your
CATALINA_OPTS, it will give you way more information about the issue.
Hope it helps,
Luis
El mar., 8 sept. 2020 a las 9:58, David Weisgerber (<
david.weisgerber@ms-gmbh.de>) escribió:
> Hi,
> I have some weird problem or bug with the HTTPS Connector. In our product,
> that ships with tomcat we want to achieve the following:
> There is one keystore where the customer puts its server certificate for
> HTTPs as well as (if intended) zero or one certificate for client
> authentication. The certificate for client authentication can be
> self-signed and the customer can setup its own certificate authority for
> this.
> For this I put the following code for configuring the connector in the
> server.xml:
>
> <Connector port="8443"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> maxThreads="150" SSLEnabled="true" scheme="https"
> secure="true" bindOnInit="false"
> clientAuth="false" sslProtocol="TLS"
> keystoreFile="/diagdata/keystore.jks" keystorePass="custo1234"
> keyAlias="main" truststoreFile="/diagdata/keystore.jks"
> truststorePassword="custo1234" />
>
> (The real clientAuth is done in the deployed application because it is
> more complicated, I just need the feature to be enabled).
> This gives me the following error:
> org.apache.catalina.LifecycleException: Protocol handler start failed
> <2> at
> org.apache.catalina.connector.Connector.startInternal(Connector.java:1038)
> <2> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> <2> at
> org.apache.catalina.core.StandardService.startInternal(StandardService.java:438)
> <2> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> <2> at
> org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930)
> <2> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> <2> at org.apache.catalina.startup.Catalina.start(Catalina.java:633)
> <2> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> <2> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> <2> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> <2> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> <2> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
> <2> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:478)
> <2>Caused by: java.lang.IllegalArgumentException: the trustAnchors
> parameter must be non-empty
> <2> at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:99)
> <2> at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:71)
> <2> at org.apache.tomcat.util.net
> .NioEndpoint.bind(NioEndpoint.java:217)
> <2> at org.apache.tomcat.util.net
> .AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1141)
> <2> at org.apache.tomcat.util.net
> .AbstractEndpoint.start(AbstractEndpoint.java:1227)
> <2> at
> org.apache.coyote.AbstractProtocol.start(AbstractProtocol.java:592)
> <2> at
> org.apache.catalina.connector.Connector.startInternal(Connector.java:1035)
> <2> ... 12 more
> <2>Caused by: java.security.InvalidAlgorithmParameterException: the
> trustAnchors parameter must be non-empty
> <2> at
> java.base/java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
> <2> at
> java.base/java.security.cert.PKIXParameters.<init>(PKIXParameters.java:157)
> <2> at
> java.base/java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:130)
> <2> at org.apache.tomcat.util.net
> .SSLUtilBase.getParameters(SSLUtilBase.java:494)
> <2> at org.apache.tomcat.util.net
> .SSLUtilBase.getTrustManagers(SSLUtilBase.java:425)
> <2> at org.apache.tomcat.util.net
> .SSLUtilBase.createSSLContext(SSLUtilBase.java:247)
> <2> at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:97)
> <2> ... 18 more
>
> The error goes away when I remove truststoreFile and truststorePassword.
> Now comes the interesting part: The same configuration works under Windows
> (with other paths of course) using the Windows-Store as truststore for
> HTTPS connections to other servers. The same configuration worked with
> Tomcat 8.5.4 and the error just popped up from version 8.5.5. The error
> also seems not to be based on the java version, I tried it with Java 8 and
> Java 14. Under Windows we use Java 9...
>
> Is this a Linux specific bug? What is a trust anchor anyway?
>
> Thanks in advance,
> David
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."
- Samuel Beckett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Truststore in HTTPS Connector does not work with Linux
Posted by Luis Rodríguez Fernández <uo...@gmail.com>.
Hello David,
That error usually happens when the java process (tomcat) can not access
the truststore file. May I ask you to check permissions and ownership of
the truststore file? You can always add -Djavax.net.debug=all to your
CATALINA_OPTS, it will give you way more information about the issue.
Hope it helps,
Luis
El mar., 8 sept. 2020 a las 9:58, David Weisgerber (<
david.weisgerber@ms-gmbh.de>) escribió:
> Hi,
> I have some weird problem or bug with the HTTPS Connector. In our product,
> that ships with tomcat we want to achieve the following:
> There is one keystore where the customer puts its server certificate for
> HTTPs as well as (if intended) zero or one certificate for client
> authentication. The certificate for client authentication can be
> self-signed and the customer can setup its own certificate authority for
> this.
> For this I put the following code for configuring the connector in the
> server.xml:
>
> <Connector port="8443"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> maxThreads="150" SSLEnabled="true" scheme="https"
> secure="true" bindOnInit="false"
> clientAuth="false" sslProtocol="TLS"
> keystoreFile="/diagdata/keystore.jks" keystorePass="custo1234"
> keyAlias="main" truststoreFile="/diagdata/keystore.jks"
> truststorePassword="custo1234" />
>
> (The real clientAuth is done in the deployed application because it is
> more complicated, I just need the feature to be enabled).
> This gives me the following error:
> org.apache.catalina.LifecycleException: Protocol handler start failed
> <2> at
> org.apache.catalina.connector.Connector.startInternal(Connector.java:1038)
> <2> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> <2> at
> org.apache.catalina.core.StandardService.startInternal(StandardService.java:438)
> <2> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> <2> at
> org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930)
> <2> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> <2> at org.apache.catalina.startup.Catalina.start(Catalina.java:633)
> <2> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> <2> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> <2> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> <2> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> <2> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
> <2> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:478)
> <2>Caused by: java.lang.IllegalArgumentException: the trustAnchors
> parameter must be non-empty
> <2> at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:99)
> <2> at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:71)
> <2> at org.apache.tomcat.util.net
> .NioEndpoint.bind(NioEndpoint.java:217)
> <2> at org.apache.tomcat.util.net
> .AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1141)
> <2> at org.apache.tomcat.util.net
> .AbstractEndpoint.start(AbstractEndpoint.java:1227)
> <2> at
> org.apache.coyote.AbstractProtocol.start(AbstractProtocol.java:592)
> <2> at
> org.apache.catalina.connector.Connector.startInternal(Connector.java:1035)
> <2> ... 12 more
> <2>Caused by: java.security.InvalidAlgorithmParameterException: the
> trustAnchors parameter must be non-empty
> <2> at
> java.base/java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
> <2> at
> java.base/java.security.cert.PKIXParameters.<init>(PKIXParameters.java:157)
> <2> at
> java.base/java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:130)
> <2> at org.apache.tomcat.util.net
> .SSLUtilBase.getParameters(SSLUtilBase.java:494)
> <2> at org.apache.tomcat.util.net
> .SSLUtilBase.getTrustManagers(SSLUtilBase.java:425)
> <2> at org.apache.tomcat.util.net
> .SSLUtilBase.createSSLContext(SSLUtilBase.java:247)
> <2> at org.apache.tomcat.util.net
> .AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:97)
> <2> ... 18 more
>
> The error goes away when I remove truststoreFile and truststorePassword.
> Now comes the interesting part: The same configuration works under Windows
> (with other paths of course) using the Windows-Store as truststore for
> HTTPS connections to other servers. The same configuration worked with
> Tomcat 8.5.4 and the error just popped up from version 8.5.5. The error
> also seems not to be based on the java version, I tried it with Java 8 and
> Java 14. Under Windows we use Java 9...
>
> Is this a Linux specific bug? What is a trust anchor anyway?
>
> Thanks in advance,
> David
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."
- Samuel Beckett