Authentik OIDC Provider Does Not Use TLS Certificates about authentik HOT 3 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.

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.

Not sure if I can "ping" a user here - @huckleberry1989

So, I ended up abandoning Authentik in favor of Keycloak. I got it working, forgot how I got it working, and then had to re-solve the problem today. Ultimately its pointing towards a hosts/DNS type problem, though it could be also certs/SAN. Probably a few ways to skin this cat.

tl;dr: I had to translate the external IP address to the internal IP address of my server for Guacamole to properly pull the JWT. I'm not sure if the same answer works when Authentik produces the self-signed cert upon SSL connect (this is still with Keycloak, see). The exact command I ran was:

iptables -t nat -A PREROUTING -d <PUBLIC IP> -p tcp -j DNAT --to-destination <PRIVATE IP>

Im not sure how deep I got into my own config, but currently I have a docker-compose file with Guacamole and its various components, and then another directory with the docker-compose for Authentik (now Keycloak) in its own folder. The intended goal was to "bolt on" the IdP to the existing deployment in my homelab. So ultimately both services run on the same host with the same internal IP, but on different docker networks. I did double check my hosts file, and I placed the public IPs with the resolution to my actual DNS name in it, but my internal IP is only shown with the host name, not the actual web DNS name.

So ultimately, I solved it with an iptables NAT rule, but there might be other options, including SAN names and proper reworking of the hosts file. I did previously test a "combined" deployment with both services + dependencies in the same docker-compose and docker networks, but never got it to work before. It too could probably be tweaked to work. Hope that helps with your attempts here with Authentik. I'm not sure yet what the "optimal" solution is.

from authentik.