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:
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.
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.
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
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
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):
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
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
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.
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.
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):
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.