How to setup SSL on a Netgear ORBI Router

As part of my network at home I use a few Orbi wireless routers from Netgear as a bridge.

They work great - except for one annoyance - and that is whenever I go to open the admin page using any sort of browser using the routers hostname, Chrome, Firefox or whatever automatically switches to use HTTPS and the connection fails due to the bad SSL certificate.

A few people have asked on the Internet for how to fix this and Netgear has remained quiet on the subject. It is a legitimate request, so here is how to fix it.

Items needed for this technique to work:

  • Wildcard Certificates (preferrably from Letsencrypt) that can be compiled into a PEM file (if wildcard certs are new to you or you have no way of generating and using such a cert then stop now and just live with the borked Netgear certs.....)
  • A web server running locally that you can use to transfer files. If none available you can also try tftp, ftp or nc.
  • A linux box on which you can run telnet via the expect shell

The only real issue with this though is that all changes you make will be reset should you reboot your router. So when you do reboot your router you will need to repeat this process all over again.

Step 1: put Orbi into debug mode

A little known web page available on the Orbi router is the debug page. To access it simply navigate to the debug page with the following URL (of course change the IP address to that of your router if needed):

On this page you can find an option to enable telnet. This will allow you to gain access to the system and make changes as required. Turn it on.

Step 2: prepare your certificates in pem format

With telnet enabled you can log into the server and view its existing certificate if you like. Use the username admin with your super secret password to log in. The certificate is located as /etc/lighttpd/certs/server.pem. This is the file that will be replaced. Just to be safe it might be useful to backup the file by copying it to server.pem.bak.

Now you will need your own local PEM file that includes your valid key and certificates. This file will have the structure of

----BEGIN RSA PRIVATE KEY-----
M...............................................................
Lots of text....................................................
....................................................==
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
M...............................................................
Lots of text....................................................
...........................................=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
M...............................................................
Lots of text....................................................
.....................................==
-----END CERTIFICATE-----

If you happen to use Letsencrypt (free) to create your (free) SSL certs and you happen to use the acme.sh script to generate and manage your Letsencrypt certificates, then in your ~/.acme.sh/site_folder (site_folder is substituted with your domain) you should find the files that you can combine together into the server.pem file. In most cases these files are:

~/.acme.sh/DOMAIN_NAME/DOMAIN_NAME.key
~/.acme.sh/DOMAIN_NAME/fullchain.cer

If you use another cert method or don’t use acme.sh then you should still be able to find those files where ever your cert method stored them.

Of special note is that the certificates I use are wildcard certificates. That means any system in my darrenpopham.com domain can use the same certificate. So orbi.darrenpopham.com will be able to make use of the same certificate I use on my main web server. If however you make a specific certificate for just your orbi.yourdomain.com system then you will have to solve verifying that you own the hostname for the Letsencrypt servers on your own.

I then run a script that just concatenates them together:

#!/bin/bash

cat /PATH_TO_YOUR_PRIVATE_KEY_WITH_NO_PASSWORD \
    /PATH_TO_THE_FULLCHAIN_CERT_CONTAINING_YOUR_CERT_AND_LETSENCRYPT_INTERMEDIATE_CERT \
    | grep [A-Za-z] \
    > /WHERE_YOU_WILL_PUT_THE_ORBI_FILE_ON_YOUR_WEBSERVER_TO_DOWNLOAD/server.pem

(the grep at the end of the command is not really needed and is just used to wipe out the blank lines, if any)

Step 3: Copy pem file to local web server, unless you are instead transferring using tftp, ftp or nc

If you happen to have an internal web server that your systems in your local network can access then you can use it to transfer the server.pem file to the orbi server. If that’s not the case then you might need to investigate transfering files using some other method such as tftp, nc or ftp. But since you care about security and privacy I am confident you have a server handy - likely it is the one you are running PiHole on.

I use my internal nginx server to host the server.pem file. If you do the same then make sure it is an internal only server and block access to it from any system not on your network. This point is really really important. If you let someone else get this file then you are f’ed in the most inelegant way and will then need to start the whole certificate revocation process and ultimately get new certs. You’ve been warned - if you give away your security then what’s the point in having it in the first place…..

In my case, I setup a small nginx location block for my internal server that looks something like this:

location /server.pem {
    root /some/folder/somewhere;
    allow ip_of_my_local_network/24;
    deny all;
    add_header Content-Type application/octet-stream;
}

This location block allows systems on my subnet to access the file in question. Everyone else is blocked.

The server.pem file is then copied to the /some/folder/somewhere location.

Step 4: automate telnet copy of the server.pem file

For this to work I find the expect command is the easiest way to automate logging into the Orbi server, downloading the server.pem file and then restarting the lighttpd server.

If you run ubuntu or any distro that uses the apt package installer, simply execute sudo apt install expect. This will install the expect shell which is used to interact with commands by “sending” a string and then “expecting” a response.

A sample script I use is:

#!/usr/bin/expect

spawn telnet -e ! hostname_of_your_orbi_server
expect {*login:}
send "admin\r"
expect {*Password:}
send "XXXXXXXXXX\r"
expect {*root@RBR50:/#}
send "curl -s -k https://INTERNAL_WEB_SERVER/server.pem > /etc/lighttpd/certs/server.pem\r"
expect {*root@RBR50:/#}
send "/etc/init.d/lighttpd restart\r"
expect {*root@RBR50:/#}
send "!"
expect {*telnet>}
send "quit\r"

A few things to note here. To exit the telnet session I find it easier to use something like the ! mark as the escape key sequence. That’s what the -e ! is for. This way I can break out of the telnet session and quit to end it. The Orbi is running Busybox and I find it does not give up its telnet connection easily via exit or Ctrl-D’s. Escape and quit though seems to do the trick.

Of course, substitute the XXXXXXXXX string with your super secret admin password and substitute the hostname_of_your_orbi_server with the hostname of your orbi server.

Then if all went well, after the lighttpd server restarts you can test your changes by navigating to the secure URL for your Orbi server.

Step 5: turn off telnet

This is specially important if you use your router as an Internet gateway. So don’t forget to go back to the debug page and disable telnet.

Enjoy!