Doesn't work with (some) self signed certs
ahmetb opened this issue · comments
I work with a GKE cluster.
GKE self-sings CA certificates and configures them in kubeconfig file.
So kubectl (and many other kubectl plugins) work fine.
However when I just tried view-allocations v0.6.0, I got this error:
cli: CliOpts { namespace: None, show_zero: false, resource_name: [], group_by: [resource, pod] }
error: ReqwestError: error sending request for url (https://35.188.100.201/api/v1/nodes?): error trying to connect: The certificate was not trusted.
Caused by:
0: error sending request for url (https://35.188.100.201/api/v1/nodes?): error trying to connect: The certificate was not trusted.
1: error trying to connect: The certificate was not trusted.
2: The certificate was not trusted.
Funny enough, it works on another GKE cluster just fine.
I'm attaching the base64 encoded CA certs, the second one isn't working.
cat ~/.kube/config | grep cert
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURDekNDQWZPZ0F3SUJBZ0lRZGw1SnNWU3JRVFQ4ZVh0bFp5enoxakFOQmdrcWhraUc5dzBCQVFzRkFEQXYKTVMwd0t3WURWUVFERXlSaVptWTFaV0U0WlMxaU5XTTBMVFJoTkdVdE9UWTJNQzFsWkRJd056VTVZemszWXpjdwpIaGNOTVRrd05qRTVNVFl3TmpNMldoY05NalF3TmpFM01UY3dOak0yV2pBdk1TMHdLd1lEVlFRREV5UmlabVkxClpXRTRaUzFpTldNMExUUmhOR1V0T1RZMk1DMWxaREl3TnpVNVl6azNZemN3Z2dFaU1BMEdDU3FHU0liM0RRRUIKQVFVQUE0SUJEd0F3Z2dFS0FvSUJBUUNidlVIT25RR09CVWpFQWI0cDl0NzlVZUt1TGdnK0Npdld3VGp4dVhYegp6TEdjUFRtQ0xOT21Ma0hJMEFFN05LZS9hRXlPSXFDV2d3OUtObkxFMDMvQU5tbU1KSEpWT1ZsallmalczR3hYCnQva3c4WE9RWVJZcStNUkk4SGJXR01RRlg1U1MwYVNGeXdKanY0RXFsTHF1ekZ6alJaZXhiWU9LQjNLSUR1U0wKTWNZQzB6em45cWZVNStJZmdZZW5KRjVWU1dqa09obWpGTDdWZE9Zc3JmRGxaUmU1UDZuelU2YXh1UFBNREdrMQpTRTRFanBsWUhNNlRBNkNSa2lObG1MZ2ROU0ZGSFpWbEViOUJyUmlNbzZ3K1owbmEzK2ZzK2FUYXlwd2k4ZXpyCkNpOE9xbXYrWVlXUDBFVXppb0IxWUZ6UHZyTkd5SzVpOVdSa2xzTm95RU9WQWdNQkFBR2pJekFoTUE0R0ExVWQKRHdFQi93UUVBd0lDQkRBUEJnTlZIUk1CQWY4RUJUQURBUUgvTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFCaAprNE16UU1oWExFVVc5bGhadGYyUGtrckYxNVlnRjNmbGtWWnRja2VqdVdoVWpuMGJBYkwyYXhpMnJqQXpMUTY5CjBWREx5NnB3b01WWldkem9xQjdvclpHUHAxb0FRcjMwd1JMU0VjUHYzTHZ5UkR2V3FORU1TWDlZWmp1UzNzYU4KU3lDcEhKMFBEWnV4Z2diTTZTS3c0WFhzNFVDN01zSXlBU1RPVWZrT213eUZUOGw3cWNibml1c3ZJbnpoL1RlTwpqNnZOa29FOTkzTU9GNS92ejJPa2FXMDU0M2lXUjVHdDF5aldUZGtJYmtMYUJuNXdnRVBaMlNLaVdDem84ck90CmFBOFFUZi80cTFZdkZ1N2FqY2NJTE9XenFHcjQrcE9YS2YvV2RUUUV4eG15UFlUZnNTNXJhR3pMUnh2YXFNUmMKZGx3VTR5Q2lTUVMxckd5M2dwK3gKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURDekNDQWZPZ0F3SUJBZ0lRVVpFRW92bTZ2cldmMkY5T0d5M1FSVEFOQmdrcWhraUc5dzBCQVFzRkFEQXYKTVMwd0t3WURWUVFERXlSak5EUXdNemswTkMwM05UVTRMVFF6WmpJdE9USmlNQzFpT0dabFpEQXhZV1ppTjJFdwpIaGNOTVRreE1qRTVNREl4TURRNFdoY05NalF4TWpFM01ETXhNRFE0V2pBdk1TMHdLd1lEVlFRREV5UmpORFF3Ck16azBOQzAzTlRVNExUUXpaakl0T1RKaU1DMWlPR1psWkRBeFlXWmlOMkV3Z2dFaU1BMEdDU3FHU0liM0RRRUIKQVFVQUE0SUJEd0F3Z2dFS0FvSUJBUUMrWHpmU29nQTViUnFrZjFNakJSRWhQVkorVVNyK242aHFycTFxNXNOTQp5c1YwRk8xdVZxZXJWREZveTFWN1NSMmFmVVIzZjJlVlpTV1ByaitLY2E4TktvTXp2bWtFaTJBb043TVMxUTVKCnIxMnZLUnNXeUVIaWowR1h2SDFIR0J2a1pIZlVFTVdLY3RhbTVjais0aEEweGlLaVhPSWw2eGw2RE53Mm5oV1IKZnYrU1JNM2ZoSFIxUFFDV3RKbTBIZjVpUmFvUHFBMlVIMkIwWXJJK3BtMXl4ajFHejgvU0hWdVh1Qnd1Ylp1bwowbDl2U3AyS0JaNks4VHlWeDB2NGpXN1RNVWVmQ2pyZGIwWVRkUVN1SitGcjgvUzFxSVM5TGpaSnoybUFwTm95CnFtOHZLTStabDVGTU9OODBSQXk0TUlJK3ZxdGhBSUgvcFhvVHhzVkhKMzU5QWdNQkFBR2pJekFoTUE0R0ExVWQKRHdFQi93UUVBd0lDQkRBUEJnTlZIUk1CQWY4RUJUQURBUUgvTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFBLwpIcVpZL0hhVDBCNzJ2QW1JSEdWdWhwV2JJTUlvTm9SY09HVUQvc0FqVklSODNhWjF0aTVCOVIxeUxoWlJheFFjCm5ZQUFjRzdCeEtxZ1plTllJVDhIbVR4bzlkLytaZEJKR2xybWtqSG51bTEzWUcreTczODBoNGJJR29DeHNJb0cKbUV0akxvb09QY1AxeHlHQVFLc3lyM3dtMllyd0g4WnNsaHQwRWRoMGpSRExmUEwvV0Z4UHIyL2EraWd6SWFCUgpFMnZIWCt6bzRkUXRNZTVhOThNZEZBWE9KdHRRK2FmVmRsU3lIVmlNOG1wMGo0RVUxTGx2czFueUhISVRjWFY5Ck83bVl5ZmlQKzE1OFdqNWJodXVyMUdCREVJZDVlZW5EbHBpTnVWRm02SlRlTDBMaktZdDFDdndZQ25XbHRZVVAKVGRFWjY4Q1lzWjQ5citkSTcyMVUKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
When I do base64 -d | openssl x509 -in /dev/stdin -noout -text I don't see any notable differences between the two certificates.
Maybe related to #11 or an issue with timezone
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=c4403944-7558-43f2-92b0-b8fed01afb7a
Validity
Not Before: Dec 19 02:10:48 2019 GMT
Anyway, I'll take a look.
Thanks for reporting
It’s not really. I checked that while posting.
Kubectl works, so cert is actually valid.
Are you on mac OSX Catalina ?
Yes.
FYI I provide the result of my investigation in the ticket of kube-rs linked above, and will discuss the workaround on it.
TLDR;
I guess the cause is :
-
the plugin use rust lib that delegate part of the certifacte checking to mac OSX
-
curl & golang doesn't delegate to OS
-
On mac OS X Catalina, some additional rules are applied Requirements for trusted certificates in iOS 13 and macOS 10.15 - Apple Support. At least one of the rules failed
Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines:
...- TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).
So for recent GKE cluster it failed because GKE generate too long certifact for API server: 5 years (see the screenshot) > 825 days . It's why the first is OK and the second failed.
As you know GKE, maybe you know how to configure it to generate shorter SSL certificate for the API server ?
If yes, can you share the info with us.
That’s not possible with GKE.
In this case, kube-rs should not delegate to macOS and it should use the CA in certificate-authority-data.
it's kube-rs, from my understanding it's the behavior of tls implementation(S) in rust used by the http client, used by kube-rs.
:-(
I'll discuss with kube-rs'team for solution.
Thank you. I suspect this is rather important bc many other local Kubernetes solutions use similar custom CA signed certs. The macOS catalina limitation sounds rather arbitrary.
In my case, older cluster is still working and newer cluster isn’t. I think both have similar validity durations. Feel free to double check above. So I suspect it’s not a Catalina thing.
The validity duration check is only applied on certificate issued after July 1, 2019 (see the quote or the link). It's why your first is ok (issued in June iirc) and not the second.
from: "Certificate not standards compliant" on macOS Catalina, iOS 13 · Issue #174 · FiloSottile/mkcert
825 comes from the CAB forum bylaws for certificates. All of the major products and CA's follow them.
I found other project reported this issue on Catalina (some website, application, tool about cert) , often they solved it by changing the duration of the certificate on the site.
Anyways, as it's a major issue for this kubectl plugin, I'll work on a workaround (including maybe a fork or a replacement of kube-rs by direct http call).
Yeah I think that explains why it happens only on one cluster. kube-rs or Rust ecosystem should address the need for a feature to programmatically configure validity requirements for a certificate.
Can you try the version 0.6.1 (also available via krew) ?
v0.6.1 solves this, thank you.