How-To: Let's Encrypt on GLDDNS domain

[admon]

Hi there

I created another mighty script!
My newest script will automate the process of getting a Let's Encrypt certificate, which can be used for the GL GUI. It even will install a cronjob for automatic renewal! It was tested on my Flint2.

Dependencies

To execute the script, the following prerequisites must be met:

• A GL.iNet router with the latest firmware version (at least 4.x)
• A working internet connection.
• DDNS must be enabled and configured.
• DDNS IP must be the same as the router's public IP. Will be checked by the script.
• The script will request a certificate for the router's public IP.
  VPN and (CG)NAT IP is not supported! So no certs for cellular devices, this is by design.
• Only HTTP mode supported, no DNS mode. This is by design of GLDDNS

There is no need to disable VPN, the script will automatically use the real WAN IP.

Download

GitHub - Admonstrator/glinet-enable-acme: This script enables the Automated...

Quick run without downloading

You can run it without cloning the repository by using the following command:

wget -O enable-acme.sh https://raw.githubusercontent.com/Admonstrator/glinet-enable-acme/main/enable-acme.sh && sh enable-acme.sh

Disclaimer

This script is provided as is and without any warranty. Use it at your own risk.

It may break your router, your computer, your network or anything else.
It may even burn down your house You have been warned!

Reverting

To revert the changes:

sed -i '/listen \[::\]:80;/c\listen \[::\]:80;' /etc/nginx/conf.d/gl.conf
sed -i '/listen \[::\]:80;/c\listen \[::\]:80;' /etc/nginx/conf.d/gl.conf
sed -i 's|ssl_certificate .*;|ssl_certificate /etc/nginx/nginx.cer;|g' /etc/nginx/conf.d/gl.conf
sed -i 's|ssl_certificate_key .*;|ssl_certificate_key /etc/nginx/nginx.key;|g' /etc/nginx/conf.d/gl.conf
/etc/init.d/nginx restart
rm /usr/bin/enable-acme

After that, please remove the line 0 0 * * * /usr/bin/enable-acme --renew from crontab -e

[japa182]

very very good, it’s a shame that my isp doesn’t leave the port 80 http and 443 https released, if not I would definitely use your script, if I change the router’s http port to another port that my isp allows and do Can I use this method of port forwarding on this chosen port?

[admon]

@japa182

if I change the router’s http port to another port that my isp allows

Could you please try if you even can do that? It’s strange that your ISP does not allow 80/443. Can you use 8080 for example? If yes, I can integrate a way to change the ports.

[japa182]

unfortunately Vivo here in Brazil blocks most ports, the only one I tested that they don’t block is ssh 22 which is standard, but I can use another port like 8080, 8008, 8090 or 8443 for https

[admon]

Unfortunately, it’s not possible to change the ports because the GLDDNS only supports HTTP-01-challenge, which is fixed to 80 and 443.

Maybe in future the GLDDNS service will add the possible to get DNS-verification. Nothing I can do about it, sorry.

[Thinner3614]

It didn’t work for me. The script accuses that the public IP is not the same as the DDNS IP.

• I’m not using VPN
• I can access the router normally through DDNS
• Port 443 is open.

To prove that I have a public IP, I can access the router through it:

v4.5.7 beta release5

[admon]

Ah, you are using IPv6 - it does not work with that so far. I will try to fix the DDNS request.

[admon]

Fixed it by forcing IPv4 only - at least so far until I got my own IPv6 up and running to play around.
@Thinner3614 Could you try again?

[LupusE]

I really appreciate your warnings. I promise not to install it on my space station!

[admon]

The last who did it lost a battery pack which was going down in the sea …

[Thinner3614]

It`s working. Very thanks for help!

[maholio]

Purely theoretical based on script logic (I didn’t tested it) you can also add noip support for cases if ISP block port 80/443

echo "Select DDNS provider:"
echo "1. GLDDNS"
echo "2. No-IP"
read -p "Enter your choice (1 or 2): " DDNS_CHOICE

case $DDNS_CHOICE in
    1)
        DDNS_PROVIDER="gl"
        ;;
    2)
        DDNS_PROVIDER="noip"
        ;;
    *)
        echo "Invalid choice. Exiting..."
        exit 1
        ;;
esac

echo "Enter your email for ACME configuration:"
read EMAIL

# Variables for GLDDNS and No-IP
case $DDNS_PROVIDER in
    gl)
        DDNS_DOMAIN_PREFIX=$(uci get ddns.glddns.domain)
        ;;
    noip)
        DDNS_DOMAIN_PREFIX=$(uci get ddns.noip.domain)
        ;;
    *)
        echo "Unsupported DDNS provider. Exiting..."
        exit 1
        ;;
esac

# Functions
create_acme_config() {
    DDNS_PROVIDER=$1
    EMAIL=$2
    # Delete old ACME configuration file
    log "INFO" "Deleting old ACME configuration file for $DDNS_DOMAIN_PREFIX"
    uci delete acme.$DDNS_DOMAIN_PREFIX
    uci commit acme
    # Create new ACME configuration file
    log "INFO" "Creating ACME configuration file"
    uci set acme.@acme[0]=acme
    uci set acme.@acme[0].account_email="$EMAIL"
    uci set acme.@acme[0].debug='1'
    uci set acme.$DDNS_DOMAIN_PREFIX=cert
    uci set acme.$DDNS_DOMAIN_PREFIX.enabled='1'
    uci set acme.$DDNS_DOMAIN_PREFIX.use_staging='0'
    uci set acme.$DDNS_DOMAIN_PREFIX.keylength='2048'
    uci set acme.$DDNS_DOMAIN_PREFIX.validation='standalone'
    uci set acme.$DDNS_DOMAIN_PREFIX.update_nginx='1'
    uci set acme.$DDNS_DOMAIN_PREFIX.domains="$DDNS_DOMAIN_PREFIX"
    uci commit acme
    /etc/init.d/acme restart
}

Cannot test it now as I am away from my test router. On main I will not risk to test something

[admon]

Only if noip offers changing of DNS entries.

DDNS does not need 80/443, Let's encrypt HTTP-01 challenge does.

[maholio]

@admon

offers changing of DNS entries

It does, but specific ones is paid

[Thinner3614]

I found this bug in MT6000 (v4.6.0-op24)

[admon]

Is GLDDNS disabled on your device?

[japa182]

It probably has something to do with this change?

DDNS host name not working suddenly?

In our recent update, the server use the TCP peer public IP to update domain data instead of using http params in order to improve the security. So there is a issue in the old firmware, IPv4 data was uploaded by IPv6 network. It mean that the IPv4 record would not be update any more in the both IPv4 and IPv6 network . We decide to recover the original processing logic temporarily, but still consider close the logic when the most user update to the laste firmware in the future days.

[admon]

No, shouldn't be an issue since GLDDNS won't be touched.

[Thinner3614]

It's enabled:

[admon]

In that case OpenWrt 24 seems to be not supported so far, I am sorry.