Re-installing server & other things


#1

Hi,

I’m in the process of installing a server with let’s Encrypt certificates with certbot client.
On test server, I managed to make certioficate to run successfully.
Now, I’m wondering some questions, and cannot really do some tests because I’m afraid of blocking my access due to number rate of certificates, etc…

1st and main question:
On my virtual servers (prod ad test), I’m writing a script so ALL server can be fully installed with it, so in case of super crash, I just have to create new VM (same IP) and run the script.
So, I’m wondering about certbot: how can I re-install certificates, which have previously be done on other server ? I’m afraid if I just run certbot certonly --webroot […], it will tell me certificates have already been created on other server, OR it will create new instances of certificates, instead of retrieving existing ones, and I don’t want to have rate limit issue, etc…
What do I need exactly to get my certificates back, and ready to be setup in my web server ? Of course, I do not want to have pem files only, because I want renew feature to work, as it was on original server…
The answer to this question should take in consideration I have access to working server right now, so I can backup required files to achieve this the day problem occurs.

2: my server is working with Debian Jessie, so I got certbot from backport.
It’s running fine, but certbot version is 0.9.3, and it appears because of this, some newly created features from documentation, are missing: example: “certbot certificates” does not work.
Without upgrading certbot (I would like to stick with apt-get official tested packages), how can I retrieve list of certificates certbot installed on server ?

3: My prod & test servers are sharing same domain. Only subdomains change from one to the others).
In order for everything to work on test & prod server, would you advice me to:

  • Have a different certificate for each machine so I can renew certificates on all ?
  • Share same certificate ? I don’t think that would be a good idea: renew would be difficult if I want this to be automated
    Do you think it’s possible to use same certbot command line on ALL servers (prod & tests), and have different certificates installed, knowing they manage different subdomains ?
    For example: certbot […] --allow-subset-of-names -d prod.domain -d test.domain -d test2.domain
    Theorically, because of allow-subset-of-names, only working domains on current machine should be ok, so it ‘should’ work. Am I right ? If so, how will be named the certificate (0.9.3 version do not have cert-name option): first domain in command line, or first WORKING domain in command line ?

Thanks for your help !!


#2

Hi @ElMac

the dry-run command will help with testing

–dry-run Perform a test run of the client, obtaining test
(invalid) certs but not saving them to disk. This can
currently only be used with the ‘certonly’ and 'renew’
subcommands. Note: Although --dry-run tries to avoid
making any persistent changes on a system, it is not
completely side-effect free: if used with webserver
authenticator plugins like apache and nginx, it makes
and then reverts temporary config changes in order to
obtain test certs, and reloads webservers to deploy
and then roll back those changes. It also calls --pre-
hook and --post-hook commands if they are defined
because they may be necessary to accurately simulate
renewal. --renew-hook commands are not called.
(default: False)

The easiest way to get the certs is to go to \etc\letsencrypt\live and see what certs have been issued


#3

there is also this command

testing:
The following flags are meant for testing and integration purposes only.

–test-cert, --staging
Use the staging server to obtain or revoke test
(invalid) certs; equivalent to --server https://acme-
staging.api.letsencrypt.org/directory (default: False)


#4

Hi and thanks for the answer.
However it does not really answer the questions…

  • Dry-run does not produce any certificate so does not allow me to do the tests I require.
  • Staging is a bit better, but still, generated certificates are not good enough since they are invalid and do not allow to make some certification tests of https website.
    None of those 2 solutions answer the main question: how can I re-install certbot on new server and re-use account and certificates I had on previously server ?
  • Would it work to just “certbot certonly…” on new server knowing it would create new account-Id, or is there a way to register my previously created account, and use it ?
  • What is the problem with using new account-id if such thing had to be done ?
    Etc.

In command line (bash), how can I list domains of previously generated certificates when certbot --certificates is not available (certbot v0.9.3 on Debian backport repository)

Thanks !

Antoine


#5

Hi Antoine

Apologies for that

if you review the contents of the /etc/letsencrypt directory

you will see some key folders

if you would like to copy your dev to production i would suggest copying these folders

for example the accounts folder

contains your account number and private keys

hope this helps

andrei


#6

I saw that, but how to import the account only in a newly installed certbot ? Just copy the account folder ?
Or should I backup the whole folder (but then, it’s quite boring because I would have to backup everythime I renew certificates)

What could be the problem, IF, on new server, I was just ignoring the previous account, and generate all new from scratch. Would it work even if certificates for similar domains have previously been generated on other account ?

Thanks !
Antoine


#7

hi antoine

at this point just try it :smiley:

the time you spend asking questions would be better spent having a go

that would be my next steps (i.e. actually do it and see what happens)

you can review the codebase on github as well

Andrei


#8

Hehe don’t worry, I did already : I work on this for 3 days to find best way to use it for my needs (including security protocol le, such ocsp, hsts, etc.)
My current grade in ssllab is A (I did not implemented hsts yet of course, otherwise it would be A+ :D) by keeping nice compatibility with old browsers (except IE6 haha)

I have answers to some of my questions:

  • Without cert-name option, certificate will be named as first domain declared in command line, EVEN when using --allow-subset-of-names if first domain cannot be validated (so, to name your certificate the way you want you can use fake domain as 1st one)
  • Using same email address on other server does not use same account ID.
    It seems not to be a problem for a issuing new certificates equals to previous ones and I ‘think’ (at least there is no warning, but I did not try to push in order not to block me) I can get rid of rate quotas by doing this… (which would be quite odd, I admit…)

But some questions remain with no answer and cannot really be tested:

  • how to properly import previously created account in certbot (copying accounts folder is probably enough, but isn’t there a cleaner way to do this ?
  • what would be the benefit of doing this ? I.E. : why not just creating new account on newly installed server ?
    Is the answer just: with same account, I’ll be able to revoke/renew previously created certificates (I think I don’t really care on new server except maybe if I use HPKP on my domains, but I don’t. With different account, rate quota is reset to 0.
    I started still don’t know how to get previously created certificates from certbot when --certificates is unavalaible(v0.9.3). Right now, I’m thinking of using OpenSSL on generated pem files, so I’ll know. It’s good enough for my needs, but it cannot work if Idon’t have access to pem files (certificates registered by letsencrypt, with my account, but not on my machine)

/Antoine

PS: sorry if you though I was waiting answers, with opened mouth :wink: I’m not haha but some help can always be nice… so community forums were invented :wink:
Thanks again !! And again ! And again !

Antoine


#9

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