Let's Encrypt was difficult not to notice of. It's a new certificate authority providing free certificate signing for everyone. And on top of it the whle process of registration, certificate signing, renewal and revoking can be scripted and automated by the CA provided client tools. The tools can even automatically reconfigure the most popular web servers (Apache and Nginx). It has a drawback though: The client itself is quite a big pile of Python scrips with heavy dependencies. Moreover the Python 2.6 support is marked experimental. Not quite perfect match to CentOS 6.
This server actually runs on CentOS 6. It's not only because it was the latest CentOS available when I first installed it. I still keep the system since RHEL-7 and therefore CentOS 7 dropped the 32bit x86 support. Given the machine is a cheap rented VM with little disk space and memory, the 64bit architecture would be a really wasteful choice.
The good news is that Let's Encrypt builds on open ACME protocol and the smart people on the Internet came with alternative clients requiring much fewer dependencies and resources.
The one that looked to be the one suitable for my underpowered ancient server seemed to be letsencrypt.sh. It's a Bash script requiring only curl and openssl. And the good news is: it really works and getting it to work is actually pretty simple.
For those who would want to give it a try on CentOS/Fedora: I've build rpm packages for myself in COPR (COPR is quite broken these days: the builds might show as fail though the packages are there). Thepackage contains just a few files:
/etc/letsencrypt.sh /etc/letsencrypt.sh/config.sh /usr/bin/letsencrypt.sh /usr/share/doc/letsencrypt.sh /usr/share/doc/letsencrypt.sh/LICENSE /usr/share/doc/letsencrypt.sh/README.md /usr/share/doc/letsencrypt.sh/domains.txt.example /usr/share/doc/letsencrypt.sh/hook.sh.example
Obviously, the main /usr/bin/letsencrypt.sh script and its configuration /etc/letsencrypt.sh/config.sh. There are several configuration steps required. First, edit the /etc/letsencrypt.sh/config.sh. First, the default CA URL is set to https://acme-v01.api.letsencrypt.org/directory. For the testing purposes it's wise to point it to a staging API instance at https://acme-staging.api.letsencrypt.org/directory. This will issue invalid certificates but doesn't have that strict quota. Choose a BASEDIR value: this is the directory where the domains configuration file would have to be created, where you would store your private key and also the script would store the ceritificates obtained from the CA. So /etc/letsencrypt.sh/ is a reasonable choice.
The other important thing is the WELLKNOWN directory. That's where the ACME server would look for the HTTP challenge files (see the How it Works document). The script should have write permissions to the directory.
Then set a path to the private key (PRIVATE_KEY) used to identify your Letsencrypt account: you may need to remove it when switching from the staging API to the production one.
The last mandatory field in the config.sh is the self-explanatory CONTACT_EMAIL...
Now for the domains you want to have the certificates issued for: create a BASEDIR/domains.txt file with a simple format:
domain.tld server.domain.tld another.domain.tld nextone.tld andanotherserver.nextone.tld
The important thing: each domain has to be accessible over HTTP and serve the challenge file: make sure to set up the web server accordingly: unlike the oficial client, letsencrypt.sh will not do that for you. The staging API is really great to test your setup.
Once you think you're done:
letsencrypt.sh -c
...and watch the logs. If things work, just create a monthly cron job and enjoy. If not... well, you wouldn't be doing this not knowing the drill already...
All in all: letsencrypt.sh rocks. Thanks to the author.