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

(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

@ndesktop, so it hung running either sudo certbot --apache or sudo certbot --nginx? Can you paste the log of the issue found in /var/log/letsencrypt? Feel free to redact domains, emails, and IPs as you deem appropriate.

@untuned, ah, that’s because . venv/bin/activate only affects your current shell. If you close and reopen it, you have to run that command again or you can run Certbot directly without putting it in your PATH from venv/bin/certbot.

@bmw Since I wrote and before you responded, the whitelist came through for our server, so that satisfied my immediate need.

But I thought I’d let you know that I’ve since tried your improved instructions. Again, didn’t work for me. I think it may be a Centos/RHEL 6 issue of having python 2.6. I ran both certbot renew and certbot --apache and both croaked on the following:
File “/space/home/dmsmith/certbot/certbot/venv/lib/python2.6/site-packages/lexicon/common/options_handler.py”, line 23
super(SafeOptions, self).update({k:v for k,v in update_options.items() if v})

I can provide more of the output if needed.

DM

Some notes:

  • Due to the default sudo secure_path setting on Debian Stretch, I had to run sudo ./venv/bin/certbot to use the virtualenv certbot even with the virtualenv activated.

  • Let’s Encrypt appears to have re-enabled tls-sni-01 for existing account keys so I had to pass --preferred-challenges=http to be able to test http-01.

Unfortunately, I was ultimately unable test http-01 issuance due to my server configuration. I have a single http virtual host that redirects to the https form regardless of domain. (The server hosts a number of pure-HTTPS domains.) certbot certonly -a nginx failed with Could not automatically find a matching server block. Set the server_name directive to use the Nginx installer.

I understand the nginx installer’s reluctance to proceed in this circumstance, but perhaps the authenticator could fall back to the default virtual host in this situation, especially considering tls-sni-01 works in this configuration.

1 Like

@DMSmith, I’m glad you were able to obtain the cert you needed. You’re right that the problem you saw was due to Python 2.6. tools/venv.sh installs all of Certbot’s plugins and some of them do not work on this version of Python. Unfortunately, I forgot about this when I edited the instructions. Thanks for pointing this out. I’ve updated the original instructions again to work around this problem if you feel like trying again.

@Patches, thanks for the helpful notes. I’ve updated the instructions in the original post to deal with both of those problems. Unfortunately, getting that error message about matching server blocks is currently expected if you don’t have a server block listening on port 80 containing a server_name directive matching the name you’re requesting a certificate for. This is one of things we’re planning on fixing before the release though.

1 Like

Hi @bmw, I just got this issue when running the last command:

tools/_venv_common.sh -e acme -e . -e cerbot-apache -e certbot-nginx

  • VENV_NAME=venv
  • rm -rf *.egg-info
  • date +%s
  • mv venv venv.1515882035.bak
  • virtualenv --no-site-packages --setuptools venv --python /usr/bin/python2
    Running virtualenv with interpreter /usr/bin/python2
    New python executable in /home//certbot/certbot/venv/bin/python2
    Also creating executable in /home//certbot/certbot/venv/bin/python
    Installing setuptools, pkg_resources, pip, wheel…
    Complete output from command /home//certbo…bot/venv/bin/python2 - setuptools pkg_resources pip wheel:
    Traceback (most recent call last):
    File “”, line 24, in
    File “/usr/share/python-wheels/pip-8.1.1-py2.py3-none-any.whl/pip/init.py”, line 215, in main
    File “/home//certbot/certbot/venv/lib/python2.7/locale.py”, line 581, in setlocale
    ** return _setlocale(category, locale)**
    locale.Error: unsupported locale setting

…Installing setuptools, pkg_resources, pip, wheel…done.
Traceback (most recent call last):
File “/usr/lib/python3/dist-packages/virtualenv.py”, line 2363, in
main()
File “/usr/lib/python3/dist-packages/virtualenv.py”, line 719, in main
symlink=options.symlink)
File “/usr/lib/python3/dist-packages/virtualenv.py”, line 988, in create_environment
download=download,
File “/usr/lib/python3/dist-packages/virtualenv.py”, line 918, in install_wheel
call_subprocess(cmd, show_stdout=False, extra_env=env, stdin=SCRIPT)
File “/usr/lib/python3/dist-packages/virtualenv.py”, line 812, in call_subprocess
% (cmd_desc, proc.returncode))
OSError: Command /home//certbo…bot/venv/bin/python2 - setuptools pkg_resources pip wheel failed with error code 1

Later edit: made it work with this: https://stackoverflow.com/questions/14547631/python-locale-error-unsupported-locale-setting

I think SystemD’s PrivateTmp feature on CentOS 7 and RHEL 7 might be an issue. I added a GitHub issue for it. After disabling PrivateTmp it works for me using CentOs 7.3.

Once this feature lands, will I need to do anything to update existing sites so they renew correctly or will certbot switch to http-01 automatically?

1 Like

Somehow it’s not working for me.
https://pieterjan.pro/LetsEncrypt.docx
I use Apache2 on Raspbian Stretch

Not sure this is the right thread in which to post this suggestion, and of course I may not have spotted some glaring issue, or an easy fix, but it seems that for anyone who has multiple sub-domains fronted by a reverse proxy, both http and dns might be complex to make work consistently. I think there might be a secure and relatively easy way to automate TLS-SNI whitelisting on a domain name basis.

What if the domain ownership is validated via a required sub-domain e.g. le-89729572.mydomain.com with either a DNS or HTTP validation method, and then SNI is whitelisted for any sub domains using the same IP address(es)? That seems highly automatable and verifiable, and if abused easily revoked on a domain basis.

@ryanjaeb, again, thank you so much for the detailed issue. A fix for this has landed in master. Once the feature is released, as long as you’re getting an updated version of Certbot on your system, it will switch to HTTP-01 automatically.

@PieterjanDeClippel, I think you may have had the same problem as @ryanjaeb. From the certbot directory, try running git pull and then run Certbot again to see if you still have the issue.

@bmw Inside a docker container that runs nginx - this is the error we are getting:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for test1.aicial.io
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. test1.aicial.io (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://test1.aicial.io/.well-known/acme-challenge/HfntYogksMO0sqVwj0GyvJAiYbh47bamCGj453LQON4: Timeout

Can use really/nginx-certbot:testing which has certbot built per the instructions in this post and then linked.

Does anybody know if the TLS-SNI-01 outage affects the Let’s Encrypt for cPanel plugin? I’ve been able to successfully issue certificates using that plugin since the start of the outage, which I assume is because it uses the HTTP validation method.

However, I just wanted to make sure that the hosting provider I work for (and thus get hosting through) hasn’t had any exception made, and I can therefor continue issuing certificates on other hosting providers. I obviously don’t maintain certificates on any VPS machines or anything, so this issue may not apply to me at all.

@troykelly: the validation servers timed out trying to connect to the your server to retrieve the validation file. It doesn’t appear to be related to the new functionality. Your website works from my connection, so please try again and if the error persists open a new top-level thread so a Let’s Encrypt engineer can see if there are any issues with their network.

@sulliops: There are a few different CPanel plugins for Let’s Encrypt. The CPanel-authored AutoSSL plug-in uses http-01.