Since TP-Link’s documentation is *awesome* for this (sarcasm alert), I thought I’d share what I finally figured out to get the self-signed cert replaced with one from a local CA that doesn’t make Chrome complain. This was the result of several hours of fiddling around, waiting for oc200 reboots, and getting uber-helpful error messages from the device (sarcasm meter explodes).
Pre-reqs:
1. passing familiarity with openssl command-line usage, including how to set up a local certificate authority (CA; out of scope for this post/rant but this looks decent as an intro: https://gist.github.com/Soarez/9688998)
2. the patience not to see how far you can shot-put the oc200 device
3. some machine with openssl installed (I used a linux machine running ubuntu 20.04 fwiw)
First, you’ll want to create a config file to save typing later and enable Subject Alternate Names for your cert (so the same cert’ll be valid from the controller raw ip, or name, or short name). Call it san.conf or similar.
[req]
req_extensions = req_ext
distinguished_name = req_distinguished_name
prompt=no
[req_distinguished_name]
countryName =
stateOrProvinceName =
localityName =
organizationalUnitName =
commonName =
emailAddress =
[req_ext]
subjectAltName = @alt_names
[alt_names]
IP.1=192.168.5.2
DNS.1=oc200.lan.example.com
DNS.2=oc200
Now, on to making the actual cert (filenames may of course be altered to your taste, just be consistent):
1. openssl req -new -keyout oc200.key -sha256 -config san.conf -out oc200.csr
a. note that you probably want a password here (used by key).
b. if you’re ok with a less secure key sans password, add a -nodes argument above
2. openssl x509 -req -days 365 -in oc200.csr -CA -CAkey -CAcreateserial -extensions req_ext -extfile san.conf -out oc200.crt
a. note that recent chrome builds are moving to deny validity of certs with longer than one year. (imho this is overkill for rfc1918 networks, but c’est la guerre.)
3. openssl pkcs12 -export -in oc200.crt -inkey oc200.key -out oc200.pfx -CApath /etc/ssl/certs/ -CAfile -caname root -name oc200 -chain
a. note that you probably want to use a password here as well
b. note also that the Omada web ui is picky about filename extensions. you’ll want to end your pkcs12-exported cert to end in “.pfx” to keep it happy on upload later
From here, with the pfx file and (optionally, but recommended) the key and pfx passwords, you can proceed to Settings > Controller > HTTP Certificate session, upload your pfx file, fill in any required passwords (be sure to pay attention to which password is which re: key vs cert file aka keystore), and save at the bottom of the screen. You will then want to go to Settings > Maintenance > Hardware Controller section and reboot (this will take several minutes to complete).
You may also need to do a full flush of your browser’s cache if there were earlier attempts with the same identity cert (e.g. accidentally making it valid for too long and learning a painful lesson). You will need to import the root CA cert into your browser/OS trusted roots collection as well if you haven’t already done so (out of scope for this, but googling something like “import root ca cert ” would help).
Hope this saves someone a few hours of irritation. :)