2

I would like to create a shell script for getting let's encrypt certificates:

#!/bin/bash
sudo docker run -it --rm -p 443:443 -p 80:80 --name certbot \
    -v "/etc/letsencrypt:/etc/letsencrypt" \
    -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \
    quay.io/letsencrypt/letsencrypt:latest certonly

But now I have to provide some infos manually:

  • email address
  • option 2 (standalone)
  • the domain

Is it possible to automate these inputs?

  • Have a look at github.com/google/acme – geek1011 Jan 18 '17 at 3:49
  • 2
    Don't reinvent the wheel if you don't have too. Check into GetSSL as well (GNU GPL3 license). Both are listed on LE's website as Bash clients. – Gypsy Spellweaver Jan 18 '17 at 8:39
  • GetSSL looks nice. But which ACCOUNT_KEY do I have to use? The command which I am using doesn't need a key as it is used on the server.... – user3142695 Jan 20 '17 at 5:27
  • This is going to involve more than a simple comment. Going to convert this into an answer, with what I know about using GetSSL and converting certbot data so you can. With links to sources where possible. – Gypsy Spellweaver Jan 20 '17 at 6:01
4

Don't reinvent the wheel if you don't have too. Someone else, several people actually, has already created a script to automate the process of getting and renewing letsencrypt certificates using a shell script. LetsEncrypt includes a list of third-party clients here.

Because the OP asked about a shell script, this is about one in particular, GetSSL, that I've looked at, experimented with. It's fully open-source and licensed under the GNU GPL3 license. There is also a wiki that covers its use very well, and a link to reporting issues. Additionally, the creator also is very active in the LetsEncrypt Community forum under the name "serverco", and answers questions there as well.

Since it's a shell script, installation is simple. (All paths used here are samples that work for me, but you can change them to suit your needs.) Download the getssl file from the link above into your bin folder. Other places work, of course, but in the bin folder simplifies things. Make it executable. Then run it.

$ wget -O - https://raw.githubusercontent.com/srvrco/getssl/master/getssl > ~/bin/getssl
$ chmod 0700 ~/bin/getssl
$ getssl --create yourdomain.name

The --create option creates the default config file(getssl.cfg) in ~/.getssl and ~/.getssl/yourdomain.name. The first one holds information common to all the domains you might choose to register, and the second one holds the information that is unique to the named domain. If you get certs for more than one domain, each will have its own directory in ~/.getssl, and you need to run the --create command above for each one. The default config files are very well commented, and you can probably configure them without even reviewing the online wiki, although reading ahead of time never hurts (RTFM).

One of the things that can be slightly confusing deals with keys. For the SSL to work, the server has to have a key pair (private/public) for the encryption process. This is called the Server Key. To use LetsEncrypt you also need a key pair for communications with the cert server. This is called your Account Key, or your LetsEncrypt Key.

For the first use of GetSSL, for new accounts, not accounts that are already active, you can make a key very easily with openssl. This command will generate one and store it for you.

openssl genrsa 4096 > ~/.getssl/LE_account.key

If, on the other hand, you already have used LetsEncrypt, somewhere you have the account key already. If so, you must continue to use that same key to renew the certs you have, or to revoke certs if needed. I don't know where other clients keep their copy of the account key, but I have found a resource that explains where the certbot client keeps it. Although written for acme-tiny, this guide explains how to 'extract' the account key from the certbot files.

The GetSSL client expects the account key to be in standard PEM format, but the certbot client stores it in some other format, inside a JSON structure, and this has to be extracted and converted. Doing so uses another tool from JonLundy, that needs python, so even though GetSSL doesn't need python, you will for this. The given process, modified for the sample file structure above, is:

$ wget -O - "https://gist.githubusercontent.com/JonLundy/f25c99ee0770e19dc595/raw/6035c1c8938fae85810de6aad1ecf6e2db663e26/conv.py" > conv.py
$ cp /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory/<id>/private_key.json private_key.json
$ openssl asn1parse -noout -out private_key.der -genconf <(python conv.py private_key.json)
$ openssl rsa -in private_key.der -inform der > ~/.gelssl/LE_account.key
$ rm conv.py private_key.json private_key.der

The final line probably should be replaced with something a little more secure. After all, this is a rather important private key involved. Maybe something like shred -zun13 private_key.json; shred -zun13 private_key.der would be better.

I am not a security expert, nor a server expert, so I am not able to discuss those aspects of GetSSL, or its implementation. They might be better addressed on Server Fault. Nor can I answer most questions about GetSSL. The place to get answers about GetSSL the fastest seems to be on the Community site for LetsEncrypt, where serverco can often be seen. Many others on that forum also deal with GetSSL questions, providing a good pool of answers.

  • Only one question for this great answer: What should <id> be? – user3142695 Jan 20 '17 at 15:15
  • If you used certbot to get certificates it created that path, and there should only be on folder in that position. That folder name is your Account ID, which you would need if you ever contact LE directly for some problem with their system, Note that certbot is not their product, but is from EFF, so problems with that, or any other client, are directed to whomever created/maintains the client, not LE. If somehow you managed to create 2 or more IDs, you need to figure out which one is the live one, and drop the other one. – Gypsy Spellweaver Jan 20 '17 at 18:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.