Help configuring Google VM to reuse an existing cert


#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. https://crt.sh/?q=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:
dicom-viewer-test.isb-cgc.org

I ran this command:
sudo certbot --nginx -m ir-team@isb-cgc.org -d dicom-viewer-test.isb-cgc.org --redirect --agree-tos --non-interactive

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for dicom-viewer-test.isb-cgc.org
Waiting for verification…
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/nginx/nginx.conf
Redirecting all traffic on port 80 to ssl in /etc/nginx/nginx.conf


Congratulations! You have successfully enabled
https://dicom-viewer-test.isb-cgc.org

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=dicom-viewer-test.isb-cgc.org


IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/dicom-viewer-test.isb-cgc.org/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/dicom-viewer-test.isb-cgc.org/privkey.pem
    Your cert will expire on 2019-02-02. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot again
    with the “certonly” option. To non-interactively renew all of
    your certificates, run “certbot renew”

  • Your account credentials have been saved in your Certbot
    configuration directory at /etc/letsencrypt. You should make a
    secure backup of this folder now. This configuration directory will
    also contain certificates and private keys obtained by Certbot so
    making regular backups of this folder is ideal.

  • If you like Certbot, please consider supporting our work by:

    Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
    Donating to EFF: https://eff.org/donate-le

My web server is (include version):
nginx 1.14.0
The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

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


#2

Oops, didn’t explain my issue:

I need to reinstantiate this node (a Google VM) from time to time, particularly during development. The certbot command line that I am using seems to cause Let’s Encrypt to create a new cert each time I call it, and I have run into the rate limit on new cert’s on another subdomain (which is now out of commission for a week ).

What I want to know is how to start certbot such that it gets the existing cert if one exists, and, ideally, creates a new one if there is no existing cert.

Thanks for your help.
Bill


#3

…and, BTW, I have looked at the certbot documentation but am unsure just what an authenticator does that is different from an installer. The documentation says an authenticator validates that you control the domain(s) you are requesting a certificate for, obtains a certificate for the specified domain(s), and places the certificate in the /etc/letsencrypt directory on your machine." While an installer is “used with the install command to install a certificate.”
What is the difference between placing a certificate in /etc/letsencrypt and installing a certificate?

Thanks again.


#4

Hi,

I’m sorry but if you want to ask certbot to pull the existing certificate (already issued before but not in this server…), it will not be able to do so. Even if certbot is able to pull the certificate (pem file) from server, it’ll not able to pull the private key (which is generated before the validation process, and will never be send to let’s encrypt server (or other servers)…

In this case, it’s better to make backup (snapshot) before you destroy the previous instance… Then recover the instance accordingly.

The authenticator will process the validation procedure that are send from let’s encrypt validation servers… After satisfing the request and store the certificate in a directory, the job as a authenticator is done…

If you only specify authenticator without install the certificate, the certificate will only exist in your file system but will not present in ssl sessions. (If you get the certificate without install it… It’s like purchasing a certificate from other commercial provider via web based interface and never deployed it into any web servers ----- the connection to those website will not be secured automatically)

Hope this would help you… (I’m really bad at explaining things…)

Thank you


#5

Thanks Steve, I think I understand.

Bill


#6

A couple more questions:
My understanding is that on reinstantiating a VM (spinning up a new VM with the same domain as a previously running VM), I should do the following:

  • Install certbot
  • Create/restore /etc/letsencrypt from previously saved version
  • Create/restore /etc/nginx/nginx.conf from previously save version
    Can I just completely replace the entire /etc/encrypt from a previous snapshot?
    Anything else I need to do?

Also, I assume that renewing a cert preserves all the keys. Is that correct? I.E. I’m assuming that renewing a cert doesn’t generate new keys which would then have to be cached.

Thanks again,
Bill


#7

By default, Certbot generates a new key for every certificate issued. Newer versions of Certbot have a --reuse-key option.

(Certbot normally reuses your account, though.)