[
https://issues.apache.org/jira/browse/QPID-4875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13724011#comment-13724011
]
Rob Godfrey edited comment on QPID-4875 at 7/30/13 4:18 PM:
------------------------------------------------------------
Rather than writing our own parser, did you try the approachsuggested here
http://stackoverflow.com/questions/7933468/parsing-the-cn-out-of-a-certificate-dn
namely something like:
{code}
import javax.naming.ldap.LdapName;
{code}
{code}
LdapName ln = new LdapName(dn);
String cn = null;
for(Rdn rdn : ln.getRdns()) {
if(rdn.getType().equalsIgnoreCase("CN")) {
cn = rdn.getValue();
break;
}
}
{code}
was (Author: rgodfrey):
Rather than writing our own parser, did you try the approachsuggested here
http://stackoverflow.com/questions/7933468/parsing-the-cn-out-of-a-certificate-dn
namely something like:
import javax.naming.ldap.LdapName;
LdapName ln = new LdapName(dn);
String cn = null;
for(Rdn rdn : ln.getRdns()) {
if(rdn.getType().equalsIgnoreCase("CN")) {
cn = rdn.getValue();
break;
}
}
> [Java] The parsing logic for certificate subjects doesn't work properly in
> all cases
> ------------------------------------------------------------------------------------
>
> Key: QPID-4875
> URL: https://issues.apache.org/jira/browse/QPID-4875
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker, Java Client, Java Common
> Reporter: JAkub Scholz
> Priority: Minor
> Fix For: Future
>
> Attachments: cert_parsing.patch
>
>
> The Java code seems to contain two places where the certificate subjects are
> being parsed. One is used in the client:
> {{common/src/main/java/org/apache/qpid/transport/network/security/ssl/SSLUtil.java}}
> and the second is used in the broker:
> {{broker/src/main/java/org/apache/qpid/server/security/auth/sasl/external/ExternalSaslServer.java}}
> Both are actually doing the same - extracting the CN and DC components from
> the subject and creating the username. It should be reconsidered whether we
> want to reuse the SSLUtil functionality from the common part of the code in
> the broker code as well.
> However, a bigger problem is that the implementation in both places are not
> working correctly in all situations. One can very easily create a certificate
> with a subject / DN like this:
> {{C=CZ,O=Scholz,OU="JAKUB CN=USER1"}}
> such certificate actually doesn't contain a CN. But both current
> implementations will still identify the CN as {{USER1"}} in the code. I would
> expect that this will happen only in very rare cases, but it should still be
> handled properly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
