How to use "certbot install" to install existing SSL certificate

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: www.optarix.com

I ran this command: certbot install --nginx --cert-name www.optarix.com --fullchain-path /tmp/ssl-certificates/fullchain.pem --key-path /tmp/ssl-certificates/privkey.pem --non-interactive --agree-tos --no-eff-email --email XXXXXXXXXXXXX@gmail.com

It produced this output: Path to certificate or key was not defined. If your certificate is managed by Certbot, please use --cert-name to define which certificate you would like to install.

My web server is (include version): nginx 1.27.0

The operating system my web server runs on is (include version): Debian GNU/Linux 12 (bookworm)

My hosting provider, if applicable, is: container running on AWS EC2 instance

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 2.1.0

More details:
I have copied all files in /etc/letsencrypt/live/www.optarix.com to a secure location (S3) and then tried two different target directories copying them back:

  1. /etc/letsencrypt/live/www.optarix.com
  2. /tmp/ssl-certificates

Then I ran the above command with the respective paths for parameters "--fullchain-path" and "--key-path". No luck. I also tried the set permissions as follows:

chmod 644 /tmp/ssl-certificates/fullchain.pem
chmod 600 /tmp/ssl-certificates/privkey.pem

again, for both options. However, in all cases I got the same error message.

Searching for "certbot install" gives me a gazillion hits on how to install certbot. However, that's not what I'm looking for. I also consulted the user guide. It mentions the "install" command but without details or examples.

One more detail I should mention: I'm using "--staging" when requesting a new certificate as I don't want to switch to production SSL certificates unless everything works.

What I want to achieve is this: Try to get existing certificate from secure, permanent storage (S3), if not successful, get new certificate and configure nginx (this part works). If successfully downloaded existing certificates, install existing certificate (this part doesn't work). In all cases set up cron job to renew automatically.

I also tried Perplexity.ai but it either misunderstands it as trying to install certbot or it gives me a list of broken links. So, not much luck there either. A standard web search doesn't help either (see above). Searching this forum for "certbot install" doesn't suggest useful posts either.

Am I on the wrong path? All pointers welcome!

2

Your idea is okay but the "file" in /etc/letsencrypt/live is actually a symlink to a file in .../archive

So, when you copy back from S3 you clobber that symlink which "breaks" Certbot setup

You should make dedicated secure folder for certs for nginx in your EC2 instance. Then, use a Certbot --deploy-hook to copy every fresh cert to that location and also trigger copy to S3

When restoring from S3 copy to this separate nginx cert folder only

You will also want to backup / restore the Certbot folders preserving symlinks. And of course a way to restore Certbot itself (via reinstall or backup/restore)

Make sense?

5 Likes
3

Thank you @MikeMcQ ! Very much appreciated!

Yes, that makes sense and it looks like an option that I'll keep in mind and experiment with.

I also realized that I can reframe the problem as "backup / restore" and then search results become more meaningful. I also need to consider that the files in the "live" directory are actually symbolic links to the "archive" directory. My current approach doesn't consider that yet. I have found this post which looks at options for addressing that particular issue: CertStorageError: expected /etc/letsencrypt/live/example.com/cert.pem to be a symlink

Again, thank you, Mike! This gave me a range of additional pointers that I'll be exploring, including your suggestion.

4 Likes
4

Sure. Also keep in mind that read/write to S3 can fail at any time. You should account for that. There have also been longer outages although these are rare. Still, be careful to not assume this is 100% available at an instant.

4 Likes
5

This is what I ended up doing, and which appears to work:

  1. Make sure nginx is running
  2. Try to download file "certbot_backup.tar.gz" from S3
  3. If not successful, run "certbot --nginx --staging --non-interactive --agree-tos --no-eff-email --email XXXXXXXX@gmail.com -d www.optarix.com", followed by "tar -czvf certbot_backup.tar.gz -C /etc letsencrypt" to create a tarball, and then "aws s3 cp certbot_backup.tar.gz s3://$S3_BUCKET_NAME/ssl-certificates-optarix-com/"
  4. If step 1 was successfull, then execute "tar -xzvf /tmp/ssl-certificates/certbot_backup.tar.gz -C /etc" to extract the tarball, followed by "certbot install --nginx --email your_email@example.com --agree-tos --cert-name www.optarix.com -d www.optarix.com" to install the certificates

For the renewal I'll be setting up a cron job that uses "certbot renew --nginx" to renew the certificates. If there are new certificates, I'll use "tar -czvf certbot_backup.tar.gz -C /etc letsencrypt" to create the tarball with all of letsencrypt's data and then "aws s3 cp certbot_backup.tar.gz s3://$S3_BUCKET_NAME/ssl-certificates-optarix-com/" to move the tarball to S3.

I'm aware that S3 may or may not be available. For this particular use case this is an acceptable risk. According to my favorite DevOps engineer, he has not experienced an S3 outage from within AWS in the last 10 years. In the unlikely event of S3 not being available from within AWS, then the app in my particular use case will become unavailable anyhow.

Note that for "tar" do NOT use the option "-h" because it will follow symbolic links instead of preserving them. The solution described above is the only example that I am currently aware of that demonstrates a working case of using "certbot install". Hopefully this helps others as well!

Thank your again @MikeMcQ for your thoughts! They were instrumental for creating additional ideas for further research and finally solving this puzzle. Very much appreciated!

1 Like
6

There was a significant outage as recent as 2017. I think the most recent was just a few years ago but was just excessive get/put failures for an hour or so. Perhaps was only my AZ.

Occasional failures of get and put happen which resolve with simple retry mechanisms. Probably most don't notice this as much tooling does that automatically. My S3 mirroring system reports every get/put failure. So, a brief panic ensues until I see the retry worked.

I guess my personal experience varies from your fave DevOps person :slight_smile:

4 Likes
7

You generally just do certbot renew without extra options. The renew uses the options stored in the renewal config file (in ../renewal/)

If in the future you use other methods putting --nginx on the renew would override them.

Are you sure --staging is correct here? That is fine for testing but gets a Staging cert which will not validate by production user-agents

Personally I would not rely on --nginx as installer. I would use certonly --webroot method and configure nginx manually. Then, use normal backup/restore of nginx config for its operation. If you store the certs for nginx in a separate folder (away from Certbot's folders) just backup those certs too to have a self-contained working nginx system.

Then, you operate Certbot just for getting/renewing the cert. Your nginx can run or be restored independently of a working Certbot install and function.

I say that because it is actually what I do (although I don't use Certbot but a different ACME Client with similar feature).

But, there is no one right answer here. Just further food for thought.

4 Likes
8

@MikeMcQ You are right. The "--staging" is not part of the solution and should be removed once everything is working. I am still using "--staging" at the moment. Only, once everything works as required, then and only then I will remove that option in my case.

2 Likes
9

Perhaps to take away some of the mystery of what "install" does. Certbot bases the config on:

Updated to match Certbot default for stapling

2 Likes
10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.