Problem with setting up Let’s Encrypt in AWS EC2 instance


(Abhinav Singh) #1

Hi,

I’ve configured discourse on AWS using this guide. Now I’m setting up HTTPS using Let’s Encrypt. When I specify Let’s Encrypt email id in ./discourse-setup, it displays below error

discuss.my_domain_name.com does not resolve to 172.31.x.xx
IT IS ALMOST CERTAINLY A BAD IDEA TO TURN ON LET’S ENCRYPT!!
Unless you know why this check failed, DO NOT USE Let’s Encrypt.

For some reason it is taking the private IP (172.31.x.xx) of the Ec2 instance instead of the public IP of that Ec2 instance. How should I fix it?


(Kai Liu) #2

Maybe you have your_domain_name.com pointed to the private IP in /etc/hosts?


(Abhinav Singh) #3

My /etc/hosts is having below lines

127.0.0.1 localhost

The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts


(Jay Pfaffman) #4

Yes. If you know that your public address is different from the one that ifconfig reports, you’re good to go. That’s why it says:

You know why it failed, right? You know that your domain resolves to the public-facing IP, so that warning doesn’t apply to you.

We really don’t want people to try to turn on Let’s Encrypt if it’ll fail. If you have an idea for what that message might say instead, please suggest it.


(Matt Palmer) #5

It might be worth using icanhazip.com (or another similar service) to get the “visible” IP of the instance, if the regular (ip ad sh) check doesn’t show goodness. That can still fail (because of ELBs, or multiple IPs, or a whole host of other shenanigans) but it’ll catch some more corner cases.


(Jeff Atwood) #6

Google does what is my ip as well, try it. Search for what is my ip.


(Matt Palmer) #7

I doubt there’s many people with a running web browser on their production servers. The nice thing about hitting http://icanhazip.com with wget or curl is that it gives you a plaintext response:

$ wget -O - -q http://icanhazip.com
192.0.2.42

(Kane York) #8

https://ipinfo.io gives you the AS number as well:

$ curl ipinfo.io
{
  "ip": "64.62.224.***",
  "hostname": "No Hostname",
  "city": "Fremont",
  "region": "California",
  "country": "US",
  "loc": "37.5***,-122.0***",
  "org": "AS8309 SIPARTECH SAS",
  "postal": "94555"
}

(Matt Palmer) #9

I doubt that “does the name point to my IP?” needs to know the AS.


(Jeff Atwood) #10

Why would you need to run a web browser? Just curl the Google querystring.


(Rafael dos Santos Silva) #11

The response from Google, if allowed, is a messy HTML document, while icanhazip gives a plain text and clean IP.

There are even some Linux distros using icanhazip for the same reason.


(Jeff Atwood) #12

Are we confident icanhazip will be around in a decade? I just don’t know the provenance of that site, and I had never heard of it before yesterday.


(Rafael dos Santos Silva) #13

I tried some similar services this week when I was setting up my dual wan setup, and most of those have super limited rate, or cache. icanhazip appears to be the better of those.

We can always ask the man himself too :smile: : Major Hayden (@majorhayden) | Twitter


(Jay Pfaffman) #14

Well, if I use a digital ocean elastic IP that points to my actual droplet, incoming traffic goes to the elastic IP, but outgoing traffic comes from the real IP (at least the way I did it). So for that case, icanhasip.com doesn’t help.

I’m on the side of “discourse-setup is for novices who are doing things a very specific way”. If someone’s done something more complicated, then they should know WTF they’re doing. If the IP that their host has is not the one that accesses the host, then they should know that and know to ignore the warning. If the warning needs to be tweaked to make that more clear, that’s fine, but I don’t think we can really fix this.


(Jeff Atwood) #15

I would add “if you are an expert and you definitely know what you are doing, feel free to ignore this warning” to the text, then.


(Jay Pfaffman) #16

Saying that they’re an “expert” rather than “unless you know why…” would make this clearer?


(Jeff Atwood) #17

Yes, if they self identify as an expert, I believe that advice is crystal clear.


(Abhinav Singh) #18

I have figured it out after looking at check_IP_match() in discourse-setup. My EC2 instance is part of VPC and inet addr was pointing to internal IP.

I’ve ignored the warning and it is all good now.


(Jay Pfaffman) #19

SO you are an expert. :slight_smile:

Anyway, I’ll see about tweaking the language so that you don’t have to read the code.


(Dean Taylor) #20

Obtaining the IP address both public and private of an EC2 instance is available from their AWS API from that instance:

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html

To determine your instance’s IPv4 addresses using instance metadata

  1. Connect to your instance.
  2. Use the following command to access the private IP address:
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/local-ipv4
  1. Use the following command to access the public IP address
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-ipv4

Note that if an Elastic IP address is associated with the instance, the value returned is that of the Elastic IP address.

There is a similar API for IPv6