[ 
https://issues.apache.org/jira/browse/WSS-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh reassigned WSS-87:
--------------------------------------

    Assignee: Colm O hEigeartaigh

> CryptoBase.getAliasForX509Cert(String, BigInteger) fails when issuer string 
> contains OIDs
> -----------------------------------------------------------------------------------------
>
>                 Key: WSS-87
>                 URL: https://issues.apache.org/jira/browse/WSS-87
>             Project: WSS4J
>          Issue Type: Bug
>    Affects Versions: 1.5.4
>         Environment: JRE 1.4.2
> WSS4J 1.5.2
>            Reporter: Mario A. Rodriguez
>            Assignee: Colm O hEigeartaigh
>             Fix For: 1.5.5
>
>
> I'm attempting to validate a signature generated using a self-signed 
> certificate. The issuer DN looks like the following:
> CN=xxxx.yyyy.com,OU=MYOU,O=Some Company,ST=NORTH 
> CAROLINA,2.5.4.17=#13053237353630,C=US
> This was generated by invoking X509Certificate.getX500Principal.getName() 
> which returns a string formatted according to RFC2253 rules.
> The problem is that when org.apache.ws.security.processor.SignatureProcessor 
> parses the SecurityTokenReference element in the signature, it feeds it 
> through the XMLX509IssuerSerial class first. And when you invoke the 
> getIssuerName() method on this class it returns the following:
> CN=xxxx.yyyy.com,OU=MYOU,O=Some Company,ST=NORTH 
> CAROLINA,2.5.4.17=\#13053237353630,C=US
> Note the extra "\".  This alone would cause the lower-level 
> getAliasForX509Cert(String, BigInteger, boolean) method to fail the 
> comparison between the two DNs. However, the problem is compounded by the 
> fact the getAlias() relies on the X509Certificate.getIssuerDN().getName() 
> routine to make its comparisons. And the DN string returned by that method 
> doesn't appear to comply with RFC2253.
> I also looked at the signing code and it is also relying on 
> X509Certificate.getIssuerDN().getName()  to format "Issuer Serial" 
> signatures. 
> The code should rely on X500Principal.getName() instead since that function 
> guarantees RFC2253 compliant strings as recommended by the digital signature 
> specification.

-- 
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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to