Does letsencrypt require a UFW rule? Ubuntu 16.04LTS


#1

I port forwarded 80 and 443 to the IP of my server behind my router. To my knowledge my internet provider does not block 80 or 443, in fact I switched from my old provider because they did block 80 and 443. However I’m still getting this failed challenge error. I have a feeling it might be due the Ubuntu level firewall which is UFW at the moment but I’m not sure what rule exactly I would need to add in there. Any tips?

My domain is: xxxxxx.dynu.com

I ran this command: sudo letsencrypt --apache

It produced this output:
Domain: my dynamic domain name
Type: connection
Detail: Failed to connect to xx.xx.xx.xx:443 for TLS-SNI-01
challenge

My operating system is (include version): Ubuntu Server 16.04

My web server is (include version):
Server version: Apache/2.4.18 (Ubuntu)
Server built: 2016-07-14T12:32:26

My hosting provider, if applicable, is: Home internet connection

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no


#2

Is ufw enabled? Check what this says:

sudo ufw status verbose

If it is active and incoming connections are blocked, enable appropriate port as follows:

sudo ufw allow XXX/tcp

where XXX is 443 for HTTPS or 80 for HTTP.


#3

Hello there!

This is the output of sudo ufw status

To                         Action      From
--                         ------      ----
22                         ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
64738                      ALLOW IN    Anywhere
137,138/udp (Samba)        ALLOW IN    Anywhere
139,445/tcp (Samba)        ALLOW IN    Anywhere
2999:3001/tcp              ALLOW IN    Anywhere
22 (v6)                    ALLOW IN    Anywhere (v6)
80/tcp (v6)                ALLOW IN    Anywhere (v6)
64738 (v6)                 ALLOW IN    Anywhere (v6)
137,138/udp (Samba (v6))   ALLOW IN    Anywhere (v6)
139,445/tcp (Samba (v6))   ALLOW IN    Anywhere (v6)
2999:3001/tcp (v6)         ALLOW IN    Anywhere (v6)

Do I need to have 443 in there too?


#4

Yes, indeed :slight_smile:

P.S. That is if you are using TLS-SNI verification. For HTTP verification you would only need port 80 open and for DNS verification you would not need open ports at all (but you would have to be able to add TXT record in your DNS).


#5

So letsencrypt requires 443 and 80 to both be open for install to work properly?

I did figure that 443 would have to be open to actually hit the webserver on https.


#6

See the edit above - 443 is needed for this particular type of verification you have used (TLS-SNI) :wink:

You can try HTTP or DNS verifications instead if you like (DNS is supported by some alternative clients - Perl, Go and Bash ones as far as I know).


#7

Since yesterday, Certbot 0.9.0 release supports DNS challenge too :wink:


#8

Bah, I must have missed that. :tada::wine_glass: :+1:


#9

Hrm, I’m still getting the same error message. Do I need to enable SSL and such in my .conf file? Maybe I am mistaken in believing that letsencrypt would do that for me?


#10

Nope, that’s correct. The apache plugin should enable SSL in your configuration.

I would recommend verifying basic connectivity to port 443 anyway, you can listen on port 443 with something like nc -k -l localhost 443 and then try to telnet to your WAN IP from a VPS or some other external host.

To rule out issues with the apache plugin, you could try using letsencrypt certonly --standalone -d example.com, which would spawn a temporary web server on port 443. If that succeeds, it’s likely an issue with your apache configuration or a bug in the apache plugin. If it doesn’t work, a network issue is more likely.


#11

Could it be because I’m using a dynamic domain from dynu.net?


#12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.