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!
Responses and reactions
Replies
When I learned about Let's Encrypt, I immediately started to like the idea of managing it through WordPress. Rather an experimental approach, but this is what came out of it: https://wordpress.org/plugins/wp-encrypt
Obviously one still needs to adjust the server configuration (which cheap hosts usually don't allow) - it would be great if a plugin could make the entire process easy enough so that we could have almost all WordPress sites have SSL, even those maintained by people who don't care about servers and code.
Curious what you think about this.
I solved that same Python 2.6 issue on CentOS 6 with Software Collections. Software Collections are kinda weird, and I'm not sold on using them for everything, but they are perfect for solving this kind of problem where you need multiple versions of something on the same machine.
I also included how I automated this to do auto-renewal. I really like how each LetsEncrypt has made the renewal process once you figure out how to get the cert issued the first time.
https://thelastcicada.com/solving-the-python-2-6-issue-for-letencrypt-on-centos-6
It's great that you've got free SSL, what do you plan to do on Feb 10th, 2016?
That's the beauty of Let's Encrypt. I'll be able to hop on the server and run the same command to renew the certificate for the next 90 days. At some point, the process will be stable enough to automate.
The only requirement for your mention to be recognized is a link to this post in your post's content. You can update or delete your post and then re-submit the URL in the form to update or remove your response from this page.
Learn more about Webmentions.