View Issue Details

IDProjectCategoryView StatusLast Update
0014912CentOS CIgeneralpublic2020-01-29 16:34
ReporterMartin.Pitt Assigned To 
Status resolvedResolutionfixed 
Summary0014912: Route TLS passthrough termination has wrong "outside" default certificate
DescriptionMy Cockpit image server has this route:

- kind: Route
  apiVersion: v1
    name: images
      kind: Service
      name: cockpit-images
      targetPort: 8443
      termination: passthrough

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 </dev/null
subject=/C=US/ST=North Carolina/L=Raleigh/O=Red Hat Inc./CN=*
issuer=/C=US/O=DigiCert Inc/ SHA2 High Assurance Server CA

However, this is not consistent - if you open 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: https://cockpit-tests:443/
* SSL certificate problem: unable to get local issuer certificate

And of course a simple `curl` 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?

TagsNo tags attached.




2018-06-06 20:26

reporter   ~0032024

Sorry, this was pilot error. I messed up SNI on the client side, now it's working as it should. I don't see how to close this issue, can you please do that? Thanks!

Issue History

Date Modified Username Field Change
2018-06-06 10:47 Martin.Pitt New Issue
2018-06-06 20:26 Martin.Pitt Note Added: 0032024
2018-06-06 22:01 bstinson Status new => resolved
2018-06-06 22:01 bstinson Resolution open => fixed
2020-01-29 16:34 siddharthvipul1 Project Buildsys => CentOS CI
2020-01-29 16:34 siddharthvipul1 Category Ecosystem Testing => general