Trailing periods in base domains

[wgordon17]

Version

$ openshift-install version
bin/openshift-install v0.5.0-master-36-gb4f5ceb6bfde8d3dc0e29f708e0494488ea37ee0
Terraform v0.11.10

Platform (aws|libvirt|openstack):

aws

What happened?

Running the provided help script for base domain (aws route53 list-hosted-zones --query 'HostedZones[? !(Config.PrivateZone)].Name' --output text) causes the output of a domain with a trailing period, e.g., example.com.. Copy/pasting this directly into the installer causes the generated kubeconfig to also contain the trailing period...there may also be other areas where this trailing period sticks around. But nothing ended up working, so I just nuked the cluster and rebuilt without the trailing period.

What you expected to happen?

Either automatically strip the trailing period, or provide some validation on the text to ensure only a validly formatted domain name is accepted

How to reproduce it (as minimally and precisely as possible)?

$ openshift-installer create cluster
? SSH Public Key <none>
? Base Domain example.com.
....

Check kubeconfig

[wking]

My initial thought was to strip the dot, like we used to do in #359. But it turns out that rooted domain names have some nice qualities (e.g. see issues with search and non-rooted domain names discussed in RFC 1535). My guess is that the issue is with X.509 validation for rooted domain names. Checking someone who's probably done things right:

$ openssl s_client -connect www.google.com.:443 </dev/null
...
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com
   i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
 1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
   i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEgjCCA2qgAwIBAgIIRytDotOLd+owDQYJKoZIhvcNAQELBQAwVDELMAkGA1UE
BhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczElMCMGA1UEAxMc
R29vZ2xlIEludGVybmV0IEF1dGhvcml0eSBHMzAeFw0xODExMDcwODU5MDBaFw0x
OTAxMzAwODU5MDBaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
MRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKDApHb29nbGUgTExDMRcw
FQYDVQQDDA53d3cuZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAIjRpZJVKkvBDJ52gm07mNau7TjxrEPfLam1To1buoSELOZELKhFGX4p
t66gmDYW1OtvIRV3DBAURgcwcdgzMo/HsMpEi5u61mvljstU9E6gdon1pjNeBacO
s+fFemPP+AaLUD7GLgvQlfbRfjtglVs1m8/OLjAokbZeUVYA+XN741iVdlFV+G+y
n0XjSsBcrH4n6DKTT5VHpgyuSDbsgfNSEXWQlDL9p+Un5JDHpB8fs4aA1jDgL0iQ
5SU3asbGXMw9WaOrvXqapgs+WczSFkhwRzXlk/8YoiCkooyBwT6BUVQP+w/SxQoA
V1RDwnes7DO6VEAbbZHAVCIhb6zlZ/UCAwEAAaOCAUIwggE+MBMGA1UdJQQMMAoG
CCsGAQUFBwMBMBkGA1UdEQQSMBCCDnd3dy5nb29nbGUuY29tMGgGCCsGAQUFBwEB
BFwwWjAtBggrBgEFBQcwAoYhaHR0cDovL3BraS5nb29nL2dzcjIvR1RTR0lBRzMu
Y3J0MCkGCCsGAQUFBzABhh1odHRwOi8vb2NzcC5wa2kuZ29vZy9HVFNHSUFHMzAd
BgNVHQ4EFgQUjiThJkr0KiZCgY0aUMSvIVZX+lowDAYDVR0TAQH/BAIwADAfBgNV
HSMEGDAWgBR3wrhQmmd2drEtwobQg6B+pn66SzAhBgNVHSAEGjAYMAwGCisGAQQB
1nkCBQMwCAYGZ4EMAQICMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwucGtp
Lmdvb2cvR1RTR0lBRzMuY3JsMA0GCSqGSIb3DQEBCwUAA4IBAQC63SRQXmOERwmC
nAMwFhrXePAypKrdRwvgN/F0t0sp7fSqbYwnTKR9CK34f5vCD+xQcPNxSYnvbjO6
Jh+U4z6aZUZN+jwLO4RoSxbVFp3eQFNVPUxCiWDTLxTQr9MbE8/fzB04ChnBMHn4
KcoOQTfLA+gisEHJQ+U/Jqit60+brQoiT7Gaw26lTZxY2TsKe9UaIu86lIh1RL1S
a7emfhuOQGlAyT/oTaUhmoF343UjD/g4+d03BNFzIrp6bHbqY6QkpkWEe5lgReZr
PNRfKOT3BsYEpLCEfuQnLXAPKV7aFaRW1nvo1aOeYrEO042CNYV8WDXPGIFiO0Su
cA/7iPSI
-----END CERTIFICATE-----
...

Dropping that cert into server.crt, we can inspect it with:

$ openssl x509 -in server.crt -noout -text | grep google
        Subject: C=US, ST=California, L=Mountain View, O=Google LLC, CN=www.google.com
                DNS:www.google.com

so the cert only contains non-rooted domains, but my OpenSSL 1.0.2k-fips and Firefox 60.2.0 both handle it fine. Checking with Go:

$ go version
go version go1.10.3 linux/amd64
$ cat test.go
package main

import (
	"fmt"
	"net/http"
)

func main() {
	resp, err := http.Get("https://www.google.com./")
	fmt.Println(resp.Status, err)
}
$ go run test.go 
200 OK <nil>

So that seems fine too. So as far as I can tell, the trailing period should work, and in some cases (where you want to bypass search) it is preferred. Can you provide more details on "But nothing ended up working", such as error messages you saw?

[wgordon17]

So, a couple of issues,

1. The server in auth/kubeconfig is listed as https://{CLUSTER_NAME}-api.{BASE_DOMAIN}.:6443. Note the trailing period

2. The web console doesn't come up

3. The web console isn't displayed in the CLI output

    INFO Access the OpenShift web-console here:
    INFO Login to the console with user: kubeadmin, password:
   

4. The API endpoint mentions RBAC issues (no RBAC policy matched)

I suspect this is all related to the trailing dot, because the exact same scenario without it leads to success every time

[wking]

1. The server in auth/kubeconfig is listed as https://{CLUSTER_NAME}-api.{BASE_DOMAIN}.:6443. Note the trailing period

I don't see why that would be a problem. And as discussed in RFC 1535, it is sometimes a good thing.

I dunno about the console and RBAC issues, we should definitely track those down.

[wgordon17]

The kubeconfig server entry may just be a symptom not an actual problem.

[crawford]

Is this still an issue with the latest installer?

[wking]

I still think trailing periods should be supported, but I haven't checked recently to see if they're still broken.

[crawford]

I still think trailing periods should be supported

I agree. I depend on the trailing periods in order to properly do split-horizon.

[wgordon17]

Perhaps we would just need to address where the trailing period is necessary versus where including it may break things (like the .kube/config file)