If you have set both the "basic constraint" and "extended key usage" fields AND marked them both critical, then I believe you are being limited by the RFC5280 section 6.2 murkiness exception for self-signed certificates.
Cliff On Mon, Aug 31, 2015 at 6:50 AM, Jakub Scholz <ja...@scholz.cz> wrote: > BTW: I played with the CA:true / CA:false extensions and it doesn't seem > that OpenSSL in Dispatch really cares about them. > > On Mon, Aug 31, 2015 at 9:32 AM, Jakub Scholz <ja...@scholz.cz> wrote: > >> Hi Cliff, >> >> Yes, you perfectly described how we use the NSS database in qpidd today. >> >> I was wondering whether the CA:false and CA:true can play a role. I will >> test it to see. >> >> The idea of using the intermediate CAs to avoid the revocation list is >> interesting, I didn't though about it before, but it sounds like an elegant >> solution. The problem is that using custom CA and sign the certificates for >> few hundred customers is often quite painful. On the other hand, the self >> signed certificates also cause trouble here and there, so maybe it is >> really time to get rid of them. >> >> Thanks & Regards >> Jakub >> >> On Sun, Aug 30, 2015 at 9:13 PM, Cliff Jansen <cliffjan...@gmail.com> >> wrote: >> >>> Hi Jacob, >>> >>> I believe you have been using the NSS trustargs to do special >>> authentication configuration. Something like assign "T" to a dummy >>> cert and store client certificates in your list of CAs with an >>> appropriate trustarg so that they could validate as a leaf certificate >>> only and not as an intermediate CA (signing arbitrary credentials). >>> >>> Proton's trustedCerts can get you part way there, but I'm not >>> convinced of the rest is possible. NSS uses the trustargs attribute >>> to augment or override attributes on the certificates themselves. To >>> the best of my knowledge OpenSSL and Java crypto only use the >>> attributes contained in the actual certificate (Windows certificates >>> can have limited different meaning depending on which store they live >>> in). >>> >>> In theory, you can require the self-signed certs that you use to have >>> the proper X509v3 extensions that correspond to the NSS trustargs you >>> rely on, otherwise you reject them as malformed before you insert them >>> in your CA database. The extensions would presumably be: >>> >>> Basic constraint: CA:false (critical) >>> Key usage: Digital signature/key encipherment (critical) >>> Extended key usage: TLS Web Client Auth (only, no signing) >>> >>> That may work as you intend for OpenSSL and Dispatch. >>> >>> However, I do not recommend this as your preferred approach. The fly >>> in the ointment is RFC5280 section 6.2 which essentially says: the >>> rules in this RFC are deliberately murky when using self-signed certs >>> as CA's... implementations can do what they want. >>> >>> >>> As an alternative that works more within stricter rfc5280 rules, >>> perhaps you could do something like: >>> >>> You become the root certificate authority >>> Users send you a CSR >>> You create a unique intermediate CA for each user from the root >>> Use this CA to sign this one CSR using the constraints you like >>> Import each intermediate CA into your CA database but not the root >>> >>> Here a stolen user private key cannot be used to create fake >>> credentials. You can remove the intermediate CA at will to revoke the >>> client certificate (without using the formal revocation list >>> mechanism). Predictable rfc5280 validation will occur on all >>> platforms. Disclaimer: I haven't actually tried this and I'm mostly >>> guessing at your use case. But I do worry that using self-signed >>> certificates as you currently do will require reworking all your >>> certificates each time you add a future component (Java broker, >>> Windows thingamajig). >>> >>> Cliff >>> >>> On Fri, Aug 28, 2015 at 6:54 AM, Jakub Scholz <ja...@scholz.cz> wrote: >>> > 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 <cliffjan...@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 <tr...@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-unsubscr...@qpid.apache.org >>> >> > For additional commands, e-mail: users-h...@qpid.apache.org >>> >> > >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org >>> >> For additional commands, e-mail: users-h...@qpid.apache.org >>> >> >>> >> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org >>> For additional commands, e-mail: users-h...@qpid.apache.org >>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
