My first Let’s Encrypt certificate

The timing of the Let’s Encrypt beta could not be more perfect as my previous certificate expires on November 18th. I purposely purchased only a 1 year certificate because I knew Let’s Encrypt was coming. Let’s see how this works!

6:00pm

In my email, I have an invite to Let’s Encrypt for 3 whitelisted domains—jeremyfelt.com, www.jeremyfelt.com, and content.jeremyfelt.com. Per the documentation, I cloned the git repository to a spot on my server—I chose /home/jeremyfelt/—so that I could use the client.

I admit that I haven’t read any documentation up until this point, so I’m flying blind and impatient like normal. 🙂

My first attempt at running the ./letsencrypt-auto command was interesting, but kind of a failure. A ton of dependencies were installed, which is good. I have an outdated version of Python apparently, which is annoying.

WARNING: Python 2.6 support is very experimental at present…
if you would like to work on improving it, please ensure you have backups and then run this script again with the –debug flag!

It took me several attempts before I finally read the message above and figured out that I was supposed to run the Let’s Encrypt command as ./letsencrypt-auto --debug to even pass to the next level. If you have Python not 2.6, this probably won’t be an issue.

Ok. Figured that out, then that crazy fake linux light blue GUI comes up… progress! Go through a couple steps and get this:

Right then. By default, the Let’s Encrypt client wants to be a web server so that it can properly communicate authority. This would be excellent if I didn’t already have a web server running.

At this point, I read down the page of documentation a bit and realized I could (a) use a config file and (b) use text only instead of ncurses. Sweet!

When I setup the default config file as /etc/letsencrypt/cli.ini, I noticed an option for webroot authenticator. This looked more promising as a way to handle authentication through Nginx. I enabled this and tried again.

And failed! “Failed authorization procedure” to be exact. My client told the other side to verify at http://jeremyfelt.com/.well-known/acme-challenge/BIGLONGSTRING, but my default Nginx configuration blocks public access to all hidden files.

I added a location block to Nginx specifically to allow .well-known and tried again.

Success! Authorization worked and a bunch of files were generated that look like what I need. I went into my Nginx configuration and updated the ssl_certificate directive to point at fullchain.pem and the ssl_certificate_key directive to point to privkey.pem. nginx -t has no complaints… let’s restart the server.

Failure! Big red X, invalid everything! The issuing CA is….. happy hacker fake CA.

Oh. Quick Google search and sure enough:

“happy hacker fake CA” is the issuer used in our staging/testing server. This is what the Let’s Encrypt client currently uses when you don’t specify a different server using the--server option like you did in the original post. Because of this, I believe the --server flag was not included when you ran the client. Try running the client again, but make sure you include the --server option from your original post.

Thank you, bmw!

I failed to update the cli.ini file that I had copied from the web to use the production API instead of the staging API.

Fix the server URL, try again. Success! And for real this time.

I repeated the process with www.jeremyfelt.com and content.jeremyfelt.com, making fewer mistakes along the way and that’s that.

• Here’s the final cli.ini file that worked for me.
• And the final command line arguments: ./letsencrypt-auto --config /etc/letsencrypt/cli.ini --debug --agree-dev-preview certonly

6:36pm

I have 3 new certificates. I still have an A+ in SSL Labs. Nothing is broken. The future is here.

Thank you to everyone at Let’s Encrypt!