This article was written by Andres Hering, Telekom MMS specialist for system engineering.
As we have to deal with ssl certificates for our customers on a daily basis we regularly need to create or renew certificates and also distribute these certificates to our servers.
Sometimes delays occur during certificate orders or we simply forgot to monitor the certificate expiration time (shame on us). How cool would it be to do this stuff automatically, to not have to rely on a human to remember when it is time to renew a certificate and do it with some kind of selfservice? Another nice side effect would be the increased security as certificates are only valid for 90 days.
Our first step towards this vision was done in the end of 2019 with an Ansible role which used certbot to issue certificates and some basic ansible modules to distribute the files to the servers.
This helped us a lot and made us faster most of the time. But we had several problems with this. For one, we did only integrate the possibility for HTTP challenges and thus couldn’t issue wildcard certificates. Second, the usage of certbot was not what is called the Ansible Way. Also certbot is another package we would have to update and have an eye on all the time. It was also a bit clunky with all its configuration options.
So we sat down again and expanded the role with the posibility to do DNS challenges. Thanks Sebastian Gumprich this was implemented with plain ansible modules and the use of our DNS providers AutoDNS API. These steps were more convincing to us and therefore we also refactored the HTTP part to work this way.
After testing and integrating it in one of our services we decided to migrate the role to an Ansible collection and also publish it on Github and Ansible Galaxy. Our hope was to help others with the same task and develop the role further.
We already had some more improvements for the collection in our minds. For example some kind of modularization for different services which are used in the HTTP and DNS challenges.
The first step into this direction was done shortly after publishing the collection at Github from Michaela Mattes. She implemented the posibility to use AzureDNS for DNS challenges.
If you are asking what happened to the distribution of the certificates to the servers:
We dropped it (for now)! There are so many possible ways and targets to distribute the files that we decided to not implement it in the collection and let users take care of this for themselves.
In conjunction with Gitlab or any other scheduling capable system you can fully automate the tasks of issueing and distributing the certificates.
Here is one example playbook for issueing a wildcard certificate:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
- name: create the certificate for *.example.com hosts: localhost roles: - letsencrypt vars: domain: certificate_name: "wildcard.example.com" zone: "example.com" email_address: "ssl-admin@example.com" subject_alt_name: - "example.com" letsencrypt_do_dns_challenge: true letsencrypt_dns_provider: autodns account_email: "ssl-admin@example.com" private_key_content: !vault | $ANSIBLE_VAULT;1.1;AES256 .... dns_user: "example_dns" dns_password: !vault | $ANSIBLE_VAULT;1.1;AES256 ... |
More examples can be found in the collection.
If you want to be part of this, find bugs or want to support us feel free to create issues or pull requests directly at Github.
You got curious? Then also take a look at…
> Our job vacancies in IT operations
Cloud Application Management
How to harmonise individual applications and cloud with advantages of DevOps-Teams and automatisation
Looking for more open source blog posts?
Ob Digitalisierungsexpert*in, Werkstudent*in oder Schülerpraktikant*in – Hier berichten unsere Gastautoren aus ihrem Alltag.
