Repository navigation
|
I've created a reencrypt using the following configuration apiVersion: route.openshift.io/v1
kind: Route
metadata:
name: keycloak-route-route
annotations:
haproxy.router.openshift.io/balance: roundrobin
haproxy.router.openshift.io/disable_cookies: "true"
spec:
host: keycloak.apps.okd-test.com
to:
kind: Service
name: keycloak-service
port:
targetPort: https
tls:
termination: reencrypt
certificate: configured-certificate
key: certificate-key
caCertificate: ca-certificate
destinationCACertificate: ca-certificateWhich should result in the same as following the instructions added in the following PR #36809 All that I'm presented with when I try to access keycloak is the standard openshift/okd error page that the service isn't running. I've double checked that the route and service is to my knowledge configured correctly, and checked that the router in OKD say's if the route is available. Is there any sugestion on what I might have missconfigured here or is this a bug in either keycloak or OKD that needs to be reported? |
Replies: 1 comment 12 replies
|
Can you provide what is shown in the Route and Keycloak status fields? |
|
The next things to check are:
|
|
curl fails with the following error message I have not found any documentation explaining if the certificate used by keycloak should be an internal cluster use only certificate or the regular external one when using reencrypt. |
Great, this should confirm that it's a problem with the Route definition.
My understanding is that as long as destinationCACertificate establishes trust for the service's certificate you should be good - you should even be able to use a self-signed cert - https://tonyhickman-15096.medium.com/urbancode-deploy-overriding-self-signed-certificates-in-openshift-2927215ab42a There is an outstanding issue about supporting service annotations in the keycloak CR #23283 to use service serving certificates. If you want to use service serving certificates, you are free to add annotations to the Service created by the operator, and it will not be removed as the operator is using server side apply, which respects field ownership. |
|
The problem was that I didn't include the full ca chain including the root from our certificate authority. I've been taught to not include the root when creating the CA chain, since most software uses the root store on the computer, or in the container it's running on. I do not have any good sugestions on how to update the re-encrypt documentation for keycloak to include that the |
|
Full certificate chains should be provided by the server when you are dealing with TLS. Browsers have certain additional functionalities that may be able to identify the full chain of the certificate even when it is not correctly provided, but this may not be available for all applications (see https://security.stackexchange.com/a/278819 for some examples where this may not make sense). In the case of the reverse proxy you are using (from the config it seems it may be HAProxy), such functionality may simply not be necessary. When configured with a re-encryption proxy (commonly the case when dealing with a layer-7 proxy), Keycloak does not need to have a certificate trusted by users (signed by a public CA, or internal user-facing CA). This is because the user connects to the proxy, which decrypts the traffic, updates various info in it and then sends a request to Keycloak with the updated information. In this architecture the proxy is a web server from the user's point of view (and needs a certificate that is trusted by the user's system), and a client for the Keycloak server. As such, the certificate used by Keycloak is only ever visible for the proxy, and having the proxy trust Keycloak's certificate is enough. |
The problem was that I didn't include the full ca chain including the root from our certificate authority. I've been taught to not include the root when creating the CA chain, since most software uses the root store on the computer, or in the container it's running on.
I do not have any good sugestions on how to update the re-encrypt documentation for keycloak to include that the
destinationCACertificatechain needs to include the root, and that it in that regards should be different from thecaCertificatefield.