Authentik OIDC Provider Does Not Use TLS Certificates about authentik HOT 2 OPEN

I have been struggling with getting Guac to work with OIDC in Authentik as well. I may have slightly different issues than you but one thing I learned may be of use to you. It appears that when you access Authentik via IP address, it will always serve up the default self-signed certificate (which may or may not be the same as the default self-signed cert that you can see in the GUI for use with providers). If you want Authentik to serve up the certificate that you created you will have to access it via hostname. If you don't have one configured you can always use the container name and an entry in your hosts file.

One other important note is that I believe the certificate configured in the provider is going to be used to sign the JWTs and NOT necessarily for the HTTPS connection. The way I was able to ensure that my own cert was used for HTTPS when accessing Authentik via hostname was to set the certificate to be used by the default brand and restart the Authentik container (System > Brands > Edit the authentik-default branhd > Other Global Settings > Web Certificate).

Don't forget to also make sure the certificates you are using have been added to the Guacamole truststore.

Doing all this has not fully solved my issue but it does get you to a point where curl via hostname will serve the correct certificate. Currently my issue is that even adding these certificates to the Guacamole truststore results in failure during JWT validation all due to various javax.net.ssl.SSLHandshakeExceptions listed below.

Using only my self-signed certs results in an apparent inability of Guac to find the correct certificate even when the configured URLs are using hostname. (sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target)

Additionally adding the default certificate that gets served with accessing Authentik via IP results in a verification error due to Guac being unable to find a certificate with a valid SAN matching the Authentik hostname. (javax.net.ssl.SSLHandshakeException: No subject alternative DNS name matching authentik-server-1 found.) This new error appearing as a result of adding this certificate suggests to me that the default certificate is still being used for some reason when it should not be.

Lastly, I updated my self-signed certificate to have an SAN set for the Authentik hostname and receive a certificate verification failure suggesting that the certificate being used for HTTPS signing is still the default certificate rather than the one I have set with an SAN value.

The main problem with this is that the default certificate being used is generated fresh at every container startup so there is no way to change it. At this point the only thing I have left to try is to set up a reverse proxy which I had been avoiding as it wasn't really necessary for my use case. I'm hoping that now that I understand more about which certs are served up and when, putting a proxy between the two services will result in the correct certs being used/expected on both sides.

If you have any breakthroughs please post them here. This is driving me insane.

from authentik.

I don't have much to add but thanks for the comment Huckleberry. I've tried various reverse proxy setups myself, since I already have one deployed for Guacamole and TLS termination. The problem with throwing both Authentik and Guac behind the TLS reverse proxy is that at some point, the browser needs to redirect in the flow and relying on internal IPs doesn't work. I'm sure there's an aspect of my configuration that was incorrect at that point, but I never got Authentik to work behind a reverse proxy either.

The only time I had Authentik+Guac working was on a completely "internal" setup with all HTTP connections and no TLS anywhere, which is totally unsuited for internet access.

from authentik.