No luck due to blacklist


#1

Please fill out the fields below so we can help you better.

My domain is: paulguijt.nl

I ran this command:

  1. sudo ./getssl paulguijt.nl
  2. sudo certbot --apache -t -d paulguijt.nl -d www.paulguijt.nl
  3. sudo certbot --apache -t -d paulguijt.nl -d www.paulguijt.nl -v

It produced this output:
1.
Certificate on remote domain does not match domain, ignoring remote certificate
Registering account
Verify each domain
Verifying paulguijt.nl
copying challenge token to /var/www/mijn/paulguijt/.well-known/acme-challenge/xX8r0olvU9lqS8_6CUPHcTPzrXykLbSy5Segx_wgHA8
Pending
getssl: paulguijt.nl:Verify error:Could not connect to paulguijt.nl

  1. Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
    Obtaining a new certificate
    Performing the following challenges:
    tls-sni-01 challenge for paulguijt.nl
    tls-sni-01 challenge for www.paulguijt.nl
    Waiting for verification…
    Cleaning up challenges
    Failed authorization procedure. paulguijt.nl (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to 82.161.149.101:443 for TLS-SNI-01 challenge, www.paul
    guijt.nl (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to 82.161.149.101:443 for TLS-SNI-01 challenge

see http://paulguijt.nl/.well-known/acme-challenge/letsencrypt.log

error.log reported:
[Fri Dec 16 11:50:40.298614 2016] [ssl:warn] [pid 2449] AH01906: 9fe57942a192d9cd5daf02b7c880c41d.ba1619d251d5103381c6cbe36b8eca81.acme.invalid:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Fri Dec 16 11:50:40.302545 2016] [ssl:warn] [pid 2449] AH01906: 9f474c6bfd6b656c9cee80c56246a147.141d1b3e50e4e4fa437dc62328d6815e.acme.invalid:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)

My operating system is (include version):
Raspbian / Debian 8

My web server is (include version):
Apache 2.4.10

My hosting provider, if applicable, is: at home, through ADSL with a fixed IP

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

DNS A is set ok, iptables should not block.

In apache2.conf:
<Directory “/var/lib/letsencrypt/”>
AllowOverride None
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
Require method GET POST OPTIONS

In ports.conf:
Listen 80 http
Listen 443 https

In ssl.conf:
SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:!aNULL:!MD5
SSLProtocol TLSv1 TLSv1.1 TLSv1.2


#2

It looks as if you have tried different systems here ( both getssl and certbot) with a couple of different errors / issues. So I’m not sure which one you want to resolve / work with.

In your first case, the error is with the Let’s Encrypt server trying to connect to your sever to verify ownership. Do you have a firewall or anything similar that could be blocking access ?

In your second case, it failed to connect to port 443 on your device. This could be a firewall issue again - or a configuration issue. I note that your https does not correctly go to your site, so the apache config looks to be slightly wrong.

In your log file, this is with certbot, and gives the error as with the second case

Detail: Failed to connect to 82.161.149.101:443 for TLS-SNI-01 challenge

To fix these errors, please make sure that your domain name was entered correctly and the DNS A record(s) for that domain contain(s) the right IP address. Additionally, please check that your computer has a publicly routable IP address and that no firewalls are preventing the server from communicating with the client. If you’re using the webroot plugin, you should also verify that you are serving files from the webroot path you provided.

So again, I’d check for a firewall issue, and that you can reach the requested files from a general location on the internet.


#3

Hi serverco,

Thanks for your swift reply. I’ve got IPTables running, with the follwing relevant rules:

:INPUT DROP [556:45783]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [3747:641434]
-A INPUT -m set --match-set blacklists src -j DROP
-A INPUT -m set --match-set MijnBlacklist src -j DROP
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

Maybe I have the Let’s Encrypt server’s IP blacklisted.

I have changed the DocumentRoot in the vritual host @ 0.0.0.0:443 so the https serves the acme challenge files.
I can see them through 4G on my smartphone.


#4

It may be worth temporarily clearing your blacklist and trying again.


#5

I have succeeded, after

  • commenting out my blacklist in my iptables rules
  • restoring the changed iptables rules

What IP adresses should I keep out of my blacklist?


#6

Good to hear that resolved it.

Let’s Encrypt don’t publish the IP addresses, and will potentially use random IP addresses ( possibly via TOR), so I can’t tell you which IP’s to whitelist, sorry. The check of ownership needs to be valid from anywhere on the internet.


#7

I fully understand that.

But it implies that Let’s Encrypt conflicts with (local) blacklisting. I don’t know if that’s the intention of the people behind Let"s Encrypt.

Nevertheless, thanks and glad it works.


#8

I’m not sure where your local blacklist rules came from.

You could check your logs in this case, to see the IP that the checks actually came from, and then see why those IP’s were listed in your blacklist.


#9

I have changed my iptables rules:

-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -m set --match-set MijnBlacklist src -j DROP

Perhaps that will allow me to combine Let’s Encrypt certification and blacklisting anyone too.


#10

Where have you created your list of IP’s in your blacklist from ? To me, that is more the question as to why you were blacklisting an IP used by Let’s Encrypt. If you know the IP and why you blacklisted it, you can then determine if it was blacklisted in error, or if there is some issue.


#11

Hi @PaulGuijt, I think in this case it’s more accurate to say that Let’s Encrypt’s implementation of HTTP-01 and TLS-SNI-01 ACME challenges conflicts with your fine-grained blacklisting. Like @serverco (thanks!) mentioned we deliberately do not publish our validation source IPs as we intend to use a diverse and unpredictable set in the future.

If you must use IP whitelisting/blacklisting then you should favour the DNS-01 challenge type instead of HTTP-01 or TLS-SNI-01. That is a better fit for this sort of environment and won’t require you knowing the IPs of the Let’s Encrypt validation authority.

Hope that helps!


#12

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