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" <[email protected]> > To: [email protected] > 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 <[email protected]> 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 <[email protected]> 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: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > -- -K --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
