[Helm+Tiller TLS configuration] - Error: remote error: tls: bad certificate

[andresguisado]

I've got a ca.cert.pem and ca.key.pem signed by a Trusted CA for my hello world domain and I have configured Helm-Tiller TLS following this doc:

https://github.com/kubernetes/helm/blob/master/docs/tiller_ssl.md

Basically what I did was the following:

• Create key.pem for tiller and helm
• Create a csr.pem for tiller and helm
• Sign Helm and Tiller csr with my ca.cert.pem and ca.key.cert (hello world domain) in order to get my helm and tiller certs signed.
• Do the installation

Tiller is successfully deployed with TLS config and I can see the secret with their certs and ca.cert.pem

By the time helm is trying to communicate to tiller I am getting the following :

[debug] Created tunnel using local port: '61243'

[debug] SERVER: "127.0.0.1:61243"

[debug] Key="helm.key.pem", Cert="helm.cert.pem", CA="ca.cert.pem

**Error: remote error: tls: bad certificate**

I checked all my certificates by OpenSSL command to see the issuer and everything looks ok:

If I created a ca.cert.pem and ca.key.pem self-signed as the official documentation does everything works fine.

Using helm 2.8.1 version.

Any idea on this?

Thank you!

[andresguisado]

Ok, I have got my own answer and it is not related to helm.

When you submit a CSR to a CA, the certificate returned by the CA specifies the following extension:

Basic Constrains:
CA: False 

If that is False you can not use this certificate to sign others to do so you need a TRUE value here and it is not going to happen because then you will be able to create a fake certificate for any site.

Surprisingly, many early SSL implementations in early browsers and even some early versions of OpenSSL did not check the basic constraints field of the certificates in a certificate chain, so this was a vulnerability that could be exploited.

You can see extension of your cert by using openssl command against your cert like this openssl x509 -n ca.cert -text -noout and the documentation where you can see the different x509 extensions is here.

I recommend you using Vault (or similar) as Certificate Authority to create self-signed certs for this purpose.

[bacongobbler]

Awesome writeup @andresguisado. Thanks! Do you think we can close this issue out now or is there some action item still missing here, either in docs or otherwise?

[andresguisado]

@bacongobbler, Maybe a note in the
doc
explaining this concept for the future helmers :-) in order to save them time trying to archive the same than me making clear the risks of having a Root CA signed by a CA with Basic Constraint CA= TRUE?

[bacongobbler]

Sure. Feel like writing that up?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[bacongobbler]

Closing due to inactivity