Installing Certbot on an AWS AMI
And here’s some notes on installing Certbot on an AWS AMI EC2:
I was having all kinds of issues with the certbot process, after having taken a snapshot and producing an image to duplicate an EC2, resulting in moving one of my services ( https://www.mailaddiction.com ) to its own instance.
The certbot process was complaining with strange errors that were never present on the original instance:
And after spending several hours of googling and trying several different potential fixes, this was the one that solved the problem:
As root:
$> rm -rf /opt/eff.org/*
$> /usr/local/bin/certbot-auto –debug
The above will produce errors, that’s okay, just continue:
$> cd /opt/eff.org/certbot/venv/lib64/python2.7
$> mv site-packages site-packages.sav
$> ln -s dist-packages/ site-packages
$> /usr/local/bin/certbot-auto –debug
Fixed! Now I’m able to run “certbot-auto” to add a wildcard to a domain of mine:
$> ./certbot-auto certonly –server https://acme-v02.api.letsencrypt.org/directory –manual –preferred-challenges dns -d *.mailaddiction.com
And we’re back in business.
Why This Happens
The root cause here is that AMI snapshots capture a point-in-time copy of the filesystem, including whatever state certbot-auto‘s Python 2.7 virtualenv was in at that moment. When that same virtualenv gets reused on a new instance, subtle path or package mismatches between site-packages and dist-packages can surface — even though the original instance never had a problem, because it never rebuilt or re-linked those directories.
A Longer-Term Fix
If you’re standing up new instances regularly, it’s worth migrating off the deprecated certbot-auto script entirely in favor of the officially supported certbot package (via snap or your distro’s package manager). It avoids this entire class of virtualenv drift issue and gets security patches through normal package updates instead of a standalone installer.
Don’t Forget Renewal
Once the certificate issues successfully, confirm auto-renewal is actually wired up — certbot renew --dry-run is the fastest way to check — and that it’s scheduled via cron or a systemd timer. A wildcard cert obtained manually with --manual --preferred-challenges dns won’t auto-renew without a DNS API plugin configured, so plan for that ahead of the 90-day expiry if you went the manual-challenge route above.
General Prevention
More broadly, treat any AMI-based EC2 duplication as an opportunity to rebuild the cert setup cleanly rather than carrying forward whatever state the snapshot captured. A short user-data script that installs and configures certbot fresh on first boot is more reliable long-term than snapshotting a machine that already has a working certificate installed — it costs a few extra minutes per launch and removes an entire category of “worked on the original, broken on the clone” issues.
It’s a small amount of extra automation work up front that pays for itself the first time you need to spin up a replacement instance under time pressure.