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 :-)


Attachment: 1.6.9-based-0001-MINOR-ssl-export-the-function-ssl_sock_get_serial.patch
Description: Binary data

Attachment: 1.6.9-based-0002-BUG-MINOR-ssl-Check-malloc-return-code.patch
Description: Binary data

Attachment: 1.6.9-based-0003-BUG-MINOR-ssl-prevent-multiple-entries-for-the-same-.patch
Description: Binary data

Attachment: 1.6.9-based-0004-WIP-certifs-a-la-avol-e.patch
Description: Binary data

Attachment: 1.6.9-based-0005-wip2.patch
Description: Binary data

Attachment: 1.8-based-0001-MINOR-ssl-use-BIO-api-for-reading-certificates.patch
Description: Binary data

Attachment: 1.8-based-0002-MINOR-ssl-split-load-cert-in-two-parts.patch
Description: Binary data

Attachment: 1.8-based-0003-wip.patch
Description: Binary data

Attachment: 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

Reply via email to