RADIUS certificate question about ubios-cert HOT 5 CLOSED

True to form, I started tinkering with it before waiting.

Here's what I found:

• This comment suggested thatunifi-os restart was insufficient to deploy the RADIUS cert. I found the same result. It appears a different command or full reboot is needed.
• My iOS device required me to trust the untrusted Let's Encrypt certificate.
• My Mac also required me to trust the untrusted Let's Encrypt certificate AND indicated that the root and intermediate R3 Certificates had expired.
• If I use the${ACMESH_ROOT}/${ACME_CERT_NAME}/fullchain.cer instead of the ${ACMESH_ROOT}/${ACME_CERT_NAME}/${ACME_CERT_NAME}.cer for my /mnt/data/udapi-config/raddb/certs/server.pem my Mac doesn't complain about the R3 Certificate being expired.

I would like for

• iOS device to trust the certificate by default, but I don't think that's possible without deploying some sort of MDM profile where I configure my device to trust this cert.
• the renewal script to trigger a restart of whatever service handles the deployment of the radius cert. I have maxed out my Let's Encrypt renewals via testing, but I wonder if radiusd restart or podman restart unifi-os might do the job?

from ubios-cert.

Thank you for spending your time on debugging this. Not having any documentation by Ubiquiti does not help...

Layman speaking here, doing his best to get it properly working... it seems the certificate chain is flawed and needs to be fixed. It should be

Root Certificate <-- CA certificate <-- server certificate where "<--" means "is trusted by...".

/mnt/data/udapi-config/raddb/certs/server.pem is the server certificate (for my device udmpro.domain.tld) and /mnt/data/udapi-config/raddb/certs/ca.pem will be the "intermediate certification authority" / CA certificate which needs trust by the Root Certificate. That seems broken right now, so we have to manually trust the server certificate (what we do not want).

fullchain.cer does contain all three certificates, but actually here you may have hit a trap as on my system the root from full chain.cer shows as "expired" as well: https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ (well, why make life easy). Maybe you "fixed" that by setting the trust level to "trusted" during your debugging efforts.

When I link to the unifi-os container and look into /etc/ca-certificates.conf, it seem that mozilla/ISRG_Root_X1.crt gets preinstalled as a trusted root certificate. So that should be fine.

The created "ca.cer" ("R3") cert

links to http://x1.letsencr.org where a proper, current, working root certificate is stored.

so we should be OK by putting the intermediate cert in the right place and getting the RADIUS server to reload.

I will have a look at that over the next days.

from ubios-cert.

@alxwolf

That's really interesting. By the way, I am in no rush to resolve this; this is just a fun sidequest for me.

I did not trust the expired R3 DST certificates on my Mac (it would not have helped anyway because it was expired).

However, when I inspected my ${ACMESH_ROOT}/${ACME_CERT_NAME}/fullchain.cer on https://tools.keycdn.com/ssl it appears to be linked to the expired DST certificate in the link you referenced:

Intermediate certificate required. Unable to get issuer certificate.

1. Subject CN: unifi.domain.tld > Issuer CN: R3
2. Subject CN: R3 > Issuer CN: ISRG Root X1
3. Subject CN: ISRG Root X1 > Issuer CN: DST Root CA X3

The only R3 certificate I have on my Mac is the one that expires: Monday, September 15, 2025, so I'm not sure how using fullchain.cer as my /mnt/data/udapi-config/raddb/certs/server.pem caused my Mac to present the correct root CA instead of the expired one.

Here's Apple's official explanation why iOS devices will not automatically trust RADIUS certificates without deploying some sort of MDM profile (emphasis mine):

During the 802.1X negotiation, the RADIUS server presents its certificate to the device supplicant automatically. The RADIUS server certificate must be trusted by the supplicant by either anchoring trust to a particular certificate or to a list of expected hostnames matching the certificate’s host. Even when a certificate is issued by a known CA and listed in the trusted root store on the device, it must also be trusted for a particular purpose. In this case the server’s certificate must be trusted for the RADIUS service. This is done either manually, when joining an enterprise network as the user is prompted to trust the certificate for the connected Wi-Fi network, or in a configuration profile.

from ubios-cert.

So we may be good as we have to "sign off" manually anyhow?? Also got this weird issue that freshly issued certificates carry the non-trusted issuer certificate (in fullchain.cer).

I may have found the trigger file to restart the RADIUS daemon: /usr/sbin/rc.radiusd restart

need to investigate further.

Update: another thread to poke around... but this is for the USG and UDM-P differs a lot.

from ubios-cert.

Closing this issue and have established a new issue #14 with a separate branch to deal with it.

from ubios-cert.