I have a K8 AWS cluster on which I have many namespaces deployed. I want to configure Istio for my applications. I am using Cert-manager to manage the letsencrypt certificates.
However, when I try to create issure+certificates using the Letsencrypt ACME URL - https://acme-staging-v02.api.letsencrypt.org/directory I get i/o timeout.
I think this is due to unreachability of the ACME challenge URL from my cluster. When I try curl/ping to the above URL. It is not reachable.
I have read on internet that Letsencrypt is not reachable from aws because it blocks requests from EC2 machines. Is it still true?
Can anyone help me in deploying certificates using certmanager+letsencrypt on aws clusters?
This has never been true.
Saw it here, old though.
That's a completely different statement. Let's Encrypt won't issue certs for *.amazonaws.com
. That doesn't mean (as you claimed) that they block requests from EC2 machines.
That prevents you creating certificates that include that domain as a SAN.
This is unrelated to the issue you are experiencing, which probably has to do with your VPC/NAT gateway configuration.
Check that your server can make outbound connections to the internet at all, then do a traceroute to the Let’s Encrypt server.
Try:
traceroute -T -p 443 acme-v02.api.letsencrypt.org
I can access all the servers on internet but not Letsencrypt. I think the Letsencrypt is having problem.
Very low probability for that.
Try showing your route tables.
and the output of:
Could be as simple as an incorrect route for the 172.16.0.0/12
subnet. (E.g., if instead of a /12
a /8
is mistakenly configured.)
traceroute to acme-v02.api.letsencrypt.org (172.65.32.248), 30 hops max, 46 byte packets
1 172-18-2-0.prometheus-prometheus-node-exporter.prometheus.xxx.xxxxx.local (172.18.2.0) 0.006 ms 0.005 ms 0.004 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
So you're using the 172.16.0.0/12
as the internal network. Which for me makes a routing issue very likely.
Please make sure the routing for your internal network is 172.16.0.0/12 and not e.g. /8
.
I have never heard this IP range making network connection issues.
If your hosts have 172.16.0.0/8
set up as the local network instead of the proper 172.16.0.0/12
range, they will not be able to reach IP addresses on the internet which are part of the /8
subnet, but are outside of the 172.16.0.0/12
range. The IP address from Cloudflare (172.65.32.248
) is such an IP address: it's NOT one of the private IP ranges of the 172.16.0.0/12
subnet, but it does fall within 172.16.0.0/8
. So if you have 172.16.0.0/8
set up, your host is trying to reach Cloudflare on your local network, which of course isn't going to work.
If you search this Community for 172.16.0.0
you should be able to find a few threads with the above issue.
Edit: I should say 172.0.0.0/8
by the way as that's the proper CIDR notation.
And you have also NOT found the problem.
Please provide the information requested:
[not sure if that's what you provided]
Something like:
netstat -nr
Beyond the route table on the server, it may also be useful to look at the route tables for the AWS network.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.