Let's Encrypt Certificates (HTTPS setup) - SOLVED


 

Curtis_Aotea

TVWBB Member
OK - spent a few hours last evening trying to get external https up and running, without much success.

Situation:
1. I already have a website/webserver up and running, with a fixed IP address.
2. It's proxied through Cloudfare for DNS only, running on a Pi4.
3. I use Let's Encrypt Certs for the website, and already have these autogenerated and renewing, and sitting in location:

/home/pi/.acme.sh/mysite.org.nz/cert files*

4. The working files generated by my Let's Encrypt setup are: fullchain.cer, keystore.p12, mysite.org.nz.cer, mysite.org.nz.csr, certificate.pfx and mysite.org.nz.key.

I've tried copying the relevent certs and converting them to "der" format, in place of /etc/uhttpd.cert and /etc/uhttpd.key, however, when I port forward the set port to my Heatermeter, either it's still using the self-signed certs (hence I can't get in, since I've set strict HSTS on the certs themselves) or the webserver fails to come up due to incorrect certs altogether.

I've also tried hm-letsencrypt and fiddling with the associated scripts, however they generate certs (with 443 forwarded), but not working/valid ones for my site ("Issuer: Fake LE Intermediate x1"), which I presume has something to do with using Cloudflare for DNS services, including A, AA and CNAME records.

My question is: which of the working Let's Encrypt files need to be uploaded using the webinterface (or scp) in place of /etc/uhttpd.cert and /etc/httpd.key? And/or do they need to be converted to "der" format?

TLDR; I've done the hard part by having working Let's Encrypt certificates and a working HTTPS server, I just can't translate those certs to Heatermeter.

EDIT: solved as per script below.
 
Last edited:
Thanks Steve - I'd hoped you would be watching this! I've read your post above thoroughly, and actually now copied my acme.sh script and account and env files from my working pi webserver. Certificates are generating correctly (acme.sh --renew --domain mysite.org.nz --force) , and I have the following, which I believe *should* now be valid key and cert files. These are:

1. mysite.org.cer
2. mysite.org.nz.key
3. ca.cer
4. fullchain.cer

...but question remains - how do I tell the heatermeter webserver to use these particular certs & do they need converting to 'der', and if so, which acme-generated files are used to do this? Thanks in advance :)
 
uhttpd is using /etc/uhttpd.key and /etc/uhttpd.crt

running /etc/init.d/uhttpd stop and /etc/init.d/uhttpd start should tell uhhtpd to use the new cert
 
Brilliant....just got it working :)

Can now browse to: mysite.org.nz:xxxx and get the heatermeter webpage with a nice green padlock.

Used the following to convert the LE files, then copied to /etc/

1. openssl x509 -inform pem -in mysite.org.nz.cer -outform der -out uhttpd.cert
2. openssl rsa -inform pem -in mysite.org.nz.key -outform der -out uhttpd.key

Now to set the above up as a cron script for whenever the certs renew

Great stuff!
 
Last edited:
A simple auto update script in case anyone's interested (updated based on feedback):

#!/bin/sh

# Stop the service
echo "Stopping HeaterMeter web interface..."

/etc/init.d/uhttpd stop

sleep 5

# remove old certs
echo "Removing old certificates..."
rm /etc/uhttpd.cert
rm /etc/uhttpd.key

# convert pem to der format
echo "Converting new certificates to DER format and writing to correct location..."
openssl x509 -inform pem -in /mnt/mmcblk0p4/.acme.sh/mysite/mysite.cer -outform der -out /etc/uhttpd.cert
openssl rsa -inform pem -in /mnt/mmcblk0p4/.acme.sh/mysite/mysite.key -outform der -out /etc/uhttpd.key

# Restart the HeaterMeter service
echo "Restarting HeaterMeter web interface..."
/etc/init.d/uhttpd start
sleep 5
echo "All Done!"

1. Obviously replace 'mysite' in the above script with your actual domain name.

2. Check your acme.sh script and .conf files to output certs to the locations referenced (you may need to edit your scripts)

3. Can be set to run as a cron job just after acme.sh runs in order to keep everything up to date and ship shape.

4. As noted below, it may not be needed to convert the certs to DER format. If you choose not, to simply edit the script to copy 'mysite.key' to /etc/uhttpd.key and 'mysite.cer to /etc/uhttpd.cert. I haven't tried this to confirm it works.

5. I've placed the above script and my .acme.sh folder and set acme.sh to write the certs to the /mnt/mmcblk0p4/ partition to stop everything being deleted every snapshot update.
 
Last edited:
not sure why you're having to convert from PEM to DER. uhttpd supports both formats

The script in the link I posted also takes care of auto renewing/updating the cert.
 
Thanks Steve - it's not clear from the web interface that's the case - it says "as DER format", or something similar. Glad to hear both work, and to be able to cut out the conversion step.

In my case, your script didn't seem to have the right env and/or account variables, hence the certs generated as "Issuer: fake LE Intermediate x1" didn't work out in my environment. It wasn't plug and play despite following the instructions to the letter, sadly. I'm not expert enough to figure out precisely why that was the case.

I'm just glad I don't have to stay up until 5am again trying to get it to work, since it does run with my workaround to reuse my own specific customised LE certs (which I use for the rest of my web presence in any case).

Hopefully my script is helpful for those who already have & use their own existing LE certs and simply need to deploy them to their heatermeter box (+/- the conversion to DER).
 
Last edited:
Update: ahhh - updating the firmware/snapshot wipes the /root/ directory. I'm such a n00b. :)

Recopied .acme.sh straight from my Pi4 web server into /root/, recreated and ran the update script above. Back with a green padlock. At least cron isn't wiped!

Learning, learning....
 
Update: ahhh - updating the firmware/snapshot wipes the /root/ directory. I'm such a n00b. :)

Recopied .acme.sh straight from my Pi4 web server into /root/, recreated and ran the update script above. Back with a green padlock. At least cron isn't wiped!
Yeah the filesystem is wiped apart from "config files". There are two ways to get it to survive a reboot:
  • Put the script in your stash: /mnt/mmcblk0p4/. Just create a new directory here, the upgrade process doesn't touch this partition
  • Add all the files you want to keep to the list of files backed up. This is in System -> Backup / Flash Firmware -> Configuration tab
 
Long time no update :)

The acme.sh script is no longer working for me on HeaterMeter or my Raspberry OS box due to "invalid domain" error. So, I've switched to certbot instead.

Since there's no apparent way to get certbot working on LEDE/OpenWRT, I've resorted to manually copying the certificates from my raspberry OS box to the HeaterMeter using WinSCP. Having done that, the above conversion script still works (just need to ensure the copied cert paths and file names are adjusted).

Bit of a pain having to do this manually, but at least it's only every 3 months.
 
...and a new method to secure your HeaterMeter's interface over the web is setting up a Cloudflare tunnel. This gives you an SSL certificate from Cloudflare (via Google Trust Services LLC).

Excellent tutorial from Crosstalk solutions on how to set up Cloudflare tunnels for any LAN services is here:
 

 

Back
Top