Authentik OIDC Provider Does Not Use TLS Certificates

[red-drover]

I've been bashing my head against this for a few days now, so hopefully I'm clear on whats going on.

Describe the bug
I have a docker-compose file with Apache Guacamole, nginx, and Authentik all inside. I have Guacamole successfully using the proxy as a TLS terminator for web access. When I configure Authentik to provide OIDC to support Guacamole, I cannot access the webpage. Troubleshooting from inside shows that the provider is using a self-signed certificate even though I have valid LetsEncrypt certificates for both Guacamole and Authentik.

To Reproduce
Steps to reproduce the behavior:

1. Upload Certificates to Authentik
2. Configure Provider to use newly added certificates
3. Configure Guacamole to use OIDC/Authentik
4. Authentication fails during attempts to retrieve jwks

Logging into the Guacamole container and running openssl s_client as well as curl both retrieve self signed certs from Authentik. I have tried both from Authentik "inside" of the Nginx proxy, as well as external to it.

Expected behavior
Authentik would use the certificate uploaded for TLS to my application

Screenshots

Logs
sconnect.txt
curl.txt

Version and Deployment (please complete the following information):

• authentik version: 2024.4.2
• Deployment: docker-compose, docker guacamole, docker nginx as well as "bare metal" nginx as an alternative

Additional context
Like I said, I've bashed my head around and my configuration is a bit mixed up at this point, but I cannot get the app to serve the proper certificates, and I cannot get it to work behind the Nginx proxy. Communications with Guacamole work fine if I remove TLS, but I cannot do that safely.

[huckleberry1989]

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.

[red-drover]

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.