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
