View Issue Details

IDProjectCategoryView StatusLast Update
0014912BuildsysCi.centos.org Ecosystem Testingpublic2018-06-06 22:01
ReporterMartin.Pitt 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Summary0014912: Route TLS passthrough termination has wrong "outside" default certificate
DescriptionMy Cockpit image server has this route:

```
- kind: Route
  apiVersion: v1
  metadata:
    name: images
  spec:
    to:
      kind: Service
      name: cockpit-images
    port:
      targetPort: 8443
    tls:
      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 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:8.43.84.246 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?

Thanks!
TagsNo tags attached.

Activities

Martin.Pitt

Martin.Pitt

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