2

I am getting below error when I install helm with TLS. I applied the given solution here: https://helm.sh/docs/tiller_ssl/#troubleshooting but, still it's not working.

Error: x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs

generating SSL files:

openssl req -x509 -newkey rsa:4096 -sha256 -keyout helm.ca.key.pem -out helm.ca.cert.pem -subj "/C=CA/ST=St/L=Ms/O=Fi/OU=Dp/CN=tiller" -days 7200 -extensions v3_ca -nodes
openssl genrsa -out ./helm.tiller.key.pem 4096
openssl genrsa -out ./helm.client.key.pem 4096
openssl req -key helm.tiller.key.pem -new -sha256 -out helm.tiller.csr.pem -subj "/C=CA/ST=St/L=Ms/O=Fi/OU=Dp/CN=tiller-server"
openssl req -key helm.client.key.pem -new -sha256 -out helm.client.csr.pem -subj "/C=CA/ST=St/L=Ms/O=Fi/OU=Dp/CN=helm"

echo subjectAltName=IP:127.0.0.1 > extfile.cnf
openssl x509 -req -CA helm.ca.cert.pem -CAkey helm.ca.key.pem -CAcreateserial -in helm.tiller.csr.pem -out helm.tiller.cert.pem -days 1800 -extfile extfile.cnf
openssl x509 -req -CA helm.ca.cert.pem -CAkey helm.ca.key.pem -CAcreateserial -in helm.client.csr.pem -out helm.client.cert.pem  -days 1800 -extfile extfile.cnf

helm init:

helm init --tiller-tls --tiller-tls-cert ./helm.tiller.cert.pem --tiller-tls-key ./helm.tiller.key.pem --tiller-tls-verify --tls-ca-cert helm.ca.cert.pem
kubectl -n kube-system wait --for=condition=Ready pod -l name=tiller --timeout=300s
helm ls --tls --tls-ca-cert ./helm.ca.cert.pem --tls-cert ./helm.client.cert.pem --tls-key ./helm.client.key.pem
RNK
  • 5,582
  • 11
  • 65
  • 133
  • Based on the error message you need to create a certificate with a SAN section having an `IPAddress` member. With recent enough versions of `openssl`, you can use `-addext` for that. See this as an example: https://security.stackexchange.com/a/183973 but use IPAddress instead of DNS. – Patrick Mevzek Sep 09 '19 at 20:30
  • @PatrickMevzek I think, that's what I am doing with this flag: `-extfile extfile.cnf` – RNK Sep 09 '19 at 20:41
  • Unfortunately the file has to be formatted differently, see various extensions online (as you do it the command can not know it is a SubjectAlternativeName extension). You also probably call it too late, you need to do it at the CSR step, it is an integral part of that the CA has to sign. – Patrick Mevzek Sep 09 '19 at 20:47
  • 1
    @PatrickMevzek So, I removed `extfile` and using `openssl req -key helm.tiller.key.pem -new -sha256 -out helm.tiller.csr.pem -subj "/C=CA/ST=St/L=Ms/O=Fi/OU=Dp/CN=tiller-server" -addext "subjectAltName = IP:127.0.0.1"` But, still getting the same error. – RNK Sep 09 '19 at 21:23
  • Your command works on my side, the CSR has `Requested Extensions: X509v3 Subject Alternative Name: IP Address:127.0.0.1`. Make sure the final certificate has that data too, and make sure you restart your systems with the new certificate. – Patrick Mevzek Sep 09 '19 at 21:53
  • @PatrickMevzek From where did you get that info? According to this guide https://www.ibm.com/support/knowledgecenter/en/SSB23S_1.1.0.13/gtps7/cfgcert.html it's not like the way you mentioned. And I am getting an error: `139754355836672:error:22075075:X509 V3 routines:v2i_GENERAL_NAME_ex:unsupported option:crypto/x509v3/v3_alt.c:531:name=IP Address` – RNK Sep 10 '19 at 13:40
  • From where I got the info? I tried the command myself and looked at the results! – Patrick Mevzek Sep 10 '19 at 14:13
  • @PatrickMevzek I have a similar problem here: https://stackoverflow.com/questions/67558966/self-signed-ca-cannot-validate-certificate-for-192-168-178-66-because-it-doesn?noredirect=1&lq=1 In the end, my CSR file indeed contains the `Subject Alternative Name: IP Adress`-part. But my CRT-File doesn't! – Jere May 16 '21 at 21:17

0 Answers0