Description of problem: Generate self signed certificates for a wildcard domain, eg, *.example.com. Create a route with wildcardpolicy enabled and point to host: test.example.com When accessing the route via test.example.com, it will use the self signed certs for encrypting, when accessing the route via any other host which has the subdomain example.com, it will use the router provided certs. Version-Release number of selected component (if applicable): openshift v3.4.0.23+24b1a58 kubernetes v1.4.0+776c994 etcd 3.1.0-rc.0 ose-haproxy-router v3.4.0.23 40c9b18e47df How reproducible: always Steps to Reproduce: 1. Setup env with router enables wildcard route 2. Create pod and service $ oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/routing/caddy-docker.json $ oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/routing/edge/service_unsecure.json 3. Create route which contains wildcard self signed certs with wildcardPolicy enabled $ oc create -f route.json cat route.json { "apiVersion": "v1", "kind": "Route", "metadata": { "name": "edge-route" }, "spec": { "wildcardPolicy": "Subdomain", "host": "test-edge.example.com", "to": { "kind": "Service", "name": "service-unsecure" }, "tls": { "termination": "edge", "key": "-----BEGIN PRIVATE KEY-----\n<<<REDACTED>>>\n-----END PRIVATE KEY-----\n", "certificate": "-----BEGIN CERTIFICATE-----\n<<<REDACTED>>>\n-----END CERTIFICATE-----\n", "caCertificate": "-----BEGIN CERTIFICATE-----\n<<<REDACTED>>>\n-----END CERTIFICATE-----" } } } 4. Access the route via the host which specified in the route json 5. Access the route via any host with the subdomain suffix Actual results: 4. $ curl --resolve test-edge.example.com:443:10.8.174.93 https://test-edge.example.com/ -vk * Added test-edge.example.com:443:10.8.174.93 to DNS cache * Hostname test-edge.example.com was found in DNS cache * Trying 10.8.174.93... * Connected to test-edge.example.com (10.8.174.93) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * skipping SSL peer certificate verification * ALPN/NPN, server did not agree to a protocol * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: * subject: OU=OS,O=RH,E=bmeng,C=CN,ST=BJ,CN=*.example.com * start date: May 25 08:12:58 2016 GMT * expire date: May 23 08:12:58 2026 GMT * common name: *.example.com * issuer: E=example,CN=www.exampleca.com,OU=Test CA,O=Default Company Ltd,L=Default City,ST=SC,C=US > GET / HTTP/1.1 > Host: test-edge.example.com > User-Agent: curl/7.43.0 > Accept: */* 5. $ curl --resolve ananany.example.com:443:10.8.174.93 https://ananany.example.com/ -vk * Added ananany.example.com:443:10.8.174.93 to DNS cache * Hostname ananany.example.com was found in DNS cache * Trying 10.8.174.93... * Connected to ananany.example.com (10.8.174.93) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * skipping SSL peer certificate verification * ALPN/NPN, server did not agree to a protocol * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: * subject: CN=router.default.svc * start date: Nov 08 09:52:28 2016 GMT * expire date: Nov 08 09:52:29 2018 GMT * common name: router.default.svc * issuer: CN=openshift-service-serving-signer@1478597570 > GET / HTTP/1.1 > Host: ananany.example.com > User-Agent: curl/7.43.0 > Accept: */* Expected results: Should always use the self signed certs for *.example.com Additional info:
Should be some related discussion found here http://stackoverflow.com/questions/31262448/can-i-use-wildcard-sni-matching-with-haproxy
I understand why they may want that, but it the behavior was not what we planned. Ram, do you want to weight in? Otherwise, I'd suggest opening this as an RFI.
I've made the changes but will leave it to you @Ben to decide if you want to merge it or not. PR is: https://github.com/openshift/origin/pull/11862 Thx
Not too scary. I've added it to the merge queue.
This has been merged into ose and is in OSE v3.4.0.25 or newer.
Checked on openshift v3.4.0.25, issue has been fixed. Access the route via any host which has the same suffix will use user provided certs.
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