HOWTO: use a Let's Encrypt ssl certificate on HTTPS web interface

This isn't a detailed howto. It's more like my notes about what I did to make it work. You should probably know what you are doing before attempting this. I've cobbled this together from various pages on the internet. Nothing is original to me. I am standing on the shoulders of giants.

Why? No good reason really. I've always enabled Web Access from WAN and HTTPS authentication method so I can access my home router from work (or while I'm out and about). It has always bothered me that the certificate isn't considered valid by the web browser.

For this to work you need to have access to a linux system inside your network. Yes, that's cheating. Fortunately for me I already had a Ubuntu VM running a Nagios that I could easily leverage.

For this howto, swap occurances of router.example.com with the publically resolvable host name you've set up for your router. See the WAN - DDNS part of the router web interface for more info.

Part 1: port 443 redirection
Really you should do this just before you run letsencrypt-auto, but layout wise it fits better here...
On the router, go to WAN and then Virtual Server / Port Forwarding
set a rule that forwards port 443 to the linux VM you are installing Let's Encrypt on.

Part 2: Install Let's Encrypt on the Ubuntu VM (that already has apache2 set up and running)
Install git

Code:

sudo apt-get install git

Get Let’s Encrypt

Code:

cd ~/
git clone https://github.com/letsencrypt/letsencrypt

Run Let's Encrypt for the first time and have it make a dummy cert. You are only allowed to generate 5 legit certs a week, so it's good to start out with a testing cert that doesn't count against your allowance.

Code:

sudo ~/letsencrypt/letsencrypt-auto --test-cert -d router.example.com

It's going to install a lot of dependencies (like a lot). Just let it do it's thing. If it asks you any questions, answer them appropriately.

If there were any problems, correct them before proceeding.

Run it again without the test-cert flag to create a real certificate.

Code:

sudo ~/letsencrypt/letsencrypt-auto -d router.example.com

Assuming everything went okay, you will now find your certificate files in /etc/letsencrypt/live/router.example.com/

Now that the cert is made, you can turn off the port 443 redirection.

Part 3: Put the certs on the router
Open a shell on your router and verify https_crt_save is set to zero

Put the contents of /etc/letsencrypt/live/router.example.com/privkey.pem (from your Ubuntu system) into /etc/key.pem on the router. Don't worry if something is already there, just delete it all first.

Put the contents of /etc/letsencrypt/live/router.example.com/fullchain.pem (from your Ubuntu system) into /etc/cert.pem on the router. Don't worry if something is already there, just delete it all first.

If you are a belt and suspenders type of person, go ahead and reboot the router (just for fun).

Part 4: Verify it worked
Point your browser to your https login page and make sure you don't get a warning about the certificate being invalid.

Part 5: Renew the cert
Let's Encrypt certs are only good for 90 days, so you will have to do this process over again every 3 months (or sooner). Realistically, the next time you need to log into your router you'll notice it's expired and go do something about it.

To renew the cert, do the whole thing over again from part 1 to part 4. This time you should use this command so it won't ask all the questions again.

The purist in me finds it worrying that Letsencrypt lets you obtain a certificate for a domain which you don't legally own. While the intent is nice (moving as many websites as possible to SSL), I feel it weakens a bit the security provided by SSL certificates, as it no longer validates the ownership of a site - it only encrypts it. Maybe that's just my personal feeling there tho...

The purist in me finds it worrying that Letsencrypt lets you obtain a certificate for a domain which you don't legally own...

Click to expand...

I don't think that is a fair characterization. The Let's Encrypt software requires communication with their mother ship over port 443 while validating the setup. This step proves you are in control of the server.

Maybe a glossed over the details, but the Linux VM I created must be on the LAN side of the router and the publicly resolvable name must terminate at the WAN side of the same router.

I guess you could argue that control does not equal ownership, but that seems like a narrow distinction in today's world.

Edit: and you have to prove that relationship every 90 or the cert expires.

I don't think that is a fair characterization. The Let's Encrypt software requires communication with their mother ship over port 443 while validating the setup. This step proves you are in control of the server.

Click to expand...

Yes, it proves that you control the server that will host the website (at least during the validation process). But if you had managed to hijack a domain's DNS, you would then be able to fully impersonate the hijacked website by obtaining a certificate for that domain. Sure, the real owner will sooner or later find out and regain control of his DNS, preventing you from renewing that certificate, but in the meantime you could have harvested/stolen a lot of important information, and people relying on a certificate to confirm they are really on the site they expect won't have that same level of trust anymore.

Yes, it's a very specific scenario, but still one that makes me wonder about the possibility.

I see where you are coming from. IMHO if someone has hijacked you DNS the game is already lost. Nothing stopping you from altering the DNS records (physical address, email contacts or whatever) and applying for a more conventional cert. I believe the benefit (free encryption for everyone, making general SSL use more commonplace) is worth the slight risk you've outlined (an already compromised system being further compromised). Just my $0.02.

I see where you are coming from. IMHO if someone has hijacked you DNS the game is already lost. Nothing stopping you from altering the DNS records (physical address, email contacts or whatever) and applying for a more conventional cert. I believe the benefit (free encryption for everyone, making general SSL use more commonplace) is worth the slight risk you've outlined (an already compromised system being further compromised). Just my $0.02.

Click to expand...

I guess that from now on, EV certificates will become something people will need to look at whenever trying to determine if the site they are accessing really is the correct one. More business for CAs selling those overpriced certificates I suppose

sudo ./letsencrypt-auto --test-cert -d chieffo.homenet.org
Checking for new version...
Requesting root privileges to run letsencrypt...
/home/tecla/.local/share/letsencrypt/bin/letsencrypt --test-cert -d chieffo.homenet.org
No installers seem to be present and working on your system; fix that or try running letsencrypt with the "certonly" command

Whatever "donor" system needs to support the let's encrypt stuff. In my case it was a Ubuntu LAMP system. I believe they only support Apache2 for the automatic cert injection stuff at this time. Regardless, you should be able to get it working if you hack at it a bit. As the error message suggest, try the certonly command and see if that works. It won't install the cert into the local web server automatically, but you don't care since you are going to move the cert over to the router anyway.

sudo ./letsencrypt-auto --test-cert -d chieffo.homenet.org
Checking for new version...
Requesting root privileges to run letsencrypt...
/home/tecla/.local/share/letsencrypt/bin/letsencrypt --test-cert -d chieffo.homenet.org
No installers seem to be present and working on your system; fix that or try running letsencrypt with the "certonly" command

Click to expand...

It means you are not running a certificate installer (e.g apache) on the Linux machine you are running this on. However, you don't need to set one up, you can use the standalone mode. I have just done this successfully on a raspberry pi with this command:

The letsencrypt authentication process is argued by some to be weaker than proving via control of the registrant email account. But there is 2 very clear benefits to letsencrypt.

It is vastly increasing https adoption (as well as making signed certs much more common on email services).
Second rogue certificates will expire much quicker without needing revocation, the long term plan is to have expiries much lower than the current 90 days perhaps eventually been only a few days.

Also my email is on their systems but I have to yet to receive this update, I guess they never finished issuing it.

The purist in me finds it worrying that Letsencrypt lets you obtain a certificate for a domain which you don't legally own. While the intent is nice (moving as many websites as possible to SSL), I feel it weakens a bit the security provided by SSL certificates, as it no longer validates the ownership of a site - it only encrypts it. Maybe that's just my personal feeling there tho...

Click to expand...

I agree - this is a bit of a opportunity for them to improve - and... there's potential for abuse perhaps because of what you mention above...

--
This post brought to you via the letters "e" and "t", and the number "1"

Letsencrypt is nice idea - but the cert period being 90 days is a bit short.

startssl.com - give them a look - email s/mime takes only a minute, and they do have a free ssl cert for personal use.

Click to expand...

90 days ain't much of a problem however due to their automated certificate renewal.

I looked at some freebies these past few years, and many of then come with a few gotchas, often only mentioned in their fine prints, such as duration being less than a year, or being free only for the FIRST issue - renewals are being sold.

The investigation concluded that WoSign knowingly and intentionally misissued certificates in order to circumvent browser restrictions and CA requirements. Further, it determined that StartCom, another CA, had been purchased by WoSign, and had replaced infrastructure, staff, policies, and issuance systems with WoSign's. When presented with this evidence, WoSign and StartCom management actively attempted to mislead the browser community about the acquisition and the relationship of these two companies. For both CAs, we have concluded there is a pattern of issues and incidents that indicate an approach to security that is not in concordance with the responsibilities of a publicly trusted CA.​

--
This post brought to you via the letters "e" and "t", and the number "1"