qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: Using Qpid Dispatch (with C++ broker)
Date Fri, 28 Aug 2015 14:49:39 GMT
Hi Jakub,

Not sure if this answers your Q, but IIRC - a proton server doesn't distinguish a self-signed
CA from a CA signed by a "real" certificate authority.  As far as a proton server is concerned,
if it's in the CA database (pn_ssl_domain_set_trusted_ca_db()) any peer whose certificate
is signed by those CA's (including the self-signed CA) are trusted.

I'm pretty sure that behavior is similar to qpidd's.  If you take a look at qpid/cpp/src/tests/ssl_test,
the peer authentication tests use a self-signed CA.



----- Original Message -----
> From: "Jakub Scholz" <jakub@scholz.cz>
> To: users@qpid.apache.org
> Sent: Friday, August 28, 2015 9:54:35 AM
> Subject: Re: Using Qpid Dispatch (with C++ broker)
> 
> 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
> >
> >
> 

-- 
-K

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message