View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0014912||Buildsys||Ci.centos.org Ecosystem Testing||public||2018-06-06 10:47||2018-06-06 22:01|
|Summary||0014912: Route TLS passthrough termination has wrong "outside" default certificate|
|Description||My Cockpit image server has this route:|
- kind: Route
It uses its own (self-signed) SSL certificate that the client checks. However, the route still presents the external CentOS CI certificate on initial connect:
$ openssl s_client -verify 5 -connect images-cockpit.apps.ci.centos.org:443 </dev/null
subject=/C=US/ST=North Carolina/L=Raleigh/O=Red Hat Inc./CN=*.apps.ci.centos.org
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
However, this is not consistent - if you open https://images-cockpit.apps.ci.centos.org/ in Firefox, it will report the "Cockpituous" self-signed cert.
This breaks curl -- there is no combination of `--cacert`, `--connect-to`, and `--resolve` tricks to make this work, e. g.:
$ curl --verbose --cacert bots/images/files/ca.pem --resolve cockpit-tests:443:220.127.116.11 https://cockpit-tests:443/
* SSL certificate problem: unable to get local issuer certificate
And of course a simple `curl https://images-cockpit.apps.ci.centos.org/` also fails, as apparently once it connected through the openshift proxy, the container's self-signed certificate gets presented. I. e. for some reason there are *two* certificates involved here.
I would actually prefer to not use passthrough termination and use edge instead, with the CentOS CI's default and valid SSL cert. But this does not work with uploads, they cause a
413 Request Entity Too Large
error - presumably as the OpenShift proxy first tries to get the entire request instead of decrypting/pipelining to the container on the fly.
So we'd either need:
* Fix the 413 error with edge termination, or
* Immediately present the container's passthrough SSL certificate on connect.
Or maybe another idea?
|Tags||No tags attached.|