udm-le: Wifiman does not work on UDMP if signer/intermediate cert is imported

I think if the default behavior were to stay the same (deploying the bundle), we could get away with leaving this new behavior in the main script behind a boolean, and maybe just add a deploy step to the main case statement at the bottom to handle just running the deployment of the certificate, to avoid the certificate limit.

The latest release is now out and I have reports that WiFiman is working as intended.

Hi all, we have had some generous users work on getting 2.x support finalized, please check out this PR and see how things are working for your use case: https://github.com/kchristensen/udm-le/pull/70

Thanks, gentlemen. I’ve been following along with this issue/request for several months now. Unfortunately I’m not as well versed as some of the people in this thread to make any sort of fix/recommendation.

While I haven’t tried the latest merge, I did swap out the podman commands at the end of ‘udm-le.sh’ as mentioned above by @rloomans which worked like a charm - I’ve got a wildcard cert provisioned to the hotspot guest portal as well as the controller portal and it’s working without issue, as well as WiFiMan. I’ve only tested iOS devices, but no issue that I’ve observed so far; perhaps it’s already got the root/sub CA’s items already, in my case.

Cheers to you all for the work here! I think the only thing I’ve yet to figure out is how to get this to work with the onboard unifi RADIUS server, but that’s beyond the scope of this thread.

Happy to provide any further information where I can, if it helps.

@martintoreilly I haven’t had a guest portal setup previously, but I set one up quickly and tested this out - it is working for me using the password and voucher authentication types

.

@martintoreilly this seems like a reasonable approach I think, as long as the documentation is clear that:

1. Exactly what setting NO_BUNDLE is supposed to do (I think captive portal/wifiman aren’t super commonly used, so I don’t want to confuse people unnecessarily)
2. Setting NO_BUNDLE at least for now is experimental so YMMV

If you want to PR something up, I can merge it into main, and we’ll hold off on a “release” for some period of time until we get some more feedback about how it’s working?

Re: --force-deploy I’ve always just runudm-le.sh initial when I need to force a new cert or deploy since that will forcibly re-issue a new certificate and deploy it, is there something else your idea would do that isn’t covered by that?

@kwschnei @kchristensen what do you think of the following suggestion? This preserves the current behaviour as default but allows individual users to decide whether to use the full chain bundle or a server-only cert for the hotspot captive portal / wifiman? If we then see that the server-only cert causes no issues with the hotspot captive portal across a wide enough range of devices, we could later decide to set the server-only certificate option as default behaviour.

1. Add aNO_BUNDLE boolean flag in udm-le.env. This would mirror the currently inoperative --no-bundle flag for the lego command. I’m not wedded to the name and we might want to consider adding a suffix indicating that this only applies to the hotspot + wifiman functionality (is this the API endpoint for both of these or do they use separate endpoints)?
2. Replace the call to the ace.jar import_key_cert program in udm-le.sh with a function that uses openssl and keytool to import either the full chain (default) or the server-only certificate (if NO_BUNDLE is set in udm-le.env).

[Edit: I think it would also be worth adding a --force-deploy option to udm-le.sh to allow people to manually trigger a redeployment of their existing certificate after making a change to the NO_BUNDLE flag. The deployment code currently only runs if the certificate has been renewed.]

I can confirm this has solved this issue for me as well.

@kchristensen - do you want to make this change, or do you want me to attempt my first pull request?

I too can confirm that @martintoreilly’s commands make WiFiman work for me.

I tested this by replacing this line in udm-le.sh:

podman exec -it unifi-os ${CERT_IMPORT_CMD} ${UNIFIOS_CERT_PATH}/unifi-core.key ${UNIFIOS_CERT_PATH}/unifi-core.crt

with

podman exec -it unifi-os openssl x509 -in ${UNIFIOS_CERT_PATH}/unifi-core.crt -out ${UNIFIOS_CERT_PATH}/unifi-core-server-only.crt
podman exec -it unifi-os openssl pkcs12 -export -inkey ${UNIFIOS_CERT_PATH}/unifi-core.key -in ${UNIFIOS_CERT_PATH}/unifi-core-server-only.crt -out ${UNIFIOS_CERT_PATH}/unifi-core-key-plus-server-only-cert.p12 -name unifi -password pass:aircontrolenterprise
podman exec -it unifi-os cp /usr/lib/unifi/data/keystore /usr/lib/unifi/data/keystore.backup
podman exec -it unifi-os keytool -delete -alias unifi -keystore /usr/lib/unifi/data/keystore -deststorepass aircontrolenterprise
podman exec -it unifi-os keytool -importkeystore -deststorepass aircontrolenterprise -destkeypass aircontrolenterprise -destkeystore /usr/lib/unifi/data/keystore -srckeystore ${UNIFIOS_CERT_PATH}/unifi-core-key-plus-server-only-cert.p12 -srcstoretype PKCS12 -srcstorepass aircontrolenterprise -alias unifi -noprompt

@mtalexan I am seeing this issue with a single chain in the Java keystore.

From within a unifi-os shell:

root@ubnt:/# keytool -list  -keystore /data/unifi/data/keystore -v
Enter keystore password:  
Keystore type: jks
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: unifi
Creation date: Jan 11, 2022
Entry type: PrivateKeyEntry
Certificate chain length: 3
Certificate[1]:
...

SSH’d into the UDM directly as root outside the unifi-os shell:

# grep /data/unifi/logs/server.log -e "WiFiman" -B 1
...
[2022-01-11T03:55:06,884] <inform-4> ERROR system - Unable to read certificate from the unifi chain. There are 3 certificates, but exactly 1 is expected
[2022-01-11T03:55:06,893] <inform-4> ERROR dev    - WiFiman enabled but could not find certificate, skipping config