<p>I set up <strong><a href="https://github.com/kubernetes/kubernetes" rel="nofollow noreferrer">Kubernetes</a></strong> cluster on <strong>aws</strong> using <strong><a href="https://github.com/kubernetes/kops" rel="nofollow noreferrer">kops</a></strong> using <strong><a href="https://github.com/kubernetes/kops/blob/master/docs/aws.md" rel="nofollow noreferrer">this tutorial</a></strong> on official kubernetes github branch.</p>

<p>The cluster set up successfully on AWS, but when I try to run</p>

<pre><code>kubectl get nodes
</code></pre>

<p>or</p>

<pre><code>kops validate cluster
</code></pre>

<p>it says </p>

<pre><code>[user@ip-70-0-0-7 ~]$ kubectl cluster-info
Unable to connect to the server: x509: certificate is valid for *.secure.hosting prod.com, not api.subdomain.mydomain.com
</code></pre>

<p>This is definitely problem with my <strong>x509 certificates</strong>. Just need a gentle push to right direction. Thank you for your precious time and help!</p>

<p><code>NOTE: I am running these commands from outside the cluster from a machine from where I did set up of cluster.</code></p>

<blockquote>
  <p>Unable to connect to the server: x509: certificate is valid for *.secure.hosting prod.com, not api.subdomain.mydomain.com</p>
</blockquote>

<p>I can't tell if those names you listed are examples, or the actual values that <code>kubectl</code> is giving you, but I'll use them as you've written just to keep things simple</p>

<p>If the kubernetes cluster you installed is really accessible via <code>api.secure.hostingprod.com</code>, then updating your <code>$HOME/.kube/config</code> to say <code>https://api.secure.hostingprod.com</code> where it currently says <code>https://api.subdomain.mydomain.com</code> should get things back in order.</p>

<p>Alternatively, if <code>api.secure.hosting prod.com</code> is not an actual domain you can use (for example, if your certificate really does have a space in the hostname), then you have a couple of options.</p>

<p>The cheapest, but least correct, might be to just tell <code>kubectl</code> "I know what I'm doing, don't check the cert" by setting the <code>insecure-skip-tls-verify</code> option under the <code>cluster</code> entry in the <code>$HOME/.kube/config</code> file:</p>

<pre><code>- cluster:
    insecure-skip-tls-verify: true
</code></pre>

<p>The more bothersome, but also most correct, would be to re-issue the certificate for the API server using the actual hostname (apparently <code>api.subdomain.mydomain.com</code>). If you know how, extra-super-best is to also add "Subject Alternate Names" (abbreviated as "SAN") to the certificate, so that in-cluster members can refer to it as <code>https://kubernetes</code> and/or <code>https://kubernetes.default.svc.cluster.local</code>, along with the <code>Service</code> IP address assigned to the <code>kubernetes</code> <code>Service</code> in the <code>default</code> namespace. It's extremely likely that your current certificate has those values, which <code>openssl x509 -in /path/to/your.crt -noout -text</code> will show you what they currently are. If you need help with the openssl bits, CoreOS Kubernetes has <a href="https://github.com/coreos/coreos-kubernetes/blob/v0.8.6/lib/init-ssl" rel="nofollow noreferrer">a shell script</a> they use, which might work as written or if nothing else provide very concrete guidance.</p>

<p>I do recognize that's a lot of words, and also a lot of work, but certificates are super important so getting them as correct as possible will really save everyone heartache down the line.</p>
