[ http://issues.apache.org/jira/browse/WSFX-40?page=history ]
Thomas Leonard updated WSFX-40:
-------------------------------
Attachment: chain.patch
We have hit this issue to. Here is a patch to fix it. Unlike the previous
suggestion, we changed SecurityTokenReference.java to only return the correct
certificate in the first place (rather than returning a chain and then taking
the head), since that is what the function is defined to do.
Taking the first in the chain is OK, as the KeyStore method returns "the
certificate chain (ordered with the user's certificate first and the root
certificate authority last), or null if the given alias does not exist or does
not contain a certificate chain"
> 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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
