Hello Willy, On Thu, May 31, 2018 at 9:02 PM, Willy Tarreau <[email protected]> wrote: > Hi Aurélien, > > On Thu, May 31, 2018 at 11:01:44AM +0200, Aurélien Nephtali wrote: >> Anyone has more comments, ideas or remarks regarding these patches ? > > Not on the patches themselves, but I think I mentioned elsewhere that > we really need to start an important discussion on the subject of how > to designate a certificate in general. Indeed : > - with crtlists (and even without) it's possible to have overlapping > identifiers, the first matching one wins. There are even multiple > key types for a same SNI. > > - within a frontend there can be multiple bind lines. It's perfectly > possible to use different sets of certs on two distinct lines, for > example one for the public connections, and another set using the > internal CA for the internal connections. Thus the frontend+SNI > may not always be enough. And in fact this type of setup is not > so rare, especially in places where you have content contributors > who are required to present their client cert from outside but > not from inside, where the security is much more relaxed, but > the internal certs are exclusively used inside with a dedicated > CA to avoid any accident.
I "addressed" this issue by allowing certificate updates ONLY if the bind line has a name. Currently, the only way to specify a particular bind line of a frontend is using the luid but it is not very user friendly. The new solution may not be perfect but it is easier to test the feature this way. > - at the moment cert file names are unique (one cert per file only), > thus at first glance it could sound like files could be used as a > unique identifier as is done with ACLs and maps. And it would > ensure that the change can be made both on the FS and on the CLI. > But with the ability to load certs from dirs, most of the time I > fear that an agent connecting to a CLI will have no idea at all > about the cert's original file name. The one adding a new cert > will figure the name as it currently does to save it before > reloading. But an agent designed to simply update a cert (eg: > let's encrypt) could very well be totally unaware of its path. > > - there are probably other unique ways to identify them that I'm > not thinking about > > Thus I think it's important that a decision is taken on this and that > we don't come back in 3 months saying "hmmm finally it was a bad idea, > I cannot manage this setup with it". > > Ideas or experience feedback from anyone is welcome here. We also need to agree on the payload format to use in the add command: only the PEM certificate is supported at the moment but when there will be OCSP + SCTL support it will become messy very quick. In my tests I am using something like "cert=[...] ocsp=[...] issuer=[...] sctl=[...]" but it is not pretty. I thought of using an INI file format but it is not very handy if you have to craft a file just for one operation. The CLI default maximum line size may barely be enough to hold the certificate but it will definitely not be if OSCP and stuff are used. This can be addressed by supporting payload streaming like you mentioned before. -- Aurélien Nephtali
