#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 tried with the latest APR versions available on the website: https://tomcat.apache.org/download-native.cgi with 1.1.34, our application works, with 1.2.7, I'm experiencing the same issue
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.
Results of further testing: The following work: OSX + Tomcat 9.0.x + OpenSSL 1.0.2h + APR 1.5.2 + tc-native 1.2.x + OSX client OSX + Tomcat 9.0.x + OpenSSL 1.0.2h + APR 1.5.2 + tc-native 1.2.7 + OSX client OSX + Tomcat 9.0.x + OpenSSL 1.0.2h + APR 1.5.2 + tc-native 1.2.6 + OSX client OSX + Tomcat 9.0.x + OpenSSL 1.0.2h + APR 1.5.2 + tc-native 1.2.6 + Win client The following fail: Win + Tomcat 9.0.x + OpenSSL 1.0.2h + APR 1.5.2 + tc-native 1.2.7 + Win client Win + Tomcat 9.0.x + OpenSSL 1.0.2h + APR 1.5.2 + tc-native 1.2.7 + OSX client Assuming there is only a single bug here, the results above rule everything out apart from the OS hosting the Tomcat server. That suggests an OS specific element of one of the native builds is responsible for this change. It is going to take some more work to track this down.
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.
1.1.x is not affected. 1.2.0 to 1.2.7 is affected. This has been fixed in 1.2.x and will be included in 1.2.8 onwards.