Yes, I had tried re-creating the route and that didn't work.
Eventually I did manage to solve it. The 'Destination CA Cert' property for the route was (automatically) filled with some place holder 'backwards compatibility' text. When I replaced this with the CA cert used by the service (found in the secrets) things started working again.
I have no idea why this stopped working and why this fix became necessary.
On 07/10/18 21:14, Joel Pearson wrote:
Have you tried looking at the generated haproxy file inside the router? It might give some hints as to what went wrong. I presume you’ve already tried recreating the route?
On Wed, 3 Oct 2018 at 2:30 am, Tim Dudgeon <tdudgeon ml gmail com> wrote:
We've hit a problem with a HTTPS route that used to work fine has now
Instead of the application we're are seeing the 'Application is not
available' page from the router.
The route is using 'reencrypt' termination type to hit the service on
The service itself and its pod is running OK as indicated by being able
to curl it from inside the router pod using:
curl -kL https://secure-sso.openrisknet-infra.svc:8443/auth
(the -k is needed).
An equivalent HTTP route that hits the HTTP service on port 8080 is
The only thing I can think of that might have caused this is redeploying
the master certificates using the 'redeploy-certificates.yml' playbook,
but I can't see how that would cause this.
This is all with Origin 3.7.
Any thoughts on what might be wrong here?
users mailing list
users lists openshift redhat com