Hi aurelien, I already look for adding dynamic certificates, and it is a real pain for me. Note that I look for this one year ago, maybe something changed. I look this development regarding only the basic usage: dynamically update of RSA certificates, and I encountered some difficulties:
- Certificates are also ECDHE and CURVES. I failed because I can’t test these kind of certificates. - ALPN and Cipher suites. If my memory is good, the cipher suite are stored only in the SSL context, and this context is hard or impossible to modify. - Certificates are linked with OCSP. No memories about theses. - Certificates are linked with SNI. SNI and, no SNI have no common parts of code for the certificate storage. Some of these information are stored only in the SSL Context and I can’t find any way to retrieve it for creating a new SSL context. I also fail to modify existing context. I suggest you to check the update way thought the code between coding the socket interface. My conclusion was a little refactoring of the SSL parts for making coherent structs. Maybe storing some configuration with clear text and into the SSL context ? For information, I join my first patches of dynamic SSL certificates and refactoring patch, before I stop this job because I do not have the requested time for doing it cleanly. The patches are provided as is. One serie is on the 1.8 branche, the other one on the 1.6. Some of these patch are qualif, other ones are work in progress. Sorry, but the WIP patch have french comments :-) BR, Thierry
1.6.9-based-0001-MINOR-ssl-export-the-function-ssl_sock_get_serial.patch
Description: Binary data
1.6.9-based-0002-BUG-MINOR-ssl-Check-malloc-return-code.patch
Description: Binary data
1.6.9-based-0003-BUG-MINOR-ssl-prevent-multiple-entries-for-the-same-.patch
Description: Binary data
1.6.9-based-0004-WIP-certifs-a-la-avol-e.patch
Description: Binary data
1.6.9-based-0005-wip2.patch
Description: Binary data
1.8-based-0001-MINOR-ssl-use-BIO-api-for-reading-certificates.patch
Description: Binary data
1.8-based-0002-MINOR-ssl-split-load-cert-in-two-parts.patch
Description: Binary data
1.8-based-0003-wip.patch
Description: Binary data
1.8-based-0004-wip-2.patch
Description: Binary data
> On 6 Mar 2018, at 15:14, Aurélien Nephtali <aurelien.nepht...@gmail.com>
> wrote:
>
> Willy,
>
> On Tue, Mar 6, 2018 at 2:30 PM, Willy Tarreau <w...@1wt.eu> wrote:
>> More or less. I'd rather return a 3rd case, like with do with samples :
>> "not sure yet" (need more data to decide). That allows the failure and
>> success cases to remain definitive.
>
> Indeed, that what I was trying to say with: "to wait until a keyword
> handler says it is ready to process the command" :) : it will keep
> saying "need more data" until it can decide and say "OK I continued
> and processed the command" or "I couldn't process it".
>
>> I just don't know exactly what is *currently* used. And we make it a
>> hard rule not to break existing deployments on purpose. People write
>> management scripts, utilities etc and purposely breaking their API is
>> really not fun at all. This is the *only* reason here.
>
> And I fully agree with that, I want to add the feature without being
> too intrusive or being non retro-compatible.
>
>> I think we're in sync on this. Please take a look at OCSP to see how it's
>> currently handled so that we don't have to imagine all possibly stupid
>> cases. Also take a look at {set|add} {acl|map} and I think that should
>> be all for now to get the whole picture of the compatiblity we have to
>> maintain.
>>
>
> I will do that and check if everything can fit in.
>
> Thanks !
>
> --
> Aurélien Nephtali
>
