Description of problem: Using an improperly formatted cert for a route, using a key that had a passphrase on it, caused an outage in the router for all customers. It appears the offending cert causes issues when re-encrypting the route on the F5. When the certificate was created they had a passphrase on it, which needs to be removed for it to work. Apparently this caused a fatal error which required deleting the route to recover from. One customer using an improperly formatted certificate caused a router outage for the whole environment. Version-Release number of selected component (if applicable): # openshift version openshift v3.2.1.4-1-g1864c8f kubernetes v1.2.0-36-g4a3f9c5 etcd 2.2.5 How reproducible: Unverified Actual results: The application which had the bad cert showed these logs: [ALERT] 255/130843 (51214) : parsing [/var/lib/haproxy/conf/haproxy.config:112] : 'bind 127.0.0.1:10444' : unable to load SSL private key from PEM file '/var/lib/containers/router/certs/example.pem'. unable to load SSL private key from PEM file '/var/lib/containers/router/certs/example.pem'. unable to load SSL private key from PEM file '/var/lib/containers/router/certs/example.pem'. [ALERT] 255/130843 (51214) : Error(s) found in configuration file : /var/lib/haproxy/conf/haproxy.config [ALERT] 255/130843 (51214) : Fatal errors found in configuration. The fatal error from the logs in the router was: [ALERT] 255/130843 (51214) : Error(s) found in configuration file : /var/lib/haproxy/conf/haproxy.config [ALERT] 255/130843 (51214) : Fatal errors found in configuration. Expected results: Either throw a warning and refuse to serve route or else work. Additional info: Is there any way to automatically sanity check certificates before they are used in routes? The problem can be rectified by deleting the route.
Is the cert in the route broken? If so, can they include the route yaml. Obviously, if it contains sensitive keys, they shouldn't give it to us.
Defaults set to true with PR: https://github.com/openshift/origin/pull/11218
This has been merged into ose and is in OSE v3.4.0.16 or newer.
Verified this bug on haproxy images (id: 227ebcf6c7d8). the default EXTENDED_VALIDATION is true. and the invalid route will be skip.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:0066