org.apache.xml.security.keys.content.x509.XMLX509IssuerSerial ... public XMLX509IssuerSerial(Document doc, X509Certificate x509certificate) { this(doc, RFC2253Parser.normalize(x509certificate.getIssuerDN().getName()), x509certificate.getSerialNumber()); } In this piece of code, x509certificate.getIssuerDN().getName() should be replaced by x509certificate.getIssuerX500Principal().getName(), as suggested by the JDK 1.5 API (http://java.sun.com/j2se/1.5.0/docs/api/java/security/cert/X509Certificate.html #getIssuerDN()) The problem I have now, is that the IssuerDN with the current implementation will report: EMAILADDRESS=abcde@somewhere.com,CN=blah,... RFC2253 format will report: 1.2.840.113549.1.9.1=#<hex string>,CN=blah,... This cause issuer distinguished name not to be identified.
Suspected, but un-verified problem : WS Security makes use of this as X509 issuer name, serial number token. Using the class org.apache.xml.security.keys.content.x509.XMLX509IssuerSerial. However, the issuer DN is not RFC 2253 format. Therefore, the issuer DN cannot be identified after transportation because the represantation is not unique.
(In reply to comment #1) > Suspected, but un-verified problem : WS Security makes use of this as X509 > issuer name, serial number token. Using the class > org.apache.xml.security.keys.content.x509.XMLX509IssuerSerial. However, the > issuer DN is not RFC 2253 format. Therefore, the issuer DN cannot be > identified after transportation because the represantation is not unique. The WS Security implementation can workaround this by reparsing the DN into a strict RFC 2253 format, ex: String dn = new X500Principal(issuerSerial.getIssuerName()).getName(); Can you report this issue to them? Your previous suggestion would also work, but unfortunately this would create a dependency on JDK 1.5 for Apache XML Security and I'm not sure everyone is ready to make that leap yet. Hopefully soon though, maybe the next release.
Closing old bugs.