FYI, if you don't want to install anything to try it out, you can use https://gethttpsforfree.com which is a browser-based ACME client. It doesn't ask for private keys, so you don't need to trust it.
This is awesome! Way easier than installing anything that tries to do everything for you, especially if you have a non-traditional setup.
One caveat: AWS CloudFront requires the domain key to be 2048 bits instead of 4096. Other than that, worked flawlessly for me and now www.a1k0n.net is finally SSL capable. Thank you!
I got to the step 5 but nothing seems to be happening.
When I opened the developer console on Chrome, it has these errors:
Failed to load resource: the server responded with a status of 400 (OK)
index.js:834 Uncaught InvalidStateError: Failed to read the 'responseText' property from 'XMLHttpRequest': The value is only accessible if the object's 'responseType' is '' or 'text' (was 'arraybuffer').
I opened the page, then needed to close my laptop for a while before I had done the step where the domain provides certain hash in particular url. Then I got back and provided the url, and it validated, but the step 5 doesn't work.
Thanks for providing the service!
edit: If I now try to do the 4th step again, I get:
Error: Domain challenge failed. Please start back at Step 1. {"type":"urn:acme:error:malformed","detail":"Unable to read/verify body :: JWS has invalid anti-replay nonce","status":400}
Ok, the error in the api call seems to be "Certificate public key must be different than account key".
I'm a layman when it comes to secure websites and certificates. I remember reading that the "free https" provided by Cloudflare meant Cloudflare owned the private keys to something and was able to see all traffic. Is that the case with Let's Encrypt? Because if it is I don't see as an improvement at all.
You create your own private key (or rather, the client does that for you, if you use the official one) and send them a Certificate Signing Request (CSR) which only includes your public key. The private key stays on your server.
At least you should not. StartSSL (and probably other CAs) has a prominent feature to create your key pair for you, which you need to skip to use a signing request. Always use the latter!
Personally, I would avoid changing SSL processes close to the expiry of your current certificate if uptime is a significant consideration[1]. If it's a toy or personal use server, then sure, learn a new experimental solution and save some money.
If you have problems with letencrypt.org, there are cheaper options for a domain validation certificate than $150. namecheap.com generally has competitive prices on various types of certs from various registrars. options and is pretty easy to use, startssl.com has free domain validation certs, but the experience can be a bit harrowing the first time around [make sure you keep a copy of everything in a safe place, you don't want to screw up the idiosyncratic process that startssl uses]).
On production servers, it's always better to use a tested process rather than winging it. This is doubly true when you have a hard deadline like a certificate expiration hanging over your head.
[1] in fact, I don't even like to let certs get close to expiry even when I'm not changing processes, since missing the deadline can cause so much unnecessary grief
edit: A bunch of little tweaks, nothing that changed the main thrust of the comment.
This website is agnostic to the server setup. All it does is ask you to host a file at a specific endpoint on your domain on port 80. It has examples of how to do this with python or file-based on nginx and apache, but there's nothing stopping you from doing your own configuration to host the file in your own way. Hope that helps!
Have you used this recently? I just tried it 3 times, and every step succeeds until after I've successfully completed step 4, then step 5 displays a failure message that tells me to go back to Step 1 again.
I didn't realize you were the author! I figured out that I made a mistake by using the same key pair for Steps 1 and 2. The LetsEncrypt API returned an error that told me to use a different key for the CSR, and once I did that it worked.
Reading back through your instructions, I don't know how you could be more clear that ACCOUNT.KEY and DOMAIN.KEY should be different. It's just my fault for not reading slowly enough. :)
Thanks a bunch for making this tool, it made everything simple.
I don't get it. What is the domain key here?
I tried to read the instructions but all of it said that the signing should be done with account private key.
Ok I got confused because tried to simultaneously read how to make the certificate using Amazon AWS documentation, and seems I skipped one crucial part.
Did you figure it out? You need two different keys: the account.key and the domain.key. For most of the steps you will use the account.key to sign, but the Certificate Signing Request will use the domain.key to sign.
this was super easy! i just got it HTTPS setup through your site for an API backend I'm working on, and the hardest part was moving nginx off of dokku so that I could get it to serve static files. thanks!
