[
https://issues.apache.org/jira/browse/DISPATCH-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17095331#comment-17095331
]
Keith Wall commented on DISPATCH-1635:
--------------------------------------
I *think* delivering this might invoke a Proton API change
(pn_ssl_domain_set_peer_authentication) as it currently has responsibilities
for setting the client CA and putting OpenSSL into SSL_VERIFY_PEER |
SSL_VERIFY_FAIL_IF_NO_PEER_CERT mode.
> Allow listener to specify an optional request for TLS client auth
> -----------------------------------------------------------------
>
> Key: DISPATCH-1635
> URL: https://issues.apache.org/jira/browse/DISPATCH-1635
> Project: Qpid Dispatch
> Issue Type: Improvement
> Reporter: Keith Wall
> Priority: Minor
>
> Dispatch Router currently allows the user to configure a *mandatory
> requirement* that TLS client authentication must be used for connections to a
> TLS port.
> For some use-cases it is desirable for some clients to use TLS client-auth
> and some clients to authenticate via other means. In Java parlance this mode
> of operation is describing as
> [Wanting|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/javax/net/ssl/SSLServerSocket.html#setWantClientAuth(boolean)]
> TLS client auth rather than
> [Needing|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/javax/net/ssl/SSLServerSocket.html#setNeedClientAuth(boolean)].
> It would be convenient if the configuration of TLS client auth in Dispatch
> Router permitted the Want semantics.
> Currently with Dispatch Router to achieve this you need to configure two TLS
> listeners, one with authenticatePeer: yes set true and the other not.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
