You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Florian Kleedorfer <fl...@austria.fm> on 2016/05/19 16:49:09 UTC
SSLVerifyClient="optionalNoCA" stops working in tomcat 8.0.32?
Hi!
TL;DR: The TLS handshake with client authentication using self-signed
client certificates (using APR/openssl) stopped working from tomcat
8.0.30 to tomcat 8.0.32. Cause is suspected in a change of openssl or
APR between versions.
# Context:
We're using tomcat 8 in a setting where the client has a self-signed
client certificate that is transmitted to the server to identify the
client. The certificate is used to gather client-specific data in the
appliation. We aren't interested in setting up our own PKI for that, or
using official CAs. Self-signed certs on the client are fine, as far as
we're concerned.
Our code that works in 8.0.30 stops working when switching to 8.0.32, as
documented in this issue on github
https://github.com/researchstudio-sat/webofneeds/issues/547
I am suspecting its either an APR or an openssl issue, or something
related to the way we generate our certificates. I looked up the
versions used in the last working and the first non-working tomcat minor
releases:
tomcat 8.0.30: tcnative version 1.1.33.0, OpenSSL 1.0.1m 19 Mar 2015
(works for us)
tomcat 8.0.32: tcnative version 1.2.4.0 , OpenSSL 1.0.2e 3 Dec 2015
(doesn't work for us)
# Config:
I'm experiencing this on Windows 7, using the -x64 zip downloads.
Here's the configuration of the tomcat connector:
<Connector
clientAuth="wanted" port="8443" minSpareThreads="5"
enableLookups="true" disableUploadTimeout="true"
acceptCount="100" maxThreads="200"
scheme="https" secure="true" SSLEnabled="true"
SSLCertificateFile="C:/Users/fkleedorfer/wonkey/t-cert.pem"
SSLCertificateKeyFile="C:/Users/fkleedorfer/wonkey/t-key.pem"
SSLPassword="changeit"
SSLVerifyClient="optionalNoCA"
SSLVerifyDepth="2"
sslProtocol="TLS"/>
# Logs:
Here's the trace of the failing TLS handshake (including the exception),
with -Djavax.net.debug=all
client side:
https://gist.github.com/fkleedorfer/8b4c3932a1de4b51617eac5e03c0be29
server side, with java util logging level=ALL:
https://gist.github.com/fkleedorfer/f9ca53ee1466bf50dba6ce6d3c243b39
# Self-Signed Client certificate:
C:\Users\fkleedorfer\wonkey>keytool -list -v -providerclass
org.bouncycastle.jce
.provider.BouncyCastleProvider -storetype UBER -storepass [XXXX]
-keystore owner-k
eys.jks
Keystore-Typ: UBER
Keystore-Provider: BC
Keystore enth�lt 1 Eintrag
Aliasname: https://192.168.124.49:8443/owner
Erstellungsdatum: 19.05.2016
Eintragstyp: PrivateKeyEntry
Zertifikatskettenl�nge: 1
Zertifikat[1]:
Eigent�mer: CN=https://192.168.124.49:8443/owner,OU=Web of Needs
Aussteller: CN=https://192.168.124.49:8443/owner,OU=Web of Needs
Seriennummer: 1
G�ltig von: Wed May 18 00:00:00 CEST 2016 bis: Sat May 19 00:00:00 CEST 2018
Zertifikat-Fingerprints:
MD5: 85:BD:2C:67:B5:BF:24:D5:D8:A2:F5:8D:51:F2:31:89
SHA1: F1:92:56:6E:70:A8:DF:05:3E:B1:34:65:8F:CA:D8:69:C6:4C:34:A5
SHA256:
43:60:9F:10:05:F3:2B:60:89:16:0F:65:87:E4:07:C1:48:FE:5E:D2:51:
C6:BA:42:3B:0C:3F:25:9B:E3:37:FD
Signaturalgorithmusname: SHA256WITHECDSA
Version: 3
*******************************************
*******************************************
**
Any help is greatly appreciated, Thanks in advance!
Florian
Re: SSLVerifyClient="optionalNoCA" stops working in tomcat 8.0.32?
Posted by Florian Kleedorfer <fl...@austria.fm>.
Hi Christopher,
Thanks for looking into this!
Am 17.06.2016 um 00:01 schrieb Christopher Schultz:
> clientAuth="want"?
> Note that this is only documented for the JSSE-based connectors, not
> the APR connector.
Yes, thanks - I think that's garbage left in there from my attempts to
use BIO/NIO connectors, which do not seem to allow the needed behaviour
(self-signed client certs) at all - but this is beside the point now.
Removing this attribute does not change anything regarding this bug.
>> SSLVerifyDepth="2"
> Why do you bother to specify SSLVerifyDepth if you aren't trying to
> use CLIENT-CERT authentication? This is just for informational
> purposes from the client, right?
I don't know of any reason to set this attribute to 2 - it was decided
by the original developer and the config used to work. Probably remains
of another abandoned experiment. To be fair, I know of no reason to
remove it (use the defaults) or set a different value, either. If you
have suggestions, I'd be thankful to hear them.
>
> With
> no changes to the client, this works on Tomcat 8.0.30 but fails
> with Tomcat 8.0.32?
My setup:
* Client and server are running on the same machine.
* Everything I documented in this bug report was tried on the same 64
Bit Windows 7 machine.
* Client and server use jdk1.8.0_92
* I am running tomcat through intellij by pointing intellij to a freshly
unpacked tomcat 8.0.(30|32).
* I am running a client as a separate java program, also from intellij.
The bug:
1. When I point intellij to the tomcat 8.0.30 folder, the application
works. When I point it to 8.0.32, it doesn't.
2. After reproducing the error as stated in 1., I can 'fix' 8.0.32 by
copying 8.0.30/bin/tcnative-1.dll to 8.0.32/bin, which convinces me that
the version change between those two tcnative versions is responsible.
The information I gave on openssl versions was taken from the tomcat log
messages. The different openssl versions are due to different versions
of tcnative-1.dll (or at least that is what I think).
'openssl version' on the command prompt of this machine says
OpenSSL 0.9.8zf 19 Mar 2015
>
> Since you presumably have a system with OpenSSL 1.0.1m on it (the
> "working" system), please install Tomcat 8.0.32 on that system and
> re-try with Tomcat 8.0.32 + tcnative 1.2.4 + OpenSSL 1.0.1m.
>
> Since you presumably have a system with OpenSSL 1.0.2e on it (the
> "non-working" system), please try installing Tomcat 8.0.30 on the
> system with OpenSSL 1.0.2e and re-try with Tomcat 8.0.30 + tcnative
> 1.1.33 + OpenSSL 1.0.2e.
Since my whole setup is local, I don't think I can perform these steps.
> This will help narrow-down which component contains the change which
> is causing these failures.
>
> I suspect the problem will be narrowed-down to either a change in
> OpenSSL, a change in tcnative, or a change in APR.
Thanks,
Florian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSLVerifyClient="optionalNoCA" stops working in tomcat 8.0.32?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Florian,
On 5/19/16 12:49 PM, Florian Kleedorfer wrote:
> TL;DR: The TLS handshake with client authentication using
> self-signed client certificates (using APR/openssl) stopped working
> from tomcat 8.0.30 to tomcat 8.0.32. Cause is suspected in a change
> of openssl or APR between versions.
>
> # Context:
>
> We're using tomcat 8 in a setting where the client has a
> self-signed client certificate that is transmitted to the server to
> identify the client. The certificate is used to gather
> client-specific data in the appliation. We aren't interested in
> setting up our own PKI for that, or using official CAs. Self-signed
> certs on the client are fine, as far as we're concerned.
>
> Our code that works in 8.0.30 stops working when switching to
> 8.0.32, as documented in this issue on github
> https://github.com/researchstudio-sat/webofneeds/issues/547
>
> I am suspecting its either an APR or an openssl issue, or
> something related to the way we generate our certificates. I looked
> up the versions used in the last working and the first non-working
> tomcat minor releases:
>
> tomcat 8.0.30: tcnative version 1.1.33.0, OpenSSL 1.0.1m 19 Mar
> 2015 (works for us) tomcat 8.0.32: tcnative version 1.2.4.0 ,
> OpenSSL 1.0.2e 3 Dec 2015 (doesn't work for us)
>
> # Config:
>
> I'm experiencing this on Windows 7, using the -x64 zip downloads.
>
> Here's the configuration of the tomcat connector:
>
> <Connector clientAuth="wanted"
clientAuth="want"?
Note that this is only documented for the JSSE-based connectors, not
the APR connector.
> port="8443" minSpareThreads="5" enableLookups="true"
> disableUploadTimeout="true" acceptCount="100" maxThreads="200"
> scheme="https" secure="true" SSLEnabled="true"
> SSLCertificateFile="C:/Users/fkleedorfer/wonkey/t-cert.pem"
> SSLCertificateKeyFile="C:/Users/fkleedorfer/wonkey/t-key.pem"
> SSLPassword="changeit" SSLVerifyClient="optionalNoCA"
This looks okay.
> SSLVerifyDepth="2"
Why do you bother to specify SSLVerifyDepth if you aren't trying to
use CLIENT-CERT authentication? This is just for informational
purposes from the client, right?
> sslProtocol="TLS"/>
>
> # Logs:
>
> Here's the trace of the failing TLS handshake (including the
> exception), with -Djavax.net.debug=all
>
> client side:
>
> https://gist.github.com/fkleedorfer/8b4c3932a1de4b51617eac5e03c0be29
With
>
no changes to the client, this works on Tomcat 8.0.30 but fails
with Tomcat 8.0.32?
Since you presumably have a system with OpenSSL 1.0.1m on it (the
"working" system), please install Tomcat 8.0.32 on that system and
re-try with Tomcat 8.0.32 + tcnative 1.2.4 + OpenSSL 1.0.1m.
Since you presumably have a system with OpenSSL 1.0.2e on it (the
"non-working" system), please try installing Tomcat 8.0.30 on the
system with OpenSSL 1.0.2e and re-try with Tomcat 8.0.30 + tcnative
1.1.33 + OpenSSL 1.0.2e.
This will help narrow-down which component contains the change which
is causing these failures.
I suspect the problem will be narrowed-down to either a change in
OpenSSL, a change in tcnative, or a change in APR.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJXYyHSAAoJEBzwKT+lPKRYox8QAKy53z/72jz02P30U8Bf32ig
c66drfBiTLmFXC5UrY90v5AgfVFQKS4G0dF9ObP59yzhmsjpen4c17AP2yrfKkbD
G69c45cpZkA+2SnV6dL4uowT7gBXVvIHkxUO1S+7pxcV9P3oqVze5KIU9W/XkwMm
+CBVeZDI5Kxugzme1lLtbu5N74OJFkSW6CQwmY11AKDb8iC4H4wB77UIb4NuwXu4
M90GG2hRF1dU5DQWhEIGY4veC4DvMlRt4lLap6/Ht/1TM8CsS0hiMPEI6UM1P7ZH
CrFIo+nk0lQ+ItSByjT4FOeQUUAVLyWMWNxemxw5eFI0glv8rETuDvSQFFLTK0n3
ELM7NuizTqMYExxXvUUeU5AFrjJtbnCIjYvcd00VweRHhzFx5NgRZmBx4B1cZu4L
/DQTIAdyElK5+yODAuAPkQEbQSizzmjsopj8u/6aX5Ce/WWDmQys2nO//rN7k/Pd
elqap3NppRavceF4XrgKUEH2C2GL4EfEGLNmr+lL+oadDWc//1/OkjAjEgYQq61L
mMugEXYAg1WLKjTJccYhaKC9sVbiCbrrj9FyMKwskdg8Pj6tJhmC8uu8jVZDDwIz
yyU2lJ95VWr3HcbAAJ2wLL/JhAbBCJBsHMeRoT95kvNOcBGEOKkFjs5sYqq2IXTE
7HKsE6safnwDuo1iaLPl
=niTn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [tomcat-users] Re: SSLVerifyClient="optionalNoCA" stops working in
tomcat 8.0.32?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jason,
On 6/16/16 2:45 PM, Jason Pyeron wrote:
>> -----Original Message----- From: Mark Thomas Sent: Thursday, June
>> 16, 2016 14:39 To: Tomcat Users List Subject: [tomcat-users] Re:
>> SSLVerifyClient="optionalNoCA" stops working in tomcat 8.0.32?
>>
>> On 16/06/2016 11:29, Florian Kleedorfer wrote:
>>> Hi!
>>>
>>> There was no response to my request on this list, so I filed a
>>> bug:
>>>
>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=59616
>>>
>>> However, this bug does not seem to get handled by the dev
>>> team.
>>
>> If you want a guaranteed response time, you'll need to pay the
>> going rate for commercial support.
>>
>>> My problem is that our application stopped working with more
>>> recent tomcat versions. We can deal with it for now, but we
>>> need a
>> solution at
>>> some point.
>>>
>>> What is the recommended course of action in this case?
>>
>
> 1. Disable native io first, try again.
This will probably mask the error. OP wants to use OpenSSL for TLS. A
solution of "disable OpenSSL" isn't terribly helpful.
> 2. make a reproducible test case.
OP provided fairly decent steps-to-reproduce. This is not about some
problem that needs to be reduced to a small test-case. This is
configuration + connection = handshake failure. Full configuration
(missing only the private key of the self-signed certificate) was
provided.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJXYyI4AAoJEBzwKT+lPKRYjA8P/2C6QRhvC+Gn++LhDLegrXqV
lPgOtMS9cUBlFXwm7Q8HmjAJWh+RAluTyqf72HfChNOGBTKJscWJDhcZgl42UKHB
qW1UPcUnqfs3q6m/Zmjkuklzk/hOg0pq9aK4JrbfP2lWK3hDEHwF2hOspqb5M8Hx
1gvb33dkc9SXPoaWtXIWgOXxJBy4oiP5kL4Sq/UFKMuhPZ38nMhShHuWQvmKpxev
HQPI8hdCp6gP49fwO7SUYlHi2i0bDbbn214z6d6bzHyCTDrKzSOCJ/OjsBdetG+Q
wHfLGYzVO46mf362nfhO7G3QXR8oaszZd1eRKc8sslh8EkAubYuhBMuyjXc04JjR
yHxl4Mya+ZefNTs2vaQwu+iy+4Tdr1H8dPzRnl1hwPmoSfegzibp3N8LU4JA5qjv
/XYbd2cDhPcJIr8aqACfXPqnOsPTIVmO9dXWZR8SltiHvfsVJ2V4+8Bxoaavshk+
e+1nqb71Nyc0iiQruCbe6tXIbxsobaCzMtLyLXxAP7qljlR7Swkf54iZF73fVjpD
B55d8frCPabbQwx5/6BWCpObJQfyY3GIaaPV4lW5DBB8xAA4YWMxtjxtwwy/DqUt
kLr7aY0j+kIdYxz9wbHpATcAE/oIxHxmSh5W7kGXM+v+15drvV685xRpiELN188b
Y8SxaO80A+QPH3ILa5Mb
=T2aI
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [tomcat-users] Re: SSLVerifyClient="optionalNoCA" stops working in tomcat 8.0.32?
Posted by Jason Pyeron <jp...@pdinc.us>.
> -----Original Message-----
> From: Mark Thomas
> Sent: Thursday, June 16, 2016 14:39
> To: Tomcat Users List
> Subject: [tomcat-users] Re: SSLVerifyClient="optionalNoCA"
> stops working in tomcat 8.0.32?
>
> On 16/06/2016 11:29, Florian Kleedorfer wrote:
> > Hi!
> >
> > There was no response to my request on this list, so I filed a bug:
> >
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=59616
> >
> > However, this bug does not seem to get handled by the dev team.
>
> If you want a guaranteed response time, you'll need to pay the going
> rate for commercial support.
>
> > My problem is that our application stopped working with more recent
> > tomcat versions. We can deal with it for now, but we need a
> solution at
> > some point.
> >
> > What is the recommended course of action in this case?
>
1. Disable native io first, try again.
2. make a reproducible test case.
-Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSLVerifyClient="optionalNoCA" stops working in tomcat 8.0.32?
Posted by Mark Thomas <ma...@apache.org>.
On 16/06/2016 11:29, Florian Kleedorfer wrote:
> Hi!
>
> There was no response to my request on this list, so I filed a bug:
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=59616
>
> However, this bug does not seem to get handled by the dev team.
If you want a guaranteed response time, you'll need to pay the going
rate for commercial support.
> My problem is that our application stopped working with more recent
> tomcat versions. We can deal with it for now, but we need a solution at
> some point.
>
> What is the recommended course of action in this case?
Do what you can to narrow the bug down as much as possible.
Do what you can to provide a simple, easy to run test case that can be
used to investigate the bug.
Then pick one of the following:
1. Wait for a committer to decide to look at the issue. A ping on the
bug every month or so is acceptable. Anything more than that is just
annoying.
2. Pay for commercial support.
Generally, the speed at which bugs get addressed is directly
proportional to the quality of the bug report. (There are other factors
as well.)
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: SSLVerifyClient="optionalNoCA" stops working in tomcat 8.0.32?
Posted by Florian Kleedorfer <fl...@austria.fm>.
Hi!
There was no response to my request on this list, so I filed a bug:
https://bz.apache.org/bugzilla/show_bug.cgi?id=59616
However, this bug does not seem to get handled by the dev team.
My problem is that our application stopped working with more recent
tomcat versions. We can deal with it for now, but we need a solution at
some point.
What is the recommended course of action in this case?
Best regards,
Florian
Am 19.05.2016 um 18:49 schrieb Florian Kleedorfer:
> Hi!
>
> TL;DR: The TLS handshake with client authentication using self-signed
> client certificates (using APR/openssl) stopped working from tomcat
> 8.0.30 to tomcat 8.0.32. Cause is suspected in a change of openssl or
> APR between versions.
>
> # Context:
>
> We're using tomcat 8 in a setting where the client has a self-signed
> client certificate that is transmitted to the server to identify the
> client. The certificate is used to gather client-specific data in the
> appliation. We aren't interested in setting up our own PKI for that,
> or using official CAs. Self-signed certs on the client are fine, as
> far as we're concerned.
>
> Our code that works in 8.0.30 stops working when switching to 8.0.32,
> as documented in this issue on github
> https://github.com/researchstudio-sat/webofneeds/issues/547
>
> I am suspecting its either an APR or an openssl issue, or something
> related to the way we generate our certificates. I looked up the
> versions used in the last working and the first non-working tomcat
> minor releases:
>
> tomcat 8.0.30: tcnative version 1.1.33.0, OpenSSL 1.0.1m 19 Mar 2015
> (works for us)
> tomcat 8.0.32: tcnative version 1.2.4.0 , OpenSSL 1.0.2e 3 Dec 2015
> (doesn't work for us)
>
> # Config:
>
> I'm experiencing this on Windows 7, using the -x64 zip downloads.
>
> Here's the configuration of the tomcat connector:
>
> <Connector
> clientAuth="wanted" port="8443" minSpareThreads="5"
> enableLookups="true" disableUploadTimeout="true"
> acceptCount="100" maxThreads="200"
> scheme="https" secure="true" SSLEnabled="true"
> SSLCertificateFile="C:/Users/fkleedorfer/wonkey/t-cert.pem"
> SSLCertificateKeyFile="C:/Users/fkleedorfer/wonkey/t-key.pem"
> SSLPassword="changeit"
> SSLVerifyClient="optionalNoCA"
> SSLVerifyDepth="2"
> sslProtocol="TLS"/>
>
> # Logs:
>
> Here's the trace of the failing TLS handshake (including the
> exception), with -Djavax.net.debug=all
>
> client side:
>
> https://gist.github.com/fkleedorfer/8b4c3932a1de4b51617eac5e03c0be29
>
> server side, with java util logging level=ALL:
>
> https://gist.github.com/fkleedorfer/f9ca53ee1466bf50dba6ce6d3c243b39
>
> # Self-Signed Client certificate:
>
> C:\Users\fkleedorfer\wonkey>keytool -list -v -providerclass
> org.bouncycastle.jce
> .provider.BouncyCastleProvider -storetype UBER -storepass [XXXX]
> -keystore owner-k
> eys.jks
>
> Keystore-Typ: UBER
> Keystore-Provider: BC
>
> Keystore enth�lt 1 Eintrag
>
> Aliasname: https://192.168.124.49:8443/owner
> Erstellungsdatum: 19.05.2016
> Eintragstyp: PrivateKeyEntry
> Zertifikatskettenl�nge: 1
> Zertifikat[1]:
> Eigent�mer: CN=https://192.168.124.49:8443/owner,OU=Web of Needs
> Aussteller: CN=https://192.168.124.49:8443/owner,OU=Web of Needs
> Seriennummer: 1
> G�ltig von: Wed May 18 00:00:00 CEST 2016 bis: Sat May 19 00:00:00
> CEST 2018
> Zertifikat-Fingerprints:
> MD5: 85:BD:2C:67:B5:BF:24:D5:D8:A2:F5:8D:51:F2:31:89
> SHA1:
> F1:92:56:6E:70:A8:DF:05:3E:B1:34:65:8F:CA:D8:69:C6:4C:34:A5
> SHA256:
> 43:60:9F:10:05:F3:2B:60:89:16:0F:65:87:E4:07:C1:48:FE:5E:D2:51:
> C6:BA:42:3B:0C:3F:25:9B:E3:37:FD
> Signaturalgorithmusname: SHA256WITHECDSA
> Version: 3
>
>
> *******************************************
> *******************************************
> **
> Any help is greatly appreciated, Thanks in advance!
>
> Florian
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org