Bug 59616 - SSLVerifyClient="optionalNoCA" stops working between 1.1.33 and 1.2.4
Summary: SSLVerifyClient="optionalNoCA" stops working between 1.1.33 and 1.2.4
Alias: None
Product: Tomcat Native
Classification: Unclassified
Component: Library (show other bugs)
Version: 1.2.4
Hardware: PC All
: P2 regression (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2016-05-23 15:13 UTC by Florian Kleedorfer
Modified: 2016-06-20 09:30 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Florian Kleedorfer 2016-05-23 15:13:04 UTC

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, OpenSSL 1.0.1m 19 Mar 2015 (works for us)
tomcat 8.0.32: tcnative version , 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:

     clientAuth="wanted" port="8443" minSpareThreads="5"
     enableLookups="true" disableUploadTimeout="true"
     acceptCount="100" maxThreads="200"
     scheme="https" secure="true" SSLEnabled="true"

# Logs:

Here's the trace of the failing TLS handshake (including the exception), with -Djavax.net.debug=all

client side:


server side, with java util logging level=ALL:


# Self-Signed Client certificate:

C:\Users\fkleedorfer\wonkey>keytool -list -v -providerclass org.bouncycastle.jce
.provider.BouncyCastleProvider -storetype UBER -storepass [XXXX] -keystore owner-k

Keystore-Typ: UBER
Keystore-Provider: BC

Keystore enthält 1 Eintrag

Erstellungsdatum: 19.05.2016
Eintragstyp: PrivateKeyEntry
Zertifikatskettenlänge: 1
Eigentümer: CN=,OU=Web of Needs
Aussteller: CN=,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
          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:
          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
Comment 1 Florian Kleedorfer 2016-05-23 15:55:42 UTC
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
Comment 2 Mark Thomas 2016-06-17 07:51:16 UTC
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.
Comment 3 Mark Thomas 2016-06-17 11:21:02 UTC
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.
Comment 4 Mark Thomas 2016-06-17 18:37:28 UTC
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.
Comment 5 Mark Thomas 2016-06-17 21:46:39 UTC
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.
Comment 6 Mark Thomas 2016-06-20 09:30:18 UTC
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.