https://bz.apache.org/bugzilla/show_bug.cgi?id=59616
Bug ID: 59616
Summary: SSLVerifyClient="optionalNoCA" stops working between
1.1.33 and 1.2.4
Product: Tomcat Native
Version: 1.2.4
Hardware: PC
Status: NEW
Severity: regression
Priority: P2
Component: Library
Assignee: dev@tomcat.apache.org
Reporter: florian.kleedor...@austria.fm
#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)
when using the tcnative-1.dll from the tomcat 8.0.30 installation, our
application also works in tomcat 8.0.32, which is another clue that the APR
library is responsible for this change in behaviour.
I could not get earlier versions of the 1.2 library for comparison, so this is
filed as an 1.2.4 bug.
# 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
*******************************************
*******************************************
**
I posted this issue in the tomcat-users mailing list but did not get any
response:
http://mail-archives.apache.org/mod_mbox/tomcat-users/201605.mbox/browser
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
