Let's Encrypt: Azure hostname issue


(Sathya Narayanan Subramanian) #1

I’ve installed Discourse via Docker on a Ubuntu as mentioned in Set up Discourse in the cloud in under 30 minutes. The site works from localhost (ssh & port forward via putty). I’m trying to see if SSL is the reason I’m unable to access the site outside localhost via Virtual Machine’s Public IP Address or domain name (via ‘A’ records). So, here is what I’m trying to do to enable Let’s Encrypt.

cybersathya@Vaaithaaforum:/var/discourse$ sudo ./discourse-setup
Ports 80 and 443 are free for use
The configuration file containers/app.yml already exists!

. . . reconfiguring . . .

Saving old file as app.yml.2017-10-13-002911.bak

Found 3GB of memory and 1 physical CPU cores
setting db_shared_buffers = 768MB
setting UNICORN_WORKERS = 2

Hostname for your Discourse? [forum.vaaithaa.com]: forum.vaaithaa.com
Email address for admin account(s)? [sathya@vaaithaa.com]: sathya@vaaithaa.com
SMTP server address? [smtp.sendgrid.net]: smtp.sendgrid.net
SMTP port? [587]: 587
SMTP user name? [apikey]: apikey
SMTP password? [stmp password as given by sendgrid]
Let’s Encrypt account email? (ENTER to skip) [me@example.com]: sathya@vaaithaa.com

Checking your domain name . . .


WARNING:: forum.vaaithaa.com does not appear to resolve to 10.0.0.4.

LET’S ENCRYPT cannot work if their servers cannot access your host by name.
Unless you think you know why this naive check failed, DO NOT USE Let’s Encrypt.
(A typical reason for failure is an AWS server with an elastic IP.)

You should probably answer “n” at the next prompt and disable Let’s Encrypt.


Does this look right?

Hostname : forum.vaaithaa.com
Email : sathya@vaaithaa.com
SMTP address : smtp.sendgrid.net
SMTP port : 587
SMTP username : apikey
SMTP password : [stmp password as given by sendgrid]
Let’s Encrypt : sathya@vaaithaa.com

ENTER to continue, ‘n’ to try again, Ctrl+C to exit: n

IP Address (with context screenshot):


Go to the quoted post button URL link is incorrect
(Sathya Narayanan Subramanian) #2

the command ip addr show gives the following:

cybersathya@Vaaithaaforum:/var/discourse$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group defaul                                                                             t qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group defa                                                                             ult qlen 1000
    link/ether 00:0d:3a:f2:33:be brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.4/24 brd 10.0.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::20d:3aff:fef2:33be/64 scope link
       valid_lft forever preferred_lft forever
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP gr                                                                             oup default
    link/ether 02:42:e2:3c:5b:29 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:e2ff:fe3c:5b29/64 scope link
       valid_lft forever preferred_lft forever
59: vetha06db8f@if58: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue m                                                                             aster docker0 state UP group default
    link/ether 5a:da:8a:f7:b4:37 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::58da:8aff:fef7:b437/64 scope link
       valid_lft forever preferred_lft forever

(Stephen Chung) #3

Does the site work WITHOUT SSL?

I have Discourse on an Azure Ubuntu VM and it worked like a charm with no hassles.

First set it up WITHOUT Lets Encrypt. Make sure that you can access the site over straight HTTP.

Then modify app.yaml to include Lets Encrypt and rebuild.

From your error messages, it looks like you have not opened the EndPoint to the public IP address. That’s why Lets Encrypt is not finding the public IP.


(Jay Pfaffman) #4

Are you saying that http://your host.com doesn’t work for your hostname?


(Sathya Narayanan Subramanian) #5

I’m saying that the discourse site works ONLY from local host (127.0.0.1:8000), when tunneling is done with PuTTy, and not from the Virtual Machine’s IP Address. Infact, I’m not able to figure-out how to run Discourse outside local host.


(Sathya Narayanan Subramanian) #6

Mind letting me know how to do that? Thanks in advance. That’s where i’m stuck.


(Stephen Chung) #7

Scratch your VM, start a new one, do it vanilla without other configurations.

You can add your configuration changes later on and rebuild.

And, do yourself a favor, use the fastest CPU VM you can afford during setup. It should only be a few days, but it saves you heaps of time waiting for a rebuild (which can take up to 15 min).

And do not go below 2GB of RAM, thus do not use things like A0.


(Sathya Narayanan Subramanian) #8

I was able to find inbound port rules in Azure Settings, and I enabled TCP/443 and TCP/80.
Thanks a lot.


(Sathya Narayanan Subramanian) #9

I’m able to reach the site via domain name now, after port forwarding 443 & 80.
How do we go with SSL now?
rerunning discourse-setup is getting this error.

Checking your domain name . . .
WARNING:: forum.vaaithaa.com does not appear to resolve to 10.0.0.4.

LET’S ENCRYPT cannot work if their servers cannot access your host by name.
Unless you think you know why this naive check failed, DO NOT USE Let’s Encrypt.
(A typical reason for failure is an AWS server with an elastic IP.)

You should probably answer “n” at the next prompt and disable Let’s Encrypt.


(Stephen Chung) #10

How do you have an ANAME when you’re using a dynamic public IP? You should be using a static public IP for that, right?


(Jay Pfaffman) #11

You’ve demonstrated that you know that the address used to access your host is not 10.0.0.4, so it would seem that you know why this naive check failed.

Still, this remains confusing to people and the set of people who are confused by this naive check is growing, especially with people increasingly using Azure.

I’ll try to either make the check more robust or tone down the language to make it less scary sometime soon.


(Sathya Narayanan Subramanian) #12

I sincerely look forward for a tone-down. Thanks for sharing your knowledge via this community.


(Jeff Atwood) #13

@pfaffman you can just add Azure to this text if Azure does things this way too? Very simple fix.


(Jay Pfaffman) #14

I’ve used nc and curl to check whether http://hostname and http://hostname:443 actually connect to that host. I think they’ll give fewer false fails on the check and the “it’s broken” language is toned down a bit.

Done!


(Stephen Chung) #15

Yup, Azure has an option to use dynamic public IP’s which change periodically.

My public IP is static (meaning fixed IP), which doesn’t seem to trigger this warning.

But does Let’s Encrypt support dynamic IP’s? If it does, then it should be fine.