-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ACME voor TLS certs #334
Comments
@mrvanes ik heb credentials voor de SURFcert acme access voot test, zodat je eea kan uitproberen. |
Gaat het dan expliciet om de vervanging van deze task? En is het cert wat daar gedeployed word een wildcard? En moet certbot dan ook een wilcard cert aanvragen (dan heb je DNS integratie nodig) of voor alle hostnames een subject alt in het cert op laten nemen? |
Ik wil denk ik liever een nieuwe rol, zodat we makkelijker dit eerst op test kunnen uitproberen zonder dat we de rest van het platform raken. Of misschien kunnen we En we hebben geen *-certificaat, maar 1tje met losse SANs. |
Ik denk dat we de tls_letsencrypt kunnen hergebruiken door alleen wat aanpassingen te maken in de te gebruiken ACME server |
Ik kan lokaal geen ACME doen omdat ik geen publieke DNS namen voor m'n VM's heb en naar test kan ik niet deployen omdat ik dan weer niet bij de secrets mag. We hebben destijds geprobeerd om naar een minimale set zonder privileges te bewegen, maar dat leek (toen) een gebed zonder end. |
In de huidige implementatie staan de frontend TLS keys in de configuratie van ansible. Hoewel ze geencrypt zijn, is dit onwenselijk (zie https://wiki.surfnet.nl/display/coininfra/Beleid+toepassing+cryptografie).
Dit moet worden vervangen door een oplossing op basis van ACME. De keys kunnen dan automatisch door ansible op de lb hosts worden gegeneerd en automatisch worden gesigned door SURFcertificaten (zie https://wiki.surfnet.nl/display/SCERTS/ACME)
The text was updated successfully, but these errors were encountered: