I have a Keycloak server I’m trying to set up for OIDC with the LXD GUI. I get a hard-error whenever the system tries to connect to the OIDC provider because the certificate isn’t trusted.
The LXD I use is Snapped, and I don’t know where it gets its certificate trust chains from. Is this from the host system’s CA certificates, or is it unique to the LXD snap?
Sorry for the delay in response. LXD uses the host certs (e.g. /etc/ssl/...) to connect to the OIDC provider (regardless of whether or not it is snapped).
@markylaing That’s what I thought, but I added the custom CA to the certs store and it still didn’t work. It’s the same root CA / intermediate CA that I utilize for all my internal stuff, so that doesn’t seem to explain why it wasn’t working.
Ultimately, because of the 10+ days of lack of reply, I ended up hunting down and changing my laptop’s system to incus which works for my personal systems (because on my laptop I use the GUI with a local Keycloak OIDC instance heh), but not for my infra in the cloud.
I’ll re-attempt this with the Cloud system and we’ll see if we can get this functioning as you specified.
May I suggest that this be added to the documentation pages for LXD? “SSL/TLS certificates and Custom CAs” where it indicates that adding to the host system store should solve the problem? Since things aren’t documented.
LXD doesn’t watch /etc/ssl/... for new files being added. The OIDC client has a persistent HTTP client that it uses to refetch JWKs on key rotation at the IdP. It’s likely that your new certs weren’t being picked up. We can do better on our side to surface issues like this (perhaps rejecting the configuration if discovery fails).
Thanks for the heads up, will add more info to the docs and create an issue to make these errors more transparent.
Well the CA certs are in the cert store for > 1yr so those should still have verified. Only new leaf / end entity certs were isssued so it should have seen the CA certs.