"Error: unable to get issuer certificate" when certificate-authority-data contains a self signed certificate

[ericwong3]

trafficstars

I am using Aliyun's serverless kubernetes service, and it provides an YAML to connect to the cluster and perform administration. The config file works with kubectl CLI. However, if I use it with this library, the "Error: unable to get issuer certificate" message appears. I was able to circumvent the issue by adding insecure-skip-tls-verify: true but clearly that is not good. This issue occurs on both Windows 10 and Ubuntu 16.04 as I have tested.

A redacted version of Aliyun's YAML:

apiVersion: v1
clusters:
- cluster:
    server: https://ca3651013ffffffffffffffffffffffff.serverless-1.kubernetes.cn-shanghai.aliyuncs.com:6443
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvekNDQW1pZ0F3SUJBZ0lEQmthcE1BMEdDU3FHU0liM0RRRUJDd1VBTUdJeEN6QUpCZ05WQkFZVEFrTk8KTVJFd0R3WURWUVFJREFoYWFHVkthV0Z1WnpFUk1BOEdBMVVFQnd3SVNHRnVaMXBvYjNVeEVEQU9CZ05WQkFvTQpCMEZzYVdKaFltRXhEREFLQmdOVkJBc01BMEZEVXpFTk1Bc0dBMVVFQXd3RWNtOXZkREFlRncweE9EQTBNalF4Ck5URTBNREJhRncwek9EQTBNVGt4TlRFNU5EUmFNR294S2pBb0JnTlZCQW9USVdNMU4yRXdPR1E0WkdFeU1UZzAKT1RNd1lUaGpZVGxpWWpVMk5EWmhNV1UyWWpFUU1BNEdBMVVFQ3hNSFpHVm1ZWFZzZERFcU1DZ0dBMVVFQXhNaApZelUzWVRBNFpEaGtZVEl4T0RRNU16QmhPR05oT1dKaU5UWTBObUV4WlRaaU1JR2ZNQTBHQ1NxR1NJYjNEUUVCCkFRVUFBNEdOQURDQmlRS0JnUUM5SE9oV1lRYXlDVEYyTG1EVXlJZ2RzWlFyUFljblRyVURmakwrcjU5MExUbkwKNkxZVFVyTlc4VE1NUzhsWHRDZjZRQlMxczRzNWJoajRYRFJLSEtYRC8rcjQwN1JobEFEY3puSUJVc0Nra0hnZgo0VDJZTkNrSUxBUFRaNG5aVGFYUk1VS3ZsOFBDTHl6aklWczJ6N21nZFJ6bnowY0pJbVo0bTVNQW5YeC80UUlECkFRQUJvNEc2TUlHM01BNEdBMVVkRHdFQi93UUVBd0lDckRBUEJnTlZIUk1CQWY4RUJUQURBUUgvTUI4R0ExVWQKSXdRWU1CYUFGSVZhLzkwanpTVnZXRUZ2bm0xRk9adFlmWFgvTUR3R0NDc0dBUVVGQndFQkJEQXdMakFzQmdncgpCZ0VGQlFjd0FZWWdhSFIwY0RvdkwyTmxjblJ6TG1GamN5NWhiR2w1ZFc0dVkyOXRMMjlqYzNBd05RWURWUjBmCkJDNHdMREFxb0NpZ0pvWWthSFIwY0RvdkwyTmxjblJ6TG1GamN5NWhiR2w1ZFc0dVkyOXRMM0p2YjNRdVkzSnMKTUEwR0NTcUdTSWIzRFFFQkN3VUFBNEdCQUI2RU03RFBDQVNTOXFDcGd3VU5CcGR2cFVDcjN2azF1SXl0Zmc5RQp0OGwvdWZJRkRjTzhTYno1ZHllSTlMTVZnNHdpc2dtV3FUakxHVGJuUVMyNHVoT1lFQ05vWXVFa1lQQjRSRkpFCjFFeTFRKy8ycWxzY0dWOFVJQlUzV1BYRFlHYU9IdlZpYnkrNzhXY2Z2U1g5Y01OR0tZMGxCSjUySFFIT1BKRE8Kc0tjMwotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: "aliyun5007422899999999"
  name: viking-ca3651013ffffffffffffffffffffffff
current-context: viking-ca3651013ffffffffffffffffffffffff
kind: Config
preferences: {}
users:
- name: "aliyun5007422899999999"
  user:
    client-certificate-data: LS0xxxxxxxx
    client-key-data: LS0xxxxxxxxxx

Where the certificate-authority-data contains the self-signed certificated generated by Aliyun.

[brendandburns]

Odd. In theory this should work. (and it does work for other providers)

I will try loading up this config in a dev. environment and see if I can reproduce the problem.

[brendandburns]

One other thing you might try is exporting the CA cert to a file, and then using:

...
certificate-authority: /path/to/file.cert
...

Rather than the inline version. If that works then it's especially weird.

[ericwong3]

Just tested, no this does not work, same error. (The property is recognized though, file not found error will appear if I set a wrong path)

[brendandburns]

Can you decode the CA certificate? My bet is that there are multiple intermediary certificates and we don't currently support that in this library...

[ericwong3]

I tried https://certificatechain.io/ which can be used to regenerate the certificate chain, and the result shows that the certificate is root in itself. (For your knowledge, the base64 certificate above is the original one from Aliyun)

[brendandburns]

Ok, I will try to test this out further in my environment...

[brendandburns]

I tried this on my machine and I get:

{ Error: CA certificate key too weak
    at TLSSocket.onConnectSecure (_tls_wrap.js:1058:34)
    at TLSSocket.emit (events.js:198:13)
    at TLSSocket._finishInit (_tls_wrap.js:636:8) code: 'CA certificate key too weak' }

I suspect that this is because nodejs wraps libssl while Go (afaik) has their own implementation.

I'm not sure this is fixable without a great deal of effort. I'm not sure I will take this any farther (for now) but I'll leave this issue open if people hit the same problem.

[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

[ericwong3]

/remove-lifecycle stale

[ameerthehacker]

Any update on this?

[brendandburns]

No updates. I'm really not sure this is fixable without a great deal of effort, I believe this error is coming from libssl, and I don't want to hack around libssl.

I think the key strength of the self-signed certificate needs to be increased.

/lifecycle frozen

[able8]

The root cause is that the cluster CA is an intermediate CA certificate which are not trusted by Nodejs https://github.com/nodejs/node/issues/36453