Right now with nginx we can pick the certificate being used to serve traffic by simply setting public_tls_unified_cert_vendor to the name of the certificate, (digicert-2019 or globalsign-2018) while with ATS we currently need to set a whole structure with several paths and filenames, making it more prone to errors.
|Stalled||Vgutierrez||T230687 Decide/document criteria needed to serve acme-chief LE issued unified certificate to end users|
|Resolved||Vgutierrez||T234803 Provide an easy way of picking the traffic serving TLS certificate used by ATS|
- Mentioned In
- T233274: ATS lua script reload doesn't work as expected
T209515: Renew Digicert Unified in 2019
T230687: Decide/document criteria needed to serve acme-chief LE issued unified certificate to end users
- Mentioned Here
- T231627: Move cache text cluster from nginx to ats-tls
T233274: ATS lua script reload doesn't work as expected
Notes from IRC, etc:
The current patch (merging shortly: https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/541220/ ) gets us part of the way there, enough to deploy dual commercial certs again across ATS + nginx. What we need to do beyond that in the near to medium term is:
- Reduce some of the duplication in the hieradata (the common SNI-check blocks, etc)
- Cover deployment of the lets-encrypt / acme_chief case to all nodes based on it being in the defined set of cert options (currently it's only deployed in eqsin; turning it on elsewhere via ucv hieradata wouldn't work)
- Fix the issues around ATS not handling a switch of directory paths with a simple reload, since commercial and LE cert options current have distinct directory paths. This means we'll have to create some universal paths for ATS's access to the unified cert/key/ocsp which are symlinks out to the appropriate commercial or legacy paths as appropriate.