Help test Certbot Apache and Nginx fixes for TLS-SNI-01 outage

The Certbot team (especially @bmw @erica and @joohoi) have been doing amazing work modifying both the Apache and Nginx plugins to add support for HTTP-01 challenge types. That should fully resolve the ongoing TLS-SNI-01 problems for most Certbot users of these plugins. Our plan is to release those updates next week. In the mean time, we would love your help testing this new code. It’s in git master, so you can test it by running the development version of Certbot:

git clone https://github.com/certbot/certbot
cd certbot
sudo ./certbot-auto --os-packages-only
export VENV_ARGS="--python $(command -v python2 || command -v python2.7)"
tools/_venv_common.sh -e acme -e . -e certbot-apache -e certbot-nginx

After running those commands, the version of the certbot command you cloned from git is available at venv/bin/certbot. Please let us know if the commands sudo venv/bin/certbot --nginx --preferred-challenges http and/or sudo venv/bin/certbot --apache --preferred-challenges http are working for you as expected.

Known issues with these changes as of 2018-01-11:

  • the Apache plugin may not succeed in using HTTP-01 Challenges on virtual hosts that redirect to a different webserver
  • the Apache plugin may not succeed in using HTTP-01 Challenges on webservers that proxy-pass the /.well-known/acme-challenges/ directory
  • the Nginx plugin may not succeed in using HTTP-01 if your nginx webserver does not have a server block on port 80 containing a server_name directive matching the domain you requested a cert for
  • the Nginx plugin may be unreliable when using HTTP-01 if you have an IPv6 (AAAA) DNS record, but your server is only listening over IPv4.

At present, the Apache and Nginx plugins will only use HTTP-01 against the production Let’s Encrypt server. But when the LE servers re-enable TLS-SNI-01 for renewal only, the plugins will prefer TLS-SNI-01 in cases where the server allows it.

11 Likes

I tried to test it on an armv7
(uname -a follows:
Linux scw-33d855 4.4.87-mainline-rev1 #1 SMP Thu Sep 7 09:37:07 UTC 2017 armv7l armv7l armv7l GNU/Linux)

but it seems to freeze with these last lines:

/home/ca/certbot/venv/local/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:122: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/security.html#insecureplatformwarning.

and after 10 minutes nothing seems to happen anymore (can’t say if is some download behind, retrying something, or it froze for real).

While I get the warning (installed python is 2.7, not 3), I’m not sure what happens.
Hope this helps.

Hello

I try it but I have a problem.I don’t know if it’s a bug or not :frowning:

For a domain that I use, my virtualhost reply with www.mondomain.fr and mondomain.fr

In DNS zone, I have this kind of reccords.

@ 10800 IN A 1.2.3.4
www 10800 IN A 1.2.3.4

When I use this command :
/opt/certbot/venv/bin/certbot --apache -d www.mondomain.fr -d mondomain.fr

Follow this error

Failed authorization procedure. mondomain.fr (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://mondomain.fr/.well-known/acme-challenge/IeC6fWfQ8RZhL8Kgg93TI6j1goLYaaXiShP5eloMdJU: "

404 Not Found

Not Found

<p"

IMPORTANT NOTES:

So, the @ is a A record.
What’s wrong ?

With old certbot no problems.

If you have a solution, it will be welcome

Add :
No problem for www record
The certificate and apache configuration is well done when i request a certificate only for www.mondomain.fr

Best regards
Laurent

A post was split to a new topic: Traefik: what to do without tls-sni-01 support

@pde I tested on my ubuntu 16.04 + nginx with no luck.

Failed authorization procedure. my.domain.name (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://my.domain.name/.well-known/acme-challenge/pT7zfeUBdqiDvNY5dlaLtIYYMenmK_5c0CIK6rjjwiw: "<met

It looks like that nginx with reverse proxy has the same issue as the Apache plugin.

I’ve checked out master and successfully used the Nginx authenticator with a config that had a redirect and a proxy_pass (though both are innocuous enough to probably not cause problems):

    location /ct-test/ {
        proxy_pass http://localhost:4500/;
    }

    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    }

I haven’t tried it with a proxy_pass that covers /.

2 Likes

Success with Nginx config with proxy_pass / as well as non-proxy_pass using certbot --nginx

location / {
        proxy_pass http://localhost:10050/;
}
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/hello.world/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/hello.world/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
        listen 80;

        server_name hello.world;
    return 301 https://$host$request_uri; # managed by Certbot

}
2 Likes

Worked okay on Apache on Ubuntu 16.04 LTS, I had to disable a few rewrite rules though, it didn’t like that I had:

RewriteCond %{REQUEST_URI} !=/index.html                                                                                                                                                                                                               
RewriteCond %{REQUEST_URI} !=/                                                                                                                                                                                                                         
RewriteRule ^.+$ index.html [R=301,L]

I tried prepending the following but that didn’t cut it, so I just temporarily disabled it all:

RewriteCond %{REQUEST_URI} !^\.well-known/acme-challenge/.*                                                                                                                                                                                            
1 Like

Didn’t work for me. Centos 6. Python 2.6.
I tried ./certbot-auto renew and got:
(venv)[root@www certbot]# ./certbot-auto renew
/opt/eff.org/certbot/venv/lib/python2.6/site-packages/cryptography/init.py:26: DeprecationWarning: Python 2.6 is no longer supported by the Python core team, please upgrade your Python. A future version of cryptography will drop support for Python 2.6
DeprecationWarning
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/www.crosswire.org.conf

Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate
/opt/eff.org/certbot/venv/lib/python2.6/site-packages/acme/jose/jwa.py:110: DeprecationWarning: signer and verifier have been deprecated. Please use sign and verify instead.
signer = key.signer(self.padding, self.hash)
Performing the following challenges:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.
Attempting to renew cert (www.crosswire.org) from /etc/letsencrypt/renewal/www.crosswire.org.conf produced an unexpected error: Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA… Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/www.crosswire.org/fullchain.pem (failure)


All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/www.crosswire.org/fullchain.pem (failure)

1 renew failure(s), 0 parse failure(s)

Then I tried ./certbot-auto --apache and got:
(venv)[root@www certbot]# ./certbot-auto --apache
/opt/eff.org/certbot/venv/lib/python2.6/site-packages/cryptography/init.py:26: DeprecationWarning: Python 2.6 is no longer supported by the Python core team, please upgrade your Python. A future version of cryptography will drop support for Python 2.6
DeprecationWarning
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache

Which names would you like to activate HTTPS for?

1: crosswire.org
2: community.crosswire.org
3: git.crosswire.org
4: labs.crosswire.org
5: mail.crosswire.org
6: www.crosswire.org
7: www.ntmss.org
8: vmrcre.org
9: www.vmrcre.org

Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter ‘c’ to cancel): 1,2,4,5,6
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
/opt/eff.org/certbot/venv/lib/python2.6/site-packages/acme/jose/jwa.py:110: DeprecationWarning: signer and verifier have been deprecated. Please use sign and verify instead.
signer = key.signer(self.padding, self.hash)
Performing the following challenges:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.

@pde It’s a bit offtopic, but why clone the whole certbot repository for just the certbot-auto script? As far as I can see on github, the script hasn’t been updated for a month now, so it’s not because of very recent updates. I assume the EFF download link is being kept rather up to date? Or is it because the certbot-auto script can use the files from the repository?

Thanks for responses everyone. They help us out a lot.

@ndesktop, what command were you running when that happened?

@lrayssiguier, this one’s a little strange to me. You have a redirect for that domain which is one of the known issues with our current HTTP-01 support in Apache, but I would expect a simple redirect to a different domain on the same server (like to add www) to work with our current approach. With that said, we should handle cases like this better in the next few days. If you’re interested in trying again then to see it our improved approach solves the problem, I would appreciate it.

@tan9, would you be willing to email me the relevant server block of your nginx config so we can try to reproduce this? My email is bmw@eff.org.

@DMSmith and @Osiris, certbot-auto in the above instructions is only used with certbot-auto --os-packages-only which installs Certbot’s OS dependencies on your system. Using certbot-auto to run Certbot will cause it to use the latest released version which does not include the HTTP-01 support we’re asking people to test here.

(venv) XXXXXX@XXXXXX:~/certbot$ ./certbot-auto --apache -d insert -d domains -d here --preferred challenges http-01
Requesting to rerun ./certbot-auto with root privileges...
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Obtaining a new certificate
Performing the following challenges:
None of the preferred challenges are supported by the selected plugin

I’m pretty sure this isn’t supposed to happen, even using it without --preferred-challenges does not work.

@bmw Then what do you do next? I don’t understand the instructions.

Rereading the original post, I see how this is confusing. I edited it to make this more clear, but the command you should run after initial setup is sudo certbot --apache and/or sudo certbot --nginx.

The commands from the initial topic:

git clone https://github.com/certbot/certbot
cd certbot
sudo ./certbot-auto --os-packages-only
tools/venv.sh
. venv/bin/activate

The last step stalled as I said for over 10 minutes and I aborted.

To work around top-level redirect rules the nginx plugin will have to add something like this at the top level of the server directive, before any other rewrite lines (could be inserted at the top of the block):

rewrite ^(/.well-known/acme-challenge/.*) $1 break;

This is basically a no-op, but the ‘break’ terminates rewrite rule matching at the top level. This has to be outside any location directives to override top-level rewrite rules. Otherwise they can take effect first and break the validation. A typical example would be a rewrite rule (or a return directive) setting up an unconditional HTTP->HTTPS redirect.

1 Like

Hi, it worked for me on an ARMBIAN 5.36 user-built Ubuntu 16.04.3 LTS 3.4.113-sun8i with a Dynamic DNS Domain at ddnss.de.

Thank you

1 Like

how to use it on ami aws with apache please?

The certbot command acts as if it’s the system one, not the one in the directory. It shows that there are no challenges it can run. @bmw