Hi! Yes, you got it right. I have no idea if there are technical limitations in the SSL library or other parts of the code that would make several certificate/key pairs for the same domain infeasible.
If there were hard restrictions, it could certainly be done "externally" with a set of clever scripts and haproxy reloads, but IMO it would be a less brittle solution if it were built right in. Also, it wouldn't require separate scripts per platform and init system (SysV, systemd, …). Daniel > On 30. Apr 2017, at 11:50, Aleksandar Lazic <al-hapr...@none.at> wrote: > > HI. > > Am 28-04-2017 09:26, schrieb Daniel Schneller: > >> Hello! >> I am managing a few haproxy instances that each manage a good number of >> domains and do the TLS termination on behalf of what you might call "hosted" >> sites. >> Most of the clients connecting to these haproxys implement certificate >> pinning and verify that the certificate presented by the server is on a >> white list for their respective domains. >> We have alerts on upcoming expirations with a few weeks advance notice, so >> that we can tell our customers to get a renewal done with their CA and >> provide it to us. Then clients (mostly mobile apps) get be updated, built >> and released to include both the current and the renewed certificates for a >> while. Once the current cert has actually expired, it will be removed from >> the white list with the next update. >> To give the end users the longest possible opportunity to download and >> install the updated client, we perform the certificate replacement on >> haproxy very close to the actual expiration point in time. >> With an increasing number of domains and certificates, and the tendency >> toward shorter certificate life times, some cert is about to expire all the >> time, making this a rather regular task. >> So I was wondering if there was a better way to achieve the client-friendly >> "last minute" replacements without having to manually care about the exact >> timing and hopefully never making a mistake. >> If haproxy could load multiple certificates for the same domain (similar to >> what it currently already does for wildcard and more specific domain >> certificates), and would additionally consider their expiration dates, >> serving the one with the least remaining validity as long as it was still >> valid, but then automatically switch to an available replacement once the >> expiration is reached, we could just schedule regular (maybe daily) reloads >> (to let haproxy read any new files in) and just drop any renewed >> certificate/key files into the appropriate directory as soon as you got them. >> I would welcome feedback on this idea, if only to be pointed at the obvious >> and glaring shortcomings it may have :D > > This sounds to me a very interesting use case especially with the let's > encrypt certificates. > > To reflect what I have understand I will try to explain your request from my > point of view. > > mysecurewww.mysecuredomain.xxx will expire 01.02.2017 > This certificate pair will created at 01.10.2016 > > Now you will create another certificate pair on 07.01.2017 with the same name > and add it to haproxy, right? > > This ends up with 2 certificate pairs for the same domain but with different > expire time. > Is this possible with the ssl lib? > > Is this the scenario you have described? > >> Cheers, >> Daniel > > Regards > Aleks > >> -- >> Daniel Schneller >> Principal Cloud Engineer >> CenterDevice GmbH | Hochstraße 11 >> | 42697 Solingen >> tel: +49 1754155711 | Deutschland >> daniel.schnel...@centerdevice.de | www.centerdevice.de >> Geschäftsführung: Dr. Patrick Peschlow, Dr. Lukas Pustina, >> Michael Rosbach, Handelsregister-Nr.: HRB 18655, >> HR-Gericht: Bonn, USt-IdNr.: DE-815299431
