--http-port-01 option not working

Help
1

I am attempting to obtain a certificate for the domain berrysmooth.ca (just for experimentation purposes). My ISP blocks port 80, so the default acme challenge will fail unless I specify an alternate port as discussed here.

When I run:

certbot certonly --http-01-port 9999 --webroot --webroot-path=/var/www/berrysmooth.ca -d berrysmooth.ca -d www.berrysmooth.ca

I get:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for berrysmooth.ca
http-01 challenge for www.berrysmooth.ca
Using the webroot path /var/www/berrysmooth.ca for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. www.berrysmooth.ca (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://www.berrysmooth.ca/.well-known/acme-challenge/2tvmysVn9VL0vEW4wTRYbIHhvCYSeCfHu9dLn42U364: Timeout, berrysmooth.ca (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://berrysmooth.ca/.well-known/acme-challenge/SHmBaAhv-qPs0yk9R_6D6T7uNMNtpH3xEBCgc_V_pBY: Timeout

IMPORTANT NOTES:

  • The following errors were reported by the server:

Domain: www.berrysmooth.ca
Type: connection
Detail: Fetching
http://www.berrysmooth.ca/.well-known/acme-challenge/2tvmysVn9VL0vEW4wTRYbIHhvCYSeCfHu9dLn42U364:
Timeout

Domain: berrysmooth.ca
Type: connection
Detail: Fetching
http://berrysmooth.ca/.well-known/acme-challenge/SHmBaAhv-qPs0yk9R_6D6T7uNMNtpH3xEBCgc_V_pBY:
Timeout

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.

It appears that despite the http-01-port option, the option is having no effect on the outgoing ACME challenge.

I am running a simple nginx configuration on debian 8 jesse, which listens to all requests to port 80, but forwarded to port 80 via my router's port forwarding configuration. My domain is pointed to my public IP, and I have verified this (port 9999 loads the site). My nginx config looks as follows:

server {
        listen 80;
        listen [::]:80;

        root /var/www/berrysmooth.ca;
        index index.html index.php index.htm index.nginx-debian.html;

        server_name berrysmooth.ca www.berrysmooth.ca;
        location / {
                try_files $uri $uri/ =404;
        }
        location ~ \.php$ {
                include snippets/fastcgi-php.conf;
                fastcgi_pass unix:/run/php/php7.0-fpm.sock;
        }

        # deny access to .htaccess files, if Apache's document root concurs with nginx's one
        location ~ /\.ht {
                deny all;
        }
        location ~ /.well-known {
                allow all;
        }
}

I am hosting on proxmox 5 on my own server, and I have root access.

Can anyone advise a way to force the acme challenge to occur on port 9999, not the default port 80? Thanks in advance.

2

Hi @srsgores,

I think you might have misunderstood the nature and purpose of this option. It’s really meant for use when you have a complicated port forwarding setup so that port 80 on your machine does not correspond to the publicly-visible port 80.

The use of (the publicly-visible) port 80 to validate your control of the domain is mandated by the CA/Browser Forum and can’t be changed; you’re required to validate on that specific port when using this validation method. So, if your ISP blocks that port, you can’t use that validation method at all; there’s no way to request or convince the CA to validate on a different port with this method.

Could you use port 443 instead? Do you have an existing web server listening there? (If so, --nginx might work if you update to a newer version of Certbot, while if not, --standalone might work.)

If not, can you update DNS records in the DNS zone for your domain? That is the third means of validation that Let’s Encrypt offers.

3

Thank you for your prompt response.

After updating to a newer certbot with apt-get install python-certbot-nginx, then running:

certbot certonly --nginx -d berrysmooth.ca -d www.berrysmooth.ca

I get this error:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for berrysmooth.ca
tls-sni-01 challenge for www.berrysmooth.ca
Generating key (1024 bits): /var/lib/letsencrypt/snakeoil/0000_key.pem
/usr/lib/python2.7/dist-packages/OpenSSL/rand.py:58: UserWarning: implicit cast from 'char *' to a different pointer type: will be forbidden in the future (check that the types are as you expect; use an explicit ffi.cast() if they are correct)
result_code = _lib.RAND_bytes(result_buffer, num_bytes)
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. berrysmooth.ca (tls-sni-01): urn:acme:error:malformed :: The request message was malformed :: Server only speaks HTTP, not TLS, www.berrysmooth.ca (tls-sni-01): urn:acme:error:malformed :: The request message was malformed :: Server only speaks HTTP, not TLS

IMPORTANT NOTES:

  • The following errors were reported by the server:

Domain: berrysmooth.ca
Type: malformed
Detail: Server only speaks HTTP, not TLS

Domain: www.berrysmooth.ca
Type: malformed
Detail: Server only speaks HTTP, not TLS

To fix these errors, please make sure that you did not provide any
invalid information to the client, and try running Certbot again.

After reviewing the google results for this message, it appears that there is no solution to this. Can you advise otherwise?

4

Hi @srsgores,

Did you add a listen 443 directive to your existing nginx configuration without listen 443 ssl?

5

I got it to work by doing:

certbot certonly --nginx -d berrysmooth.ca -d www.berrysmooth.ca

And modifying my default configuration under sites-available to listen to port 443. However, there are some additional domains routed through cloudflare for which I’m trying to get SSL certificates, but those are not able to validate over TLS (getting “The server experienced a TLS error during domain verification :: remote error: tls: handshake failure”). Should I create a new thread for that?

6

I think this thread is OK, even though it’s a slightly different question.

For the domains that go over Cloudflare, does it answer on port 80? If so, you can probably get certificates with the --webroot method, specifying the top of your web content directory with -w.

Cloudflare provides a free cert from a different CA for the client-to-CDN part of the connection. If you do get a Let’s Encrypt cert for a domain name that’s behind Cloudflare, you can only use it for the CDN-to-origin part of the connection. Cloudflare also provides a separate option to get a non-publicly-trusted origin certificate, issued by them, which can be used for that part of the connection, which provides equivalent security.

7

Currently, none of my domains routed through cloudflare work through port 80, my ISP has blocked port 80, so I need an alternative. I have reviewed Cloudflare’s SSL, and it appears that though their CA is free to use, they would require one in my case, as my ISP has blocked port 80. Can you suggest a workflow to get certbot to obtain certificates, or will I have to change my domains’ A records to match my public IP again?

8

Well, the Let’s Encrypt CA supports three methods of proving your control over a domain name. One is receiving an HTTP connection on port 80, one is receiving a TLS connection on port 443 (which does not work with Cloudflare or CDNs or devices that directly terminate TLS), and the last one is making changes to your DNS records. Could you do that?

I didn’t understand exactly what the problem with using Cloudflare’s origin certificates in your situation is, although I’ve never used that service so I also don’t know exactly what Cloudflare’s requirements are for it.

9

Requirements for validation? There aren't really any. It's not a publicly trusted CA, and you've already demonstrated control of the domain; you just have to write a list of names, paste a CSR (or let them generate it) and click a button. (Or use their API.)

10

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