ubios-cert: FW 3.2.7 breaks RADIUS certificates
@alxwolf sorry to necro this issue..but I am not so sure that 3.2.7 is so happy with custom certificates.
While I don’t use this script specifically (I have a internal CA that I use to generate certificates for my intranet), I do at the very least replace /data/unifi-core/config/unifi-core.crt
along with /data/unifi-core/config/unifi-core.key
. Upon restarting unifi-core with systemctl restart unifi-core
, the OS overwrites my custom certificates, effectively undoing my work.
My setup has been working for months and I never had to mess with keystore or the RADIUS config (raddb). I am trying to reach out to anyone who might know more. Only reason I noticed this was because my monitoring software detected it couldn’t reach my router anymore…then did some digging and found this stuff out. Router must have updated at 3am causing this to break.
_Originally posted by @therealpaulgg in https://github.com/alxwolf/ubios-cert/issues/60#issuecomment-1854651522_
About this issue
- Original URL
- State: open
- Created 7 months ago
- Comments: 25 (9 by maintainers)
Allright, I “think” I got to the end of it by modifying the right key/values in the mongoDB. This seems to survive the System config reload, the
service unifi restart
and the full UDM hardware reboot.⚠️ Again, I’m not responsible for you breaking your MongoDB, have some backups before!
The following one-liners are used to load the right certs in the right collection by updating existing values (this
mongosh
command looks for “key: radius” combo toupsert
values in place -which creates them if not present, you might want to check that you only have one “key: radius” combo before ending up with more than one document):One thing I haven’t tested is if the other changes to the JSON files are necessary if this is done first. It might be the case that only this change to the MongoDB is needed ultimately.
Also, I’m not sure how this will fare with updates, Ubiquiti has already changed all certs w/o telling its users, so this might have to be adjusted with future updates of Unifi OS.
All thanks @ouaibe . This did solve the problem for me.
@ouaibe Great analysis!
Will have a look into the web server certificate in the other issue e#62 - the JSON contains another cert, suitable for web server, which is (again) the standard self-signed cert by UI (at least on my machine).
So far, restarting
unifi-core
did not break the web certificate. And I can only support what you write in your final paragraph…but, maybe this is just a small step we have to overcome on the path to having it managed automatically.
Allright, I found the solution (which I had in front of my eyes for a while, except I missed a layer of b64 encoding).
Turns out, with 3.2.7, the certificates (CA, Server, and a bunch of others) have been moved to the
udapi-server
configuration state/file in/data/udapi-config/ubios-udapi-server/ubios-udapi-server.state
. This is confirmed by the service being launched as/usr/bin/ubios-udapi-server -c /data/udapi-config/ubios-udapi-server/ubios-udapi-server.state --silent
.The JSON file elements where this can be found are
.services.radiusServer.caCertificate.crt
.services.radiusServer.serverCertificate.crt
and.services.radiusServer.serverCertificate.key
but they are not in PEM format, they are Base64 encoded over their PEM format.Upon service start, the certificates are taken from the
ubios-udapi-server.state
JSON file, decoded from Base64 and written to/etc/freeradius/3.0/certs/
asca.pem
server.pem
andserver-key.pem
accordingly.As such, it’s possible to replace these entries in the JSON file and (probably?) make them persistent in this configuration.
Here are one-liners using
jq
examples to load your existing certificates into the JSON configuration file, provided that you already have aca.pem
(CA Certificate content in PEM format),server.pem
(Server Certificate content in PEM format) andserver-key.pem
(Server Key Content in PEM format).⚠️DO BACKUP YOUR JSON CONFIG FILE, I AM NOT RESPONSIBLE FOR YOU BREAKING YOUR UNIFI HARDWARE.⚠️
Note that this is probably also true for the
unifi-core
certificates, but I haven’t looked into it specifically.So why did Ubiquiti make that change? I can’t tel, but hopefully it is because eventually that JSON config file (that seem to hold the entirety of the UDM config) will be modified by the Web UI and allow the user to load their own certificates ? One can dream 😃
That being said, forcing a new CA chain onto all their users without any early warning is certainly not professional, with many users complaining about connection refusals from Apple (and Android) devices that suddently get a certificate change (for another untrusted one, mind you) https://community.ui.com/questions/UniFi-OS-3-2-7-CA-Certificate-changes-break-Radius-backed-802-1x-authentication/9a5d4fb9-f791-4bec-81b5-3b9cc0c7853a#answer/23a7c99a-e1f4-410f-95fb-670b4fb426d3
I know this is “late” in the discussion, but I can also confirm that the certs are being replaced by
udapi-server
starting process:From
journalctl -u udapi-server
:And using
inotifywait
to monitor file changes in the certs directory:That being said, I’m unable to find the source of these certificates, nor which exact process does the replacement.