You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org> on 2010/11/10 18:35:29 UTC

[jira] Issue Comment Edited: (WSS-40) WSSecurityEngine does not support chained certificates

    [ https://issues.apache.org/jira/browse/WSS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12930666#action_12930666 ] 

Colm O hEigeartaigh edited comment on WSS-40 at 11/10/10 12:34 PM:
-------------------------------------------------------------------


Hi Seumus,

I've committed your test-case and a patch for this issue. I changed a few things around - namely I added back in the part about only checking the cert chain if it was a PKIPath. 

I have a port of this almost done on 1_5_x-fixes. Things are done slightly differently here, as trust verification does not take place in the SignatureProcessor, as it does on trunk, but is done in WSHandler.verifyTrust. I added an overloaded version of this method to WSHandler. The client code (i.e. WSS4JInInterceptor in CXF) must call the right overloaded method depending on whether there are multiple certificates or not. The SignatureProcessor only saves multiple certificates if the inbound BinarySecurityToken uses PKIPath.

One I get this done I'll add a patch to CXF. I'm not going to touch WSS4JHandler (which CXF doesn't use), or the inbound Axis handler. Other third party code which uses WSS4JHandler, or WSHandler in general, must implement their own logic to call the right verifyTrust method, if they want to take advantage of this functionality. 

Colm.

      was (Author: coheigea):
    
Hi Seumus,

I've committed your test-case and a patch for this issue. I changed a few things around - namely I added back in the part about only checking the cert chain if it was a PKIPath. 

I have a port of this almost done on 1_5_x-fixes. Things are done slightly differently here, as trust verification does not take place in the SignatureProcessor, as it does on trunk, but is done in WSHandler.verifyTrust. I added an overloaded version of this method to WSHandler. The client code (i.e. WSS4JInInterceptor in CXF) must call the right overloaded method depending on whether there are multiple certificates or not. The SignatureProcessor only saves multiple certificates if the inbound BinarySecurityToken uses PKIPath.

One I get this done I'll add a patch to CXF. I'm not going to touch WSS4JHandler (which CXF doesn't use). pr the inbound Axis handler. Other third party code which uses WSS4JHandler, or WSHandler in general, must implement their own logic to call the right verifyTrust method, if they want to take advantage of this functionality. 

Colm.
  
> WSSecurityEngine does not support chained certificates
> ------------------------------------------------------
>
>                 Key: WSS-40
>                 URL: https://issues.apache.org/jira/browse/WSS-40
>             Project: WSS4J
>          Issue Type: Bug
>    Affects Versions: 1.5.6
>         Environment: WSS4J 1.0.0, Axis 1.2.1, Sun JDK 1.4.2
>            Reporter: Guy Rixon
>            Assignee: Colm O hEigeartaigh
>             Fix For: 1.6
>
>         Attachments: client_keystore.jks, server_keystore.jks, wss-40-test.patch, wss40-trunk-revised.patch, wss40.patch, wss40.patch.11.09.2010
>
>
> My project, which is associated with the Grid, uses limited proxy certificates for digital signature. I.e., the signing application holds a user's permanent certificate, signed by a CA and a proxy certificate signed with the permanent certificate. The application signs a message using the proxy certificate and includes both the proxy and permanent certificates in the message header as a WS-Security direct reference to a BinarySecurityToken. The service has the CA certificate with which the user's permanent certficate was signed. Therefore, to establish trust, the service has to chain back from the proxy to the permanent certificate and then to the CA certificate.
> WSSignEnvelope includes both certificates correctly but WSSecurityEngine fails when checking the chain of trust. WSSecurityEngine..processSecurityHeader() only adds one certificate to the results passed back to WSDoAllReceiver; it ignores the intermediate certificate in the chain.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org