You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the connection to OIDC auth server is encrypted using TLS the certificate must be trusted by the system, or we have to disable verification completely using quarkus.oidc.tls.verification=none.
This is inconvenient when the certificate is provided in Openshift by Service CA that gets mounted as a configmap - the certificate mounted into the image cannot be made trusted system-wide (without elevated privileges) but we cannot set it in Quarkus, neither as PEM certificate nor as a Java Keystore.
In addition to that mutual TLS is not possible at all because we cannot set client certificate.
Implementation ideas
We should follow the same approach as with Resteasy client; properties like quarkus.oidc.tls.trustStore should be added.
The text was updated successfully, but these errors were encountered:
+1, including the client cert part. @sberyozkin
are you going to address that as well in the linked PR (or in a subsequent one) or should we better create yet another issue?
Description
When the connection to OIDC auth server is encrypted using TLS the certificate must be trusted by the system, or we have to disable verification completely using
quarkus.oidc.tls.verification=none
.This is inconvenient when the certificate is provided in Openshift by Service CA that gets mounted as a configmap - the certificate mounted into the image cannot be made trusted system-wide (without elevated privileges) but we cannot set it in Quarkus, neither as PEM certificate nor as a Java Keystore.
In addition to that mutual TLS is not possible at all because we cannot set client certificate.
Implementation ideas
We should follow the same approach as with Resteasy client; properties like
quarkus.oidc.tls.trustStore
should be added.The text was updated successfully, but these errors were encountered: