As part of renewing our cluster certificate we have accidentally deleted our "tls-rancher-ingress secret" from local cluster, after that we are unable to access cluster through kubectl and getting error like "Getting Unable to connect to the server: x509: certificate is valid for ingress.local, not rancher",please guide us if there is any way to add the secret again without using kubectl?
Related
Behind a corporate firewall with Symantec WSS agent.
I get this error
ERROR: (gcloud.compute.start-iap-tunnel) There was a problem refreshing your current auth tokens: HTTPSConnectionPool(host='oauth2.googleapis.com', port=443): Max retries exceeded with url: /token (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1129)')))
Please run:
I tried
gcloud config set auth/disable_ssl_validation True
I also pulled the certificate chain with
openssl s_client -showcerts oauth2.googleapis.com:443
and then
gcloud config set core/custom_ca_certs_file c:/temp/certs.pem
No matter what it won't get past the certificate check
I thought that disabling SSL validation would work, but it doesn't
I have installed istio with below command.
istioctl install --set profile=default -y
And I created istio-injection=enabled label to specific namespace.
But, Replicaset of that namespace occur below error.
Warning FailedCreate 12m (x20 over 53m) replicaset-controller Error creating: Internal error occurred: failed calling webhook "namespace.sidecar-injector.istio.io": Post "https://istiod.istio-system.svc:443/inject?timeout=10s": context deadline exceeded
So I used the below command in another container.
Command
curl https://istiod.istio-system.svc:443/inject
Out
Client sent an HTTP request to an HTTPS server.
root#general-component-b477fd4b8-qdfqn:/# curl https://istiod.istio-system.svc:443/inject
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
root#general-component-b477fd4b8-qdfqn:/# curl http://istiod.istio-system.svc:80/inject
curl: (7) Failed to connect to istiod.istio-system.svc port 80: Connection timed out
root#general-component-b477fd4b8-qdfqn:/# curl https://istiod.istio-system.svc:443/inject
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
There seems to be a problem with SSL, but I just did a basic install.
How can i solve this problem?
Deployed Chaos with helm on AKS. all pods up&running and all resources created.
I try then to create a crd NetworkChaos as in the official documentation but I get a x509 signed by unknown authority when trying to contact the Controller Manager svc. the certificate used is stored in the webhook-certs automatically generated by the helm.
Can anyone help me? Should I put a trusted certificate instead? should I trust the generated certificate by the cluster CA?
I also would be ok on skipping tls but I didn't find how to. Thanks
I have my own hosted Kubernetes cluster where I store my secrets in vault. To give my microservices access to the secrets managed by vault, I want to authenticate my microservices via their service accounts. The problem I'm facing is that vault rejects the service accounts (JWTs) with the following error:
apis/authentication.k8s.io/v1/tokenreviews: x509: certificate signed by unknown authority
The service accounts are signed with Kubernetes own CA. I did not replace this with Vault's pki solution. Is it possible to configure Vault to trust my Kubernetes CA certificate and therefore the JWTs?
This kind of error can be caused by a recent change to Service Account Issuer Discovery in Kubernetes 1.21.
In order to mitigate this issue, there are a couple of options that you can choose from based on your expectations:
Manually create a service account, secret and mount it in the pod as mentioned on this github post.
Disable issuer validation as mentioned on another github post.
Downgrade the cluster to version 1.20.
There are also a couple of external blog articles about this on banzaicloud.com and particule.io.
I just installed the kubernetes dashboard. I would like to access it in HTTPS and not in HTTP. Unfortunately when I enter the URL https://10.109.0.xx:6443
I have an error telling me that the connection is not secure.
And I would just like to avoid this kind of mistake.
Do you have any idea how I can fix this problem?
so when i want to run helm ls --tls i get the error certificate signed by unknown authority as you can see below
I have succeeded to signa URL https://xxx.cloud.net/ to go directly to the kubernetes dashboard .
# helm ls --tls
Error: Get https://10.109.0.xx:6443/api/v1/namespaces/kube-system/pods?labelSelector=app%3Dhelm%2Cname%3Dtiller: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")