[
https://issues.apache.org/jira/browse/QPID-4875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
JAkub Scholz updated QPID-4875:
---
Description:
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.
was:
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=CR,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.
[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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
