[
https://issues.apache.org/activemq/browse/SMXCOMP-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SMXCOMP-590 started by Freeman Fang.
> 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
> Assignee: Freeman Fang
> Fix For: 3.2
>
> Attachments: certs.tar
>
>
> 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.
