I just noticed an error that had gone unseen: this very site was serving another site’s HTTPS certificate. I started digging what had gone wrong and noticed that EFF’s Certbot had touched the Apache configurations of this site even though I deployed a cert for another site. It had overwritten the configuration and even added more lines to it.
The devil is in the automation. I have used Certbot a couple of times with the CLI args (-d etc.) and with the GUI. I have used it completely successfully and without any problems, but that doesn’t matter here: I’m 100 % confident that I have not given permission in any GUI or CLI to amend the Apache configurations for this domain name when deploying a certificate for another domain (which was, btw, being served by NGINX). It has to have happened in the background, behind the curtain, you know, where the process is automated – which is also the key selling point of Let’s Encrypt and Certbot, to make it easy and automated.
This of course raises the question whether I’m to blame Certbot or did I do something wrong and actually the service was working as expected. Who knows. I also admit that my VPS setup consists not only of one domain and one IP address, but multiple domains served by both Apache and NGINX from three IP addresses. Nonetheless, I should be able to trust the automation. But the takeaway here, for me atleast, is to write a script to check whether the correct config files and none else were touched during the deployment. Certbot already prints out to you the list of issued certificates, their private keys, and certificate chains. It would be a nice improvement to have a list of all touched files during the deployment just to alert the geek.