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
Cheers,
Daniel
--
Daniel Schneller
Principal Cloud Engineer
CenterDevice GmbH | Hochstraße 11
| 42697 Solingen
tel: +49 1754155711 | Deutschland
daniel.schneller@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
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
Cheers,
Daniel
--
Daniel Schneller
Principal Cloud Engineer
CenterDevice GmbH | Hochstraße 11
| 42697 Solingen
tel: +49 1754155711 | Deutschland
daniel.schneller@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