Auto-Generated Certificate incompatible with AWS ELB?

[mentalblock]

I think there is a compatibility issue between the Amazon's Elastic Load Balancer (ELB) and the auto-generated SSL certificate that is created by Web Dashboard. I believe the parameter https://github.com/kubernetes/dashboard/blob/v1.8.3/src/deploy/recommended/kubernetes-dashboard.yaml#L122 creates a self-signed certificate if one is not provided.

When using an AWS Elastic Load Balancer, you can point the backend to a NodePort Service that hits the web dashboard service. I terminate the SSL at the AWS ELB because it is a free, trusted certificate using Amazon Certificate Manager. In summary, the AWS ELB is configured to have a Listener of HTTPS and a backend instance protocol of HTTPS to the web dashboard.

The problem is when the backend instance protocol is HTTPS to the auto-generated certificate of web dashboard, the connection hangs. When I replace the auto-generated certificate with another self-signed certificate, it works fine.

Environment

Dashboard version: 1.8.3
Kubernetes version: 1.9.3
Operating system: CentOS 7.4
Node.js version: N/A
Go version: N/A

Steps to reproduce

1. After getting the web dashboard hosted on Kubernetes with https://github.com/kubernetes/dashboard/blob/v1.8.3/src/deploy/recommended/kubernetes-dashboard.yaml, overwrite the web dashboard service with a type of NodePort
2. Create an AWS Elastic Load Balancer that uses an HTTPS Listener, and the backend instance protocol set to HTTPS. Make sure the load balancer is configured to use a server that is running a Kubernetes instance that is running the NodePort. Set the backend port to the port listed in the NodePort Service.

Observed result

Connections hang because I believe there is a compatibility issue with the auto-generated certificate created by web dashboard.

Expected result

The web dashboard to load correctly without any certificate warnings.

Comments

Replacing the web dashboard's auto-generated SSL certificate with another self-signed certificate creates the expected result. This is why I believe there is something amiss with the auto-generated certificate or Amazon has some strange implementation on their side regarding their SSL client.

[floreks]

Auto-generated certificates contain only very basic information and might not be compatible with external providers. It is possible that some information are missing that are required by AWS LB or maybe there is an issue with ECDSA signing. Anyway, that is why we have added an option to override this certificates with custom ones.

[mentalblock]

I would think the main reason why the option to override the certificates exists is so that we can integrate it with our own Certificate Authority, whether it be a paid one or an internal PKI.

I believe it would make the setup of the web dashboard a lot simpler if the compatibility issue was addressed for those who choose not to verify the certificate. This was my situation and I had to go through the trouble (albeit 10 minutes for me) to create a certificate signed by my internal CA.

At the very least, perhaps my report should be confirmed and have its place in the official documentation? It took me around 30 minutes to isolate the issue and that is something I do not wish other users to experience.

At any rate, thanks for taking the time.

[floreks]

I'd like to fix that for AWS, however, we don't have resources to prepare environment on AWS to test it and actually isolate the issue. It would be nice if we could make it work by default in such setups.

[mentalblock]

Maybe it is related to the cipher set. Similar to kubernetes/ingress-nginx#2182

[mhobotpplnet]

Have you ever found the workaround for this guy? I have very similar issue.

[Jarch09]

Same experience. Used the recommended setup, but replaced the Service with an ELB (using ACM certificate) Service. The ELB is unable to access the dashboard via https. The alternative http method works, but want to use the recommended setup

[hollowimage]

Likewise, same issue here. using k8s 1.10.6

2018/10/11 19:33:09 http: TLS handshake error from 100.108.0.0:21700: tls: no cipher suite supported by both client and server
2018/10/11 19:33:09 http: TLS handshake error from 100.109.0.0:59924: tls: no cipher suite supported by both client and server
2018/10/11 19:33:09 http: TLS handshake error from 100.108.0.0:21704: tls: no cipher suite supported by both client and server
2018/10/11 19:33:09 http: TLS handshake error from 100.109.0.0:59928: tls: no cipher suite supported by both client and server
2018/10/11 19:33:09 http: TLS handshake error from 100.108.0.0:21708: tls: no cipher suite supported by both client and server
2018/10/11 19:33:09 http: TLS handshake error from 100.109.0.0:59932: tls: no cipher suite supported by both client and server
2018/10/11 19:33:09 http: TLS handshake error from 100.108.0.0:21712: tls: no cipher suite supported by both client and server
2018/10/11 19:33:09 http: TLS handshake error from 100.109.0.0:59936: tls: no cipher suite supported by both client and server

Plus, now with browser updates, chrome refuses to let people create security exceptions without major settings overhaul, as does IE.

[ttimasdf]

+1, this auto-generated certificate is not compatible with python, Chrome... anything! Only curl could manage to connect.

[floreks]

It is compatible. i.e. Chrome has chrome://flags/#allow-insecure-localhost flag that you can enable to allow access for insecure certificates on localhost. It's a configuration issue. Also, there is always an option to use valid custom certificates.

[ghost]

I am experiencing a pretty-much identical problem. This is NOT unique to AWS, the untrusted certificates methodology affects almost anybody who wants to arrange their own trusted TLS termination in front of the service.

The solution I would like to see is the option to turn off untrusted SSL/TLS and use vanilla HTTP inside K8s, so I can terminate trusted TLS at the edge/ingress.

What I want to do is make the dashboard accessible to people who don't have kubectl [proxy].
What I can't do is supply the container with a trusted certificate because we have a strict policy on where they go.

Edit: I see a vanilla port 9090 listed, but nothing is listening on it in the container. Stale documentation?

[floreks]

You can simply remove autogeneration of certificates, then provide --enable-insecure-login flag and configure your own reverse proxy that will inject authorization header in every request to Dashboard. This way you can have your own IdP that will restrict access to Dashboard and provide access with limited permissions.

[maciaszczykm]

Closing as stale, please reopen if this is still valid.