You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by "Werner Dittmann (JIRA)" <fx...@ws.apache.org> on 2005/05/21 22:36:53 UTC

[jira] Closed: (WSFX-40) Encryption via 509SubjectKeyIdentifier can't handle certificate chain

     [ http://issues.apache.org/jira/browse/WSFX-40?page=all ]
     
Werner Dittmann closed WSFX-40:
-------------------------------

    Resolution: Fixed

Problem fixed during some general code cleanup

> Encryption via 509SubjectKeyIdentifier can't handle certificate chain
> ---------------------------------------------------------------------
>
>          Key: WSFX-40
>          URL: http://issues.apache.org/jira/browse/WSFX-40
>      Project: WSFX
>         Type: Bug
>   Components: WSS4J
>  Environment: AXIS 1.2 Beta3, 
> .NET client using WSE 2.0 sp1
>     Reporter: Erik Strauss Hansen
>  Attachments: chain.patch
>
> I have found a problem in decryption of a SOAP request.
> Scenario:::
> I am testing a WebService deployed in AXIS 1.2 Beta3 and using the latest WSS4J source code..  
> The Webservice client is a .NET client using WSE 2.0 sp1.
> It seems that the WSE 2.0 uses the "509SubjectKeyIdentifier" to identify the "Encryption" certificate.
> Problem::::
> The client sends the following XML to identify the Encryption certificate.
> <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
>   <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
>     <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
>       <wsse:SecurityTokenReference>
>         <wsse:KeyIdentifier  ValueType="http://docs.oasis-open.org/wss/2004/01/     
>                     oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier">
>               fFQvqAg/jmQ4bGbCKvdqaTLAVs0=
>         </wsse:KeyIdentifier>
>       </wsse:SecurityTokenReference>
>     </KeyInfo>
>     ...
> </xenc:EncryptedKey>
> The problem is in the "WSSecurityEngine" class.  
> The method "public void handleEncryptedKey(Element xencEncryptedKey, CallbackHandler cb, Crypto crypto) throws WSSecurityException"  throws an exception, when trying to find the "Encryption" certificate in the certificate-store.
> The following code is the part, where the problem occurs..
> * If wsse:KeyIdentifier found, then the public key of the attached cert was used to
> * encrypt the session (symmetric) key that encrypts the data. Extract the certificate
> * using the BinarySecurity token (was enhanced to handle KeyIdentifier too).
> * This method is _not_recommended by OASIS WS-S specification, X509 profile
> */
>      else if (secRef.containsKeyIdentifier()) {
>         X509Certificate[] certs = secRef.getKeyIdentifier(crypto);
>         if (certs == null || certs.length != 1 || certs[0] == null) {
>            throw new WSSecurityException(WSSecurityException.FAILURE,
>                  "invalidX509Data", new Object[]{"for decryption (KeyId)"});
>         }
> The call to the method "secRef.getKeyIdentifier(crypto)" return not only the "Encryption" certificate, but the complete certificate chain.
> So the Array of Certificates contains more then one certificate and therefore a "WSSecurityException" is thrown.
> I have changed the source code as follows; 
>            if (certs == null || certs[0] == null) {
> allowing more then one certificate to be returned.    This change does however assume that the "Encryption" certificate is the first one in the array.    
> I am not sure where to do the change, but it is properly more feasible to make a change in  "SecurityTokenReference.java" in method  "public X509Certificate[] getKeyIdentifier(Crypto crypto)".
> Instead of returning the certificate chain, then only the main certificate should be returned.
> #### (existing code )
>      } else if (value.equals(SKI_URI)) {
>         String alias = getX509SKIAlias(crypto);
>         if (alias != null) {
>             return crypto.getCertificates(alias);   ####  returning certificate chain.
>         }
>      }
>     return null;
> ####
> The interoperability test seems to work, because the certificates used for the tests, does have a certificate chain length of 1.   

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira