qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Scholz <ja...@scholz.cz>
Subject Re: Using Qpid Dispatch (with C++ broker)
Date Fri, 28 Aug 2015 13:54:35 GMT
Thanks for the clarification regarding the certificate databases. As I see
it, the trustedCerts might be useful in case you don't use CAs but directly
the end user certificates. This is what I usually use with self-signed
certificates. In such case you don't wont to have them all listed during
the SSL handshake, because each certificate = user account. So one can use
the trustedCerts to override it. That is nice.

However, that brings me to another question ... the C++ broker is using the
NSS library which distinguishes between trusted peer (only the trusted peer
it self can connect, certificates signed by the peer will be rejected) and
trusted CA (certificates signed by the trusted CA can connect). Do you have
by coincidence an idea how Proton / OpenSSL deals with this? There is no
trusted peer / CA flag in the certDb.

Thanks & Regards
Jakub

On Tue, Aug 25, 2015 at 8:19 PM, Cliff Jansen <cliffjansen@gmail.com> wrote:

> The certDb (proton:
> pn_ssl_domain_t::pn_ssl_domain_trusted_certificate_db) is the
> database/collection/store of CA certificates which are used to
> validate the authenticity of the peer's certificate (client or
> server).  For self signed certificates, at least the public portion of
> the certificate itself must be in the database (since it is its own
> CA).
>
> The trustedCerts (proton
> pn_ssl_domain_t::pn_ssl_domain_set_peer_authentication) is a
> server-only attribute specifying the list of CA's that will be
> included in the "client certificate request" portion of the first SSL
> handshake packet from the server to the client.  In theory, Proton
> could allow the application examine this list and provide its
> preferred client certificate for that server, but it currently
> requires a single certificate to be specified before socket creation,
> and it does not change during SSL negotiation.  Proton could also
> allow the server to change the list based on the client's IP address
> or other client hello context, but again the value is fixed before
> listener socket creation.
>
> I am not sure if there is a good use case to specify the two with
> different values for messaging applications requiring client
> certificates, but the ability is there for the static case.  They are
> separately (and dynamically between handshake stages) configurable in
> both OpenSSL and SChannel, so it is clear some SSL applications need
> the flexibility.
>
> On Mon, Aug 24, 2015 at 7:58 PM, Ted Ross <tross@redhat.com> wrote:
> >
> >
> > On 08/19/2015 11:15 AM, Jakub Scholz wrote:
> >>
> >> I spent some time playing with Qpid Dispatch (0.4) in combination with
> >> Qpid
> >> C++ broker. I was impressed about what it does already. Big +1 to
> everyone
> >> involved.
> >>
> >> I still run into some issues / limitations / questions ... maybe someone
> >> can help with them ...
> >>
> >> 1) Is there some technical reason why the linkRoutePattern isn't allowed
> >> to
> >> contain any periods (well, apart the one at the end) and why it has to
> end
> >> with a period? In my use case, almost every address name contains
> several
> >> periods in it and in many cases the important part in the address is
> only
> >> after the last period. So it would be very useful to be able to use
> >> multiple periods in the linkRoutePattern prefix and to be not required
> to
> >> end the prefix with a period.
> >
> >
> > There is no technical reason for this limitation.  It was done for
> > expediency to prove the link-routing concept.  This should be expanded to
> > match any pattern.
> >
> >>
> >> 2) The Listener allows to configure the certDB and trustedCert
> parameters.
> >> I thought that one is for CAs and one is for self signed certificates.
> But
> >> it doesn't seem to be that easy. Can someone explain how are they
> supposed
> >> to work?
> >
> >
> > This functionality comes straight from Proton.  It is my understanding
> that
> > certDB can be for CAs or self-signed certs.  The trustedCert parameter
> can
> > be used to constrain the set of certificates in the DB that are
> considered
> > trusted for this listener.
> >
> > Perhaps someone else can provide some more clarity.
> >
> >>
> >> 3) In the configuration file, what is the relation between "router",
> >> "container", "listener" and "connector"? Is there some kind of hierarchy
> >> between them? It almost seems that "router" and "container" are entities
> >> which always apply to the whole Dispatch process and can be used only
> >> once.
> >> Is that correct?
> >
> >
> > That is correct.  In fact, we plan to combine the configuration in
> > "container" and "router" into a single section (probably router) to
> reduce
> > the confusion.
> >
> >>
> >> 4) The DISPATCH-58 issue seems to be quite annoying - are there any
> plans
> >> to fix it?
> >
> >
> > Yes, I'm planning a refactor of the ingress links that will improve the
> > ability to use flow control across the network.  This will likely improve
> > the DISPATCH-58 issue.
> >
> >>
> >> Thanks & Regards
> >> JAkub
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message