Update of RADIUS server certificates - how to do that

[alxwolf]

Created a separate branch to work on this topic. Seems a bit more complicated than expected and equally "well-documented" by Ubiquiti as usual.

Linked with issue #12 and PR #13

[tackynugget]

@alxwolf

Let me know how I can help. I’m also happy to test.

[tackynugget]

FYI (and you probably already know this): I was able to regenerate the original UBIOS RADIUS certificates by renaming/removing the /mnt/data/udapi-config/raddb/certs/server.pem certificate and server-key.pem key and restarting the UDM.

In the course of my earlier testing, I lost my backup of the original UBIOS RADIUS cert. Since the ca.cer in that directory was likely used to create more certificates, I figured it might recreate the RADIUS cert if it was missing.

NB: I had to completely reboot the UDM to get the cert/key to regenerate. I tried /usr/sbin/rc.radiusd restart after rm server.pem and rm server-key.pem but it did not recreate the cert/key pair.

[alxwolf]

@OverengineeredNetwork could you try the following please - if possible.

/etc/init.d/S45ubios-udapi-server restartcould do the trick to get the LE certificate enabled for RADIUS.

If this is stuck or shows weird behaviour, a reboot should fix it

[tackynugget]

@alxwolf,
Well, I thought running /etc/init.d/S45ubios-udapi-server restart went smoothly.

Stopping ubios-udapi-server watchdog: OK
Stopping ubios-udapi-server: ........................OK
Starting ubios-udapi-server: OK
Starting ubios-udapi-server watchdog: OK

I was able to disjoin and re-join my RADIUS-Authenticated WiFi Network without any certificate errors.

However, I could not browse to any websites or post this reply. It was as if DNS could not resolve external or internal hosts. Other RADIUS-Authenticated WiFi clients also lost the ability to resolve public hostnames.
I was able to restore functionality by running the reboot command you suggested.

[alxwolf]

@OverengineeredNetwork

Thanks for being so quick in testing it. Do yo run pi-hole as DNS on the UDM Pro (I do that)? Had the same issue (must reboot).

Are now the correct certificates installed for the Radius server?

[tackynugget]

I just saw I received a few notifications from my controller too.

I've been getting these errors recently. I'm not sure if they were related to our testing or when I upgraded the firmware from UniFi 1.10.4 to 1.11.0 (7 days after our testing).

I use AdGuardHome which runs as a podman container.

I can confirm that it is still serving the correct certificate for RADIUS-Authenticated WiFi supplicants.

Update: I think each Wi-Fi client (RADIUS supplicant) that hasn't accepted the new certificate will trigger this alert. When I see this alert on my smartwatch, it also specifies the client's name.

[tackynugget]

Those iOS notifications from the controller don't do anything. Everything works. I just get these notifications occasionally.

I "forgot" the RADIUS WiFi network on my iPhone and Mac and rejoined them anew. Everything worked as expected.

[tackynugget]

Based on this testing, I

• Replaced line 64 (/usr/sbin/rc.radiusd restart) in /mnt/data/ubios-cert/ubios-cert.sh with reboot
• Forced a renew sh /mnt/data/ubios-cert/ubios-cert.sh forcerenew
• Ran a deployment (to get the add_radius function to run): sh /mnt/data/ubios-cert/ubios-cert.sh deploy

Deploying certificates and restarting UniFi OS
New certificate was generated, time to deploy it
[buncha hex]
Checking if Captive Portal certificate needs update.
New certificate was generated, time to deploy it
Checking if RADIUS server certificate needs update.
New certificate was generated, time to deploy to RADIUS server
New RADIUS certificate deployed.
unifi-os: Stopping unifi-os
unifi-os: Stopping unifi-os unifi-core.service
unifi-os: Stopping unifi-os unifi-protect.service
unifi-os: Stopping unifi-os unifi.service
unifi-os: Stopping unifi-os unifi-base-ucore.service
unifi-os: Stopping unifi-os postgresql.service
unifi-os: [buncha hex]
unifi-os: Stopping unifi-os SSH daemon... OK
unifi-os: Starting unifi-os
unifi-os: Stopping unifi-os SSH daemon... OK
unifi-os: Starting unifi-os SSH daemon... OK
unifi-os: unifi-os

All of my wifi devices seemed to keep their connection to the SSID, but I couldn't navigate anywhere. I had to toggle wifi off and on again to accept the NEW RADIUS cert on each device. I noticed this time that my Mac didn't report problems with the cert like it had before. I confirmed that the /mnt/data/udapi-config/raddb/certs/server.pem in place was the current one and not the fullchain. The fullchain cert should be used for the RADIUS cert. I didn't get an error before because I had trusted the expired cert. I cleared all related certs between test and confirmed that the Mac will assume the wrong root CA unless the fullchain cert is used.

Once I accepted the new RADIUS cert on my devices, I checked to see if the cert had been applied to my controller and my AdGuardHome podman container. Everything works as expected.

Whatever that reboot command does, it seems more effective than the others we've tried. I'm not sure if its overkill to use the command or if it's a "dirty" shutdown.

Also, of note, the deploy_cert () function calls the add_captive () function, but not the add_radius () function. But the deploy switch calls both. That's why I ran the command twice (at the top).

I'm still learning GitHub--not sure how I can propose these changes to help.

TLDR:

• The reboot command works to deploy the RADIUS cert (but seemed to disrupt video recordings for ~5 minutes)
• Given the effectiveness of the reboot command, I wonder it if should replace the unifi-os restart command to prevent redundant service restarts.
• The fullchain.cer should replace /mnt/data/udapi-config/raddb/certs/server.pem
• The deploy_cert () might want the add_radius () function as well to keep it consistent with the deploy switch.

[alxwolf]

@CaseyTal so. Good news is I got it sorted out "in principal"™

bad news is: won't be able to offer it for V1.x (due to lack of equipment for testing), but nobody should care as we should all move to V2.0 (or V3.0 soon).

Plus, right now I can only make free radius read the new certificate by rebooting the box, like stated here by @tackynugget. So, some more research required.

[CaseyTal]

Fair enough. Have you made any changes to the files yet? I'm on 2.x, so that's fine by me!

And the reboot would only be once, correct? OR would that be required in the event of a power outage as well?

[alxwolf]

@CaseyTal you could try the main branch now, as I believe I've been able to sort it out now.

At first login, devices will (might?, only tried with a Mac and iOS) ask you to nod off the certificate - but at least now the right name is displayed, not "UbiOS Radius etc.", and it is shown as valid, for not being self-signed by UI.

@tackynugget, thanks for the effort you put into deciphering what UI does. With 2.x, I've been able to get it to work (i.e., updated cert presented) by restarting the service with systemctl restart udapi-server, without requiring to reboot.

[CaseyTal]

Still getting "Syntax error: newline unexpected"

[alxwolf]

Still getting "Syntax error: newline unexpected"

Which DNS provider do you use? in case it's not GoDaddy, you must comment out

# GoDaddy
export DNS_API_PROVIDER="dns_gd"
export GD_Key=<KEY>
export GD_Secret=<SECRET>

the <> will break parsing the file