#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

I'm seeing the issue (or something very like it) with 1.2.7 and Tomcat trunk. I spent a little time looking at the 1.1.x code vs 1.2.x but don't see any obvious root causes. I plan to do some more investigation today.

Whatever is going wrong is going wrong in OpenSSL. Don't know where the root cause is at the moment but the error is:
3648:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed:.\ssl\s3_srvr.c:3270:
Which is triggered a full failure rather than allowing the tc-native code to decide what to do.

I've found the root cause. There were some changes in the build scripts between 1.1.x and 1.2.x that meant OCSP was always enabled. Validation with optionalNoCA always fails if OCSP is enabled.
I plan to commit my fix early next week and start the process to release a new set of Windows binaries for tc-native.

This is ASF Bugzilla: the Apache Software Foundation bug system. In case
of problems with the functioning of ASF Bugzilla, please contact
bugzilla-admin@apache.org.
Please Note: this e-mail address is only for reporting problems
with ASF Bugzilla. Mail about any other subject will be silently
ignored.