The org.apache.servicemix.cxfbc.ws.security.CxfBcHttpsConsumerTest is failing
on IBM machines
---------------------------------------------------------------------------------------------
Key: SMXCOMP-590
URL: https://issues.apache.org/activemq/browse/SMXCOMP-590
Project: ServiceMix Components
Issue Type: Bug
Components: servicemix-cxf-bc
Affects Versions: 3.2
Environment: IBM
Reporter: Eamonn Dwyer
Fix For: 3.2
The reason the test fails with the ibm jdk, and not the sun jdk seems to be due
to this:
IBM's JSSE implementation verifies the entire server or client certificate
chain, including trusted certificates. For example, if a trusted certificate
has expired, the handshake fails, even though the expired certificate is
trusted. Sun's JSSE verifies the certificate chain up to the trusted
certificate. Verification stops when it reaches a trusted certificate and the
trusted certificate and beyond are not verified.
Taken from :
http://www.ibm.com/developerworks/java/jdk/security/142/secguides/securityguide.ref.html#jsse_jsse2_diff
Enabling javax.net.debug while running the test, I see this for the last
certificate in the chain:
...
Validity: [From: Mon May 25 02:39:50 NDT 2009,
To: Sat Mar 24 19:11:34 NST 1973]^M
Issuer: C=US, ST=NY, O=Apache, OU=NOT FOR PRODUCTION, CN=TheCA^M
SerialNumber: [1234]^M
...
main, SEND TLSv1 ALERT: fatal, description = certificate_expired
Here's some keytool output:
tc-aix53-1(pjones): keytool -list -v -keystore
src/test/resources/org/apache/servicemix/cxfbc/ws/security/provider/certs/cherry.jks
Enter keystore password: password
Keystore type: jks
Keystore provider: IBMJCE
Your keystore contains 1 entry
Alias name: mykey
Creation date: May 25, 2009
Entry type: keyEntry
Certificate chain length: 3
Certificate[1]:
Owner: CN=Cherry, OU=NOT FOR PRODUCTION, O=Apache, ST=NY, C=US
Issuer: CN=TheRA, OU=NOT FOR PRODUCTION, O=Apache, ST=NY, C=US
Serial number: 1347
Valid from: 5/25/09 1:09 AM until: 5/24/10 1:09 AM
Certificate fingerprints:
MD5: 10:60:0E:36:BB:8B:0D:D0:28:FF:8C:A7:90:C1:84:0A
SHA1: CF:11:CF:41:6A:04:47:10:9D:93:BF:EA:C3:02:16:0A:E8:89:A9:B4
Certificate[2]:
Owner: CN=TheRA, OU=NOT FOR PRODUCTION, O=Apache, ST=NY, C=US
Issuer: C=US, ST=NY, O=Apache, OU=NOT FOR PRODUCTION, CN=TheCA
Serial number: 1345
Valid from: 5/25/09 1:09 AM until: 5/24/10 1:09 AM
Certificate fingerprints:
MD5: FA:0D:7F:1C:91:54:9F:77:2B:AF:89:34:FC:9D:F9:18
SHA1: BC:35:75:0E:D2:5B:BC:65:B1:59:5C:2D:A1:CF:88:42:67:17:7D:C3
Certificate[3]:
Owner: C=US, ST=NY, O=Apache, OU=NOT FOR PRODUCTION, CN=TheCA
Issuer: C=US, ST=NY, O=Apache, OU=NOT FOR PRODUCTION, CN=TheCA
Serial number: 4d2
Valid from: 5/25/09 1:09 AM until: 3/24/73 5:41 PM
Certificate fingerprints:
MD5: 18:83:94:2C:F8:F4:E2:D3:62:44:3D:C8:DA:B2:D2:E9
SHA1: AC:3D:C6:05:D6:7E:AF:6D:0C:54:84:10:7B:4F:4B:11:88:17:33:CA
*******************************************
*******************************************
Using certs that do not expire in 3/24/73 should fix that.
I will be supplying a tar file containing new certs to fix this issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
