i am having a issue where cert manager does not create the ingress resource for lets encrypt servers acess the web server to complete the challenge, what can i do? i am using a EKS cluster
Hi, I have the godaddy ssl certificates files ( certificate.crt, bundle.crt, .pem file) and the private.key file. I used the certificate.crt and the private.key in the kubectl create secret command and created a secret and later used in my istio ingress gateway but while testing I got an error: ssl-error: unable to verify the first certificate. 2nd way: cat certificate.crt bundle.crt > chained_certificate.crt And use the above output file along with the private key in thr kubectl create secret command and again an unfortunate error: client network socket disconnected before secure tls connection was established I have installed istio on my Digitalocean kubernetes cluster. Would appreciate if you could guide me on this. Thank you!
I am trying to follow the Cert-manager part, and all is well till challenge creation. I have the challenge stuck at pending state and acme pod is never created to solve the challenge. Also cert-manager pod logs gives this: Failed to watch *v1beta1.Ingress: failed to list *v1beta1.Ingress: the server could not find the requested resource The tutorial have no ingress service created, is this the problem?
Found the problem. cert manager version 1.3.1 wasn't compatible with kubernetes v1.24.9 that I used, so updating cert manager to v1.11.0 got the problem solved
Thanks for this step by step guide. which http-01 challenge, the certificate authority need to verify the presence of the file using the DNS provided. In other words, our DNS Name need to resolve to our Ingress Gateway ( External IP ). Is that correct ?
Hi Juilo! It will be a bit difficult to test this out locally, especially if you're using a real domain name. However, you can always create a self-signed certificate and try it out like that (check the tutorial here: github.com/tetratelabs/istio-weekly/blob/main/istio-weekly/003/demo.md#using-self-signed-certificate)
@@learncloudnative Oh but that is not using cert manager, I am asking cause cert manager has staging endpoint and also have the ability to create self signed certs. I have tried though I am getting a ERR_CERT_AUTHORITY_INVALID, can't understand how to overcome this issue... thanks for your quick response.
@@learncloudnative hi ! thanks à lot for this vidéo. I am trying to apply what you did but in a backend app listenning in port 443 it is mandatory that the backend app listen on port 80 (or in http protocol and not https)? My issue is that i get and error : reset protocol
@@rafhue The actual backend can be on any port and (theoretically) any protocol. It depends where you do the SSL termination - in this video we're doing it at the ingress level; but you can also terminal the certs at the backend level and then configure your ingress gateway to passthrough the connection ( e.g. tls: mode: PASSTHROUGH)
Very informative. Thanks
Big tks!! wonderful!! this video very veru useful
Thanks :)
i am having a issue where cert manager does not create the ingress resource for lets encrypt servers acess the web server to complete the challenge, what can i do? i am using a EKS cluster
Hi,
I have the godaddy ssl certificates files ( certificate.crt, bundle.crt, .pem file) and the private.key file. I used the certificate.crt and the private.key in the kubectl create secret command and created a secret and later used in my istio ingress gateway but while testing I got an error: ssl-error: unable to verify the first certificate.
2nd way: cat certificate.crt bundle.crt > chained_certificate.crt
And use the above output file along with the private key in thr kubectl create secret command and again an unfortunate error: client network socket disconnected before secure tls connection was established
I have installed istio on my Digitalocean kubernetes cluster.
Would appreciate if you could guide me on this. Thank you!
I am trying to follow the Cert-manager part, and all is well till challenge creation. I have the challenge stuck at pending state and acme pod is never created to solve the challenge. Also cert-manager pod logs gives this:
Failed to watch *v1beta1.Ingress: failed to list *v1beta1.Ingress: the server could not find the requested resource
The tutorial have no ingress service created, is this the problem?
Found the problem. cert manager version 1.3.1 wasn't compatible with kubernetes v1.24.9 that I used, so updating cert manager to v1.11.0 got the problem solved
Thanks for this step by step guide. which http-01 challenge, the certificate authority need to verify the presence of the file using the DNS provided. In other words, our DNS Name need to resolve to our Ingress Gateway ( External IP ). Is that correct ?
Exactly. You need to create an A record in the DNS settings to point to the ingress gateways' external IP.
how to test this locally?
Hi Juilo! It will be a bit difficult to test this out locally, especially if you're using a real domain name. However, you can always create a self-signed certificate and try it out like that (check the tutorial here: github.com/tetratelabs/istio-weekly/blob/main/istio-weekly/003/demo.md#using-self-signed-certificate)
@@learncloudnative Oh but that is not using cert manager, I am asking cause cert manager has staging endpoint and also have the ability to create self signed certs. I have tried though I am getting a ERR_CERT_AUTHORITY_INVALID, can't understand how to overcome this issue... thanks for your quick response.
@@learncloudnative hi ! thanks à lot for this vidéo. I am trying to apply what you did but in a backend app listenning in port 443 it is mandatory that the backend app listen on port 80 (or in http protocol and not https)? My issue is that i get and error : reset protocol
@@rafhue The actual backend can be on any port and (theoretically) any protocol. It depends where you do the SSL termination - in this video we're doing it at the ingress level; but you can also terminal the certs at the backend level and then configure your ingress gateway to passthrough the connection ( e.g. tls:
mode: PASSTHROUGH)
@@learncloudnative thanks for your answer and your time!