Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA #5405

Closed
themarkymark-steem opened this Issue Jan 10, 2018 · 81 comments

Comments

Projects
None yet
@themarkymark-steem
Copy link

themarkymark-steem commented Jan 10, 2018

My operating system is (include version):

Ubuntu 16.04

I installed Certbot with (certbot-auto, OS package manager, pip, etc):

OS Package Manager

I ran this command and it produced this output:

sudo certbot renew --dry-run
or
sudo certbot --nginx -d [hostname]

Certbot's behavior differed from what I expected because:

¯_(ツ)_/¯

Here is a Certbot log showing the issue (if available):

Logs are stored in /var/log/letsencrypt by default. Feel free to redact domains, e-mail and IP addresses as you see fit.

2018-01-10 04:20:37,807:INFO:certbot.auth_handler:Performing the following challenges:
2018-01-10 04:20:37,808:CRITICAL:certbot.auth_handler:Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.
2018-01-10 04:20:37,810:WARNING:certbot.renewal:Attempting to renew cert (www.coolsite.com) from /etc/letsencrypt/renewal/www.coolsite.com.conf produced an unexpected error: Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.. Skipping.
2018-01-10 04:20:37,812:DEBUG:certbot.renewal:Traceback was:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/certbot/renewal.py", line 425, in handle_renewal_request
main.renew_cert(lineage_config, plugins, renewal_candidate)
File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 743, in renew_cert
_get_and_save_cert(le_client, config, lineage=lineage)
File "/usr/lib/python2.7/dist-packages/certbot/main.py", line 80, in _get_and_save_cert
renewal.renew_cert(config, domains, le_client, lineage)
File "/usr/lib/python2.7/dist-packages/certbot/renewal.py", line 297, in renew_cert
new_certr, new_chain, new_key, _ = le_client.obtain_certificate(domains)
File "/usr/lib/python2.7/dist-packages/certbot/client.py", line 318, in obtain_certificate
self.config.allow_subset_of_names)
File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 68, in get_authorizations
self._choose_challenges(domains)
File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 103, in _choose_challenges
self.authzr[dom].body.combinations)
File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 374, in gen_challenge_path
return _find_smart_path(challbs, preferences, combinations)
File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 411, in _find_smart_path
_report_no_chall_path()
File "/usr/lib/python2.7/dist-packages/certbot/auth_handler.py", line 442, in _report_no_chall_path
raise errors.AuthorizationError(msg)
AuthorizationError: Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA.

Here is the relevant nginx server block or Apache virtualhost for the domain I am configuring:

server {
listen 3002;
server_name www.coolsite.com;

location / {
    proxy_pass http://coolip:3002;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
 }

}

@bmw

This comment has been minimized.

Copy link
Contributor

bmw commented Jan 10, 2018

Unfortunately, Let's Encrypt has stopped offering the mechanism that Certbot's Apache and Nginx plugins use to prove you control a domain due to a security issue. See https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188 for more info.

We are planning on releasing a new version of Certbot in the next few days that works around this but if you have to obtain/renew your cert and cannot wait, you have a couple of options. If you're serving files for that domain out of a directory on that server, you can run the following command:

sudo certbot --authenticator webroot --installer nginx

If you're not serving files out of a directory on the server, you can temporarily stop your server while you obtain the certificate and restart it after Certbot has obtained the certificate. This would look like:

sudo certbot --authenticator standalone --installer nginx --pre-hook "service nginx stop" --post-hook "service nginx start"

These hooks will cause Certbot to automatically stop your server to obtain certificates and then start it again. After running a command like this once, Certbot will remember your settings so certbot renew will work in the future.

For other people who find this issue, this affects some of our other plugins as well such as the Apache plugin. All the advice above is identical except you should replace nginx with apache in the different CLI options.

EDIT: The post hook in the 2nd example was previously "server nginx stop" but I changed it to the correct value of "service nginx start".
EDIT2: Updated the beginning of the post in response to TLS-SNI-01 being permanently disabled.

@themarkymark-steem

This comment has been minimized.

Copy link
Author

themarkymark-steem commented Jan 10, 2018

When I do the 2nd option, I get an error saying it is unable to connect to domain. It's trying to connect via port 80, but the site is hosted on a custom port. Where do I tell it to do the authentication via a custom port?

Thanks for the insanely quick response, I wasn't finding anything online.

@bmw

This comment has been minimized.

Copy link
Contributor

bmw commented Jan 10, 2018

When I do the 2nd option, I get an error saying it is unable to connect to domain. It's trying to connect via port 80, but the site is hosted on a custom port. Where do I tell it to do the authentication via a custom port?

If you need Certbot to listen on a different port, you can include --http-01-port <port> on the command line, but if I'm understanding you correctly, the problem is that Let's Encrypt server externally is attempting to connect via port 80. Unfortunately, you cannot change this and Let's Encrypt will always attempt to connect to your server via this port.

If you need a cert now and can't (even temporarily) use one of the above options, you can also look at our manual plugin. I left instructions about how to use this out of my previous response as it can be a little tedious, but it allows you to work around more complex setups. Set --authenticator manual on the command line and it will walk you through manually setting up the challenge or alternatively, you can provide scripts for the manual plugin to run to set up and tear down the challenge as described in the link.

Thanks for the insanely quick response, I wasn't finding anything online.

Thanks for the kind words! Happy to help.

@themarkymark-steem

This comment has been minimized.

Copy link
Author

themarkymark-steem commented Jan 10, 2018

The sites are listening on custom ports locally (3000 range), but only expose the ssl port (5000 range) to the public.

I can temporarily change the port, but there are three hosts on here and that's just a big pain to keep doing. I guess I can add it into a script to modify the host file to expose port 80 then switch it back after.

I'll look to see if the manual way is more or less work.

What's the likelihood this will be resolved and auto-renew will work again with nginx?

@themarkymark-steem

This comment has been minimized.

Copy link
Author

themarkymark-steem commented Jan 10, 2018

Just did it manually, it's not too bad, but obviously can't auto-renew, but the DNS option is quick and painless.

Thanks!

@bmw

This comment has been minimized.

Copy link
Contributor

bmw commented Jan 10, 2018

Great! In the future when this incident is resolved if you want to switch back to the old authentication method so certbot renew works, just run:

sudo certbot --nginx -d <domain> --force-renewal

This will cause Certbot to renew your certificate even it's not close to expiration, but it will remember the settings it used to obtain the cert and use them with certbot renew going forward.

@themarkymark-steem

This comment has been minimized.

Copy link
Author

themarkymark-steem commented Jan 10, 2018

Best way to be notified when the issue is resolved?

@bmw

This comment has been minimized.

Copy link
Contributor

bmw commented Jan 10, 2018

You can just watch this issue. This is going to be a common problem for people until it is resolved so we can leave it open until then.

@christopherfowers

This comment has been minimized.

Copy link

christopherfowers commented Jan 10, 2018

I apologize for being "that guy" but is there an estimate that anyone knows of for a resolution to this?

@samlh samlh referenced this issue Jan 10, 2018

Closed

Closed #5406

@hola56

This comment has been minimized.

Copy link

hola56 commented Jan 10, 2018

Hi,

I tried the second option but hit this error:

Starting nginx: [FAILED]

Hook command "service nginx start" returned error code 1
Error output from service:
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] still could not bind()

Problem binding to port 80: Could not bind to IPv4 or IPv6.

Cannot see a new certificate on the server so assuming it didn't work at all.

Do you have any advice on how to get round this please?

@iabel

This comment has been minimized.

Copy link

iabel commented Jan 10, 2018

Thanks BMW. I had the same issue with apache. For those working with apache, this worked for me:

certbot --authenticator standalone --installer apache -d <yourdomain> --pre-hook "systemctl stop apache2" --post-hook "systemctl start apache2"

@taur

This comment has been minimized.

Copy link

taur commented Jan 11, 2018

for debian/ubuntu:
certbot --authenticator standalone --installer apache -d <yourdomain(s)> --pre-hook "apache2ctl stop" --post-hook "apache2ctl start"

@ccoenen

This comment has been minimized.

Copy link

ccoenen commented Jan 12, 2018

For those watching: it hasn't been explicitly said in here, but this appears to be the source: TLS-SNI-01 has been deactivated as authentication scheme because of security issues.
https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996
https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188

@artfulrobot

This comment has been minimized.

Copy link

artfulrobot commented Jan 12, 2018

iabel's method worked for me on Debian 9 (which uses systemd by default).

@Lonni93

This comment has been minimized.

Copy link

Lonni93 commented Jan 12, 2018

Hi everybody,
I didn't understand yet how renew existing certificates obtained with TLS-SNI-01 challenge. Do I have to obtain new certificates with the suggested "webroot" method (that indeed works perfectly for new domains) manually for every domain? What if I have many of them?

Thx to all

@Rudloff

This comment has been minimized.

Copy link

Rudloff commented Jan 12, 2018

@Lonni93 For domains that expire soon, you can easily renew them like this:

sudo certbot renew --webroot --cert-name example.com --webroot-path /path/to/webroot

For other domains that expire later, you can wait for the next release of certbot that should fix this issue.

@Yizi

This comment has been minimized.

Copy link

Yizi commented Jan 14, 2018

When I type the following is asking for the new webroot which is /var/www/html but it doesn't accept this. Any ideas?

sudo certbot --authenticator webroot --installer nginx

EDIT:

The following worked for me not sure why:

sudo certbot --authenticator webroot -w /var/www/html/ --installer nginx

@gnulnx

This comment has been minimized.

Copy link

gnulnx commented Jan 14, 2018

I'm using nginx and trying like this:

sudo certbot --authenticator webroot --installer nginx -m dude@dude.com --agree-tos --noninteractive --webroot-path /home/ubuntu/site/ -d oursite.blah.com

certbot fails with a TIMEOUT trying to fetch

http://oursite.blah.com/.well-known/acme-challenge/LCBIafxnKoVQjt91ykJHRGAG_XB7cZs2QHKynSXqII4:

This simply won't work. We only allow https for 1 (required by our payment gateway) and for 2 it's trying access /.well-known/acme... which doesn't exist on our site and is correctly throwing a proper 404 error...

We provision all our servers with a single click and we have been using certbot in dev, qa, and prod for a long time now so we would REALLY rather stay with what we have because certbot has been awesome for so long now. I really would rather help find a resolution before coughing up money to purchase a cert, but alas business is business.

Is there any way around this yet?
Is there anything outsiders can do to help?

BTW Thanks to all of you for your hard work and I really appreciate you staying on top of the security issues... Though I wonder how many of us would have been effected?

@gnulnx

This comment has been minimized.

Copy link

gnulnx commented Jan 14, 2018

Just want to clarify ours is not a reissue problem. We need to be able to generate new certs for new stacks on the fly. We never renew certs. We alway's destroy our entire stack and rebuild as part of our security policy and certbot fit in perfectly with that workflow.

@gnulnx

This comment has been minimized.

Copy link

gnulnx commented Jan 14, 2018

Sorry for the stream of comments...

We also tried this:

sudo certbot --authenticator standalone --installer nginx --pre-hook "service nginx stop" --post-hook "service nginx start" -d our.domain.blah

And it's the same TIMEOUT error trying to reach a non valid url.. which is ODD since the command explicitly stops nginx.. so I'm not sure how it expected to reach any url on our site.

@schoen

This comment has been minimized.

Copy link
Contributor

schoen commented Jan 14, 2018

@gnulnx

This comment has been minimized.

Copy link

gnulnx commented Jan 14, 2018

Hi John,

I don't understand how you say you see both of these errors, as
a timeout and a 404 are reported differently on the CA side (from not
allowing inbound port 80 connections at all vs. allowing them but not
finding a particular path).

My apologies. I mean it would throw a 404 if it made it through. Port 80 alway's redirects to 443 so if certbot follows the redirects I'd expect our site to return a 404 an not hold the request until TIMEOUT. But to be clear the error reported by certbot is a TIMEOUT error.

Basically this

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: qa.teaquinox.com
    Type: connection
    Detail: Fetching
    http://qa.teaquinox.com/.well-known/acme-> challenge/tkR_Oa6Nhlh_ppa_ywq5F_2PqcdEdw6gnwrp--QpasQ:
    Timeout

I will go take a look at the links you sent.. and thanks for a such a fast reply!

@chongma

This comment has been minimized.

Copy link

chongma commented Jan 15, 2018

The certbot is working normally for me now. It must have been fixed. I am on centos 7

@bibiwan

This comment has been minimized.

Copy link

bibiwan commented Jan 15, 2018

@chongma : I just have tried and it's still not working.

@afterbit01

This comment has been minimized.

Copy link

afterbit01 commented Jan 16, 2018

I have a few domains with Let’s Encrypt certificate that use tls-sni-01 validation..
Now they fail to renew..

if i do :

certbot --authenticator webroot --webroot-path /var/www/vhosts/www.mydomain.com --installer apache -d www.mydomain.com

the certificate for that domain (and domain alises) is re-generated and the authentication will switch from tls-sni-01 to HTTP-01? correct?

…and next time the command :

certbot – renew

will get the new setting automatically… correct?

@Lonni93

This comment has been minimized.

Copy link

Lonni93 commented Jan 16, 2018

@afterbit01 correct, the new method (webroot) will be used for the next renew

@falconmick

This comment has been minimized.

Copy link

falconmick commented Jan 31, 2018

Is there a way I can be notified when the fix is avaiable for PPA so I can change my config around?

@amjad

This comment has been minimized.

Copy link

amjad commented Feb 1, 2018

label's command worked! thank you.

Is there an update for this?

@dugajean

This comment has been minimized.

Copy link

dugajean commented Feb 1, 2018

The "next few days" have passed. Anything new on this?

chris001 added a commit to chris001/InstallScript that referenced this issue Feb 1, 2018

Add LE TLS cert workaround (SNI vulnerability)
* TLS SNI has been disabled at Lets Encrypt TLS certificate issuing servers.  
 This is what broke the LE TLS cert feature.  
 Workaround now we use `standalone` mode which has the side effect of turning off `nginx` web server for about 10 seconds while the remote Lets Encrypt issuing servers create the TLS cert.  
 certbot/certbot#5405

chris001 added a commit to chris001/InstallScript that referenced this issue Feb 1, 2018

Big update.
* Script can now run again and again without corrupting the installation.
* Script will install to `/home/odoo/` by default, instead of `/odoo/`, this is best practice, because `/home/odoo` will be backed up on typical servers, and `/odoo` will be restricted or refused access on typical servers.
* Script will halt on major errors to more easily locate any errors.
* Cleaned up, combined many `apt-get` and `pip` calls into fewer calls.
* All output goes to `~/install_log` for easier posting to github for help.
* `./install_log` is cleared at the start of each run.
* All work (downloads, building the `conf` file and service file) takes place in home dir.
* Fixed bug, was creating `addons` dir with ownership of `root`.
* Add configurable option to add user `odoo` to group `sudo` or not.
* Show proof that service is running at the end of the run.
* More to do, (put each step into its own function, and create reverse of each function for uninstaller) but this is a great start.

Newest WKHTMLtoPDF 0.12.4 (Nov 2016).

Install the newest version 0.12.4 (Nov 2016) of WKHTMLtoPDF.
Has about 140 commits newer than the previously used 0.12.1 (released 2014) which is obsolete unpatched and unsupported for years now.
https://github.com/wkhtmltopdf/wkhtmltopdf/releases

Fix service start bug. On 16.04 /etc/init.d fails.

Fix service start bug.
Put more blocks of procedural code into functions for easier updating it.
Clean up Enterprise install function.

Fix. Run `odoo-server` as an ordinary user odoo, not member of `sudo` (superadmin).

Running `odoo-server` service as ordinary user is working now.
Set `odoo` user to default as non-`sudo` group member.
This commit lets script continue OK when removing `odoo` user from `sudo` group when already not a member of the `sudo` group.

Fix error checking for install on empty server.

When `odoo-server` stopped, and try to `stop`, don't halt script, just continue.

Show version and install details. Upgrade pip.

Fixes bugs in `start.sh` and postgresql create database.

Better organized.
Easier to see bugs.
Fixes bug in start.sh (was using old name openerp instead of odoo)
Fixes bug, charset error when postgresql tries to create your database at the odoo welcome screen.

Cleanup. Functions. Update version.

Handles command line to install Enterprise: -E -e --enterprise

Save time, no need to edit the script and change a variable just to install Enterprise!
`./odoo_install.sh -E`
`./odoo_install.sh -e`
`./odoo_install.sh --enterprise`

Fix bug in enterprise install, addons_path was omitting custom.

Old bug in enterprise installs.
`addons_path` was failing to include the path `(home)/custom/addons`.
Fixed.

Add sudo. Add flag. Reduce error messages.

You should now be able to run without `sudo` before script name on command line.
Script uses `sudo` which prompts for password when you're not super-admin.

Odoo home folder, fix permission error message.

Fix bug when run install as non-superadmin

Bug. Was failing to create `odoo-server.conf` file.

Add uninstall command line feature. -U or --uninstall

Add missing python libs (from requirements.txt)

These python libraries are required and were missing, and caused serious errors in the `/var/log/odoo/odoo-server` log file:
```
num2words markupsafe ofxparse pillow pyldap pyserial qrcode six
```
Fixed by adding these libs to the function `install_python_libraries`.

Fixes errors (missing python libraries).

This commit fixes the following error.  A feature was broken because of the simple fact of not installing some required libraries.
```
2017-11-22 19:14:34,560 21522 WARNING ? odoo.addons.base.res.res_currency: The num2words python library is not installed, l10n_mx_edi features won't be fully available.
```
Previous commit fixed the above error, but had 2 syntax errors, which are fixed in this commit.

Version number.

Add options --update --upgrade to get newest code from `odoo` repo.

Add options `--update` `--upgrade`.
Either one will get newest code from `odoo` repo.

Version number. clear_install_log.

Make log entries go to the same log file. Not relative to current directory. Because current directory changes during install process.

Improved "--update" code.

Add -h --help option.

Fix missing sudo chown. Add --delete-start-over

* Fix bug, was missing `sudo` in in front of some `chown` commands, this would fail, rather than prompt for password.
* Add option `--delete-start-over`, this does full Uninstall, delete `odoo` user and home fdir, then creates `odoo` user as superadmin, and home dir. Just create a password for `odoo` user (command line: `passwd odoo`), and you're ready to test this install script as typical ordinary (non-`root`) user.

Fix bug install Enterprise (dir wasn't created)

1. Fix bug install Enterprise (dir wasn't created because of shell command variable did not exist in context!). Now it works.
2. Fix bug wasn't adding enterprise addons path. Fixed now it works.

Fix enterprise install bug. Add nginx + LE HTTPS.

1. Fix enterprise install bug (must specify current directory to avoid creating a new dir which puts the code one level too deep).
2. Add NGINX and Lets Encrypt support - not finished yet - command line parsing is not perfect.

Detect sudo and show warning. Number steps.

Next version should be able to run as non-`sudo` and install as much as possible without failing/exiting.
For systems where admin has already installed required packages, maybe on a previous installation.

Nginx + LE HTTPS work. Verifies domain exists.

Add HTTP/2.

Fix Livechat. Runs chat listener process.

I fixed Livechat.
Previously it wasn't listening on the livechat port.
Now it is listening.
However this livechat feature appears to not work on 16.04, probably because of this bug: odoo/odoo#20512
Conclusion, Livechat might work for you.
It will work on python 3.5 (16.04) only if your version of Odoo has the patch that avoids using the feature of python 3.5 that's broken and causing the http responses to be truncated.

Fix parameter checking. Improve run without sudo.

Parameter checking is more user friendly now.
Run without `sudo` in front of the command.  `Sudo` is in the code so `sudo` doesn't need  to be on the command line.
TODO: finish `virtualenv` + finish install as ordinary user (make sure system packages already installed).

FIx a few bigs.

* Fix bug causing script to fail on 14.04, must remove debian packages for `python-pypdf2` and `python3-suds` and install only thru `pip3`.
* TODO: Move all possible debian `python-` packages to install with `pip3`. This makes installer script much more portable across OS.
* Fix `sudo` missing bug on `create_startup_script` in statements `chown` and `mv`.
* Add `universe` repository, in function `update-server` because some extremely minimal servers are missing the default `universe` repo.

Fix typo. update_repo_in_current_dir updates db.

Version.

Fix bug (apt add repository universe).

* `apt-add-repository` is not a built in command! Must be added to a generic default system. Fixed.

Add feature, self-update.

* `odoo_install.sh --self-update` downloads the newest version of this script, saving to the same filename as running, even if different from the original scrip filename.

Fix self-update bug, download filename.

* Even when script filename is changed, must download from the same source filename.

Fix many issues. Add 2 features.

* Change: move `conf` file location to `/etc/odoo/odoo-server.conf` to make easier management of multiple Odoo instances on one server.
* Add command line option `--livechatport=8072` to make possible to install multiple Odoo instances on one server.
* Fix many issues mentioned by @Yenthe666

Move python libs from apt to pip.

Add option --upgrade-python-libraries

* Add option to upgrade to the newest version of python libraries. Many will want to test on these newer library versions, and if they work, run Odoo on these new python library versions, for the many security and bug fixes they offer.

Update the Help with --upgrade-python-libraries

* Add --upgrade-python-libraries to help.
* Improve help entries for other command options.

Remove ZSI. It's not a requirement.

* TODO: Add option to install exactly the python libs listed in `requirements.txt`

Tested OK ubuntu 16.04 lxc/openvz server.

* added `htop`, it helps show activity.
* added `testresources` it's required by `launchpadlib` (used by `bzr` ?) yet wasn't auto installed.

Add 2 python build requirements for minimal 16.04

* Minimal 16.04 appears to miss the build requirements `gcc` and `python3-dev`, needed to install `psutil` thru `pip3`.
* Do `apt-get update` to get all package indexes, before the very first `apt-get install`. Necessary when the OS is totally fresh and has never before run `apt-get update`, causing `apt-get install` to fail because no package indexes have been downloaded yet.

net-tools for netstat diagnostics. Works on 17.10

* Install on Ubuntu 17.10 Artful (note: `nginx` and `LE TLS cert` on 17.10 wasn't tested yet).
* Add package `net-tools` soon to be added feature to display/verify ports in-use by `odoo` and by `nginx`.

Fix download_odoo work when dir isnt empty.

* `git clone` fails when dir isn't absolutely empty! So, we must remove the directory and all its contents (to be sure all the git dotfiles are gone) so that `git clone` will work under all circumstances.

Add LE TLS cert workaround (SNI vulnerability)

* TLS SNI has been disabled at Lets Encrypt TLS certificate issuing servers.
 This is what broke the LE TLS cert feature.
 Workaround now we use `standalone` mode which has the side effect of turning off `nginx` web server for about 10 seconds while the remote Lets Encrypt issuing servers create the TLS cert.
 certbot/certbot#5405
@artemxgruden

This comment has been minimized.

Copy link

artemxgruden commented Feb 2, 2018

if there are problems with webroot method and nginx, check how to: https://gist.github.com/cecilemuller/a26737699a7e70a7093d4dc115915de8

it helps me ( i use certbot inside docker nginx container on ubuntu:16.04 )
thanks to @cecilemuller Cecile Muller

@pde

This comment has been minimized.

Copy link
Member

pde commented Feb 3, 2018

@dugajean yes, Certbot 0.21 was released on the 17th of January, and should have fixed this problem for just about everyone. Some considerations:

  • We need to update the Certbot website to change the warning or what it points to :)
  • You need to actually run Certbot 0.21+. If your OS doesn't have packages for that, certbot-auto is a good temporary solution.
  • The HTTP-01 challenge support in the Apache and Nginx plugins for Certbot 0.21.1 is pretty good, though your webserver needs to be reachable on port 80. If you have problems with it, please file a bug.
@amjad

This comment has been minimized.

Copy link

amjad commented Feb 3, 2018

I still get this error when I follow Digital Ocean’s Lets Encrypt tutorial for Ubuntu Apache.

@chris001

This comment has been minimized.

Copy link

chris001 commented Feb 3, 2018

@amjad
https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-16-04
That tutorial is using the ubuntu ppa for certbot.

$ certbot --version
certbot 0.19.0

The error you get is because the ubuntu maintainer for ppa:certbot/certbot hasn't updated it to certbot 0.21.0 yet, that version contains the fix.
You can workaround by modifying your site to get the cert, either run certbot in standalone mode, or in webroot mode, or download and use cerbot-auto which contains the fix.

@fkrauthan

This comment has been minimized.

Copy link

fkrauthan commented Feb 4, 2018

Any news on the PPA update? This is really a big problem not having a working version. After all the PPA is marked as the official way for running certbot on ubuntu.

@falconmick

This comment has been minimized.

Copy link

falconmick commented Feb 4, 2018

How about instead of the unhappiness we try to help. Is there anything any of us could contribute to help?

@chris001

This comment has been minimized.

Copy link

chris001 commented Feb 4, 2018

@falconmick @fkrauthan

  • Not really any way to contribute or help the certbot ppa ( https://launchpad.net/~certbot/+archive/ubuntu/certbot ).
  • See #5405 (comment)
    @pcraston emailed the ubuntu ppa maintainer for cerbot and they said 13 days ago the fixed version 0.21.0 would be available for download to the general public in about a week, but it's been 13 days, they're lagging, so you should probably just run certbot-auto now, until cerbot 0.21.0 is available, could be tomorrow, could be a month from now. Anyway, cerbot-auto downloads cerbot newest version 0.21.0+ this is the fixed version and it'll renew your certs without that SNI error, follow the steps on the following page to get certbot-auto and run it:
    https://certbot.eff.org/docs/install.html#certbot-auto
@jmpinto

This comment has been minimized.

Copy link

jmpinto commented Feb 4, 2018

Hi
I would like to ask if I'm not able to get a Certificate if my domain extension is .com.br?
I have a server with Centos 6 and Freepbx (with Apache) and is under a domain .com.br all the time that I try to get the certificate using SSH I'm not able because it says that has wrong caracter.
Also using the FreePBX Gui I do not get the Let's Encrypted Certificate
Someone here could help me? Please
Thank you for your time and attention

@ciprianflorescu

This comment has been minimized.

Copy link

ciprianflorescu commented Feb 5, 2018

@chris001

You can workaround by modifying your site to get the cert, either run certbot in standalone mode, or in webroot mode, or download and use cerbot-auto which contains the fix.

I believe I tried all these methods and I still get the error about DNS issues. Is there any detailed, manual installation guide for certbot 0.21? Like downloading the source from a repository to the server, then using that to install certbot. I am running nginx on Ubuntu Trusty 14.04 and they haven't updated their PPA for certbot.

The certbot-auto method didn't work for me either. All these methods eventually lead to either some errors in installation or fail to recognise the domain name. Even though the domain works.

I may just have to give up on letsencrypt and just get a domain with included ssl and call it a day. This whole chain of weak links between Ubuntu maintainers - letsencrypt and whatnot is making me waste time I could use to be more productive.

Sadly the web world is full of such weak links. We need another model for the web.

@falconmick

This comment has been minimized.

Copy link

falconmick commented Feb 5, 2018

Sounds like sombody isn’t happy with there free software, better get him a refund!

In all seriousness though, this is the risk you take when it doesn’t cost a penny, paid certs means that sombody has an incentive to make things as easy as possible for you, so it’s definitely a good option.

My main reason for let’s encrypt is the 3 month auto renewal system. It’s just a better way of handling certs

@FlippingBinary

This comment has been minimized.

Copy link

FlippingBinary commented Feb 5, 2018

@ciprianflorescu I would like to point out that you could seek paid support from one of many providers. Regardless, I went ahead and spun up a server running Ubuntu 14.04 to demonstrate how to run certbot-auto and made a video for you on YouTube. Watch the video if you want. It shows the process working flawlessly.

@chris001

This comment has been minimized.

Copy link

chris001 commented Feb 5, 2018

@ciprianflorescu @falconmick @FlippingBinary @fkrauthan
The Ubuntu PPA for certbot is updated now to 0.21.1 - thanks to certbot ppa maintainers. sudo apt-get upgrade and then cerbot command should work fine for you now.

@jmpinto
If you use certbot-auto on centos 6, it should download the newest version certbot 0.21+ and work fine and it will even install your LE TLS cert into apache2, as long as your specify apache2 on the command line. Watch video of @FlippingBinary https://youtu.be/0TYjZ_TYr-s to learn how to run the process of certbot-auto.

@certbot certbot deleted a comment from ciprianflorescu Feb 5, 2018

@falconmick

This comment has been minimized.

Copy link

falconmick commented Feb 5, 2018

Thanks to everyone who put in the hard work!

@cyio

This comment has been minimized.

Copy link

cyio commented Feb 6, 2018

@chris001 ugrade => upgrade

@ciprianflorescu

This comment has been minimized.

Copy link

ciprianflorescu commented Feb 8, 2018

Thanks for your answers, I already bought a cert from a provider.

@falconmick So this time if something doesn't work, I can actually get that refund you were so concerned about. That's what I call accountability.

@HaeckDesign

This comment has been minimized.

Copy link

HaeckDesign commented Feb 9, 2018

Thank you to the whole Certbot team!! We're starting a monthly donation to EFF in your honor (https://supporters.eff.org/donate) - If there's a way to earmark it for your team, please let us know.

@jfmessierdotca

This comment has been minimized.

Copy link

jfmessierdotca commented Feb 13, 2018

Just to mention that the command that was previously shown for a system by "BMW" actually works as-is for Raspbian OS on my Raspberry pi:

certbot --authenticator standalone --installer apache -d <yourdomain> --pre-hook "systemctl stop apache2" --post-hook "systemctl start apache2"

I only substituted "-d " with the multiple ones I have for my cert. And since I have several domain names, I put the whole thing in a script. Works perfectly for me.

chris001 added a commit to chris001/InstallScript that referenced this issue Feb 27, 2018

Big update.
* Script can now run again and again without corrupting the installation.
* Script will install to `/home/odoo/` by default, instead of `/odoo/`, this is best practice, because `/home/odoo` will be backed up on typical servers, and `/odoo` will be restricted or refused access on typical servers.
* Script will halt on major errors to more easily locate any errors.
* Cleaned up, combined many `apt-get` and `pip` calls into fewer calls.
* All output goes to `~/install_log` for easier posting to github for help.
* `./install_log` is cleared at the start of each run.
* All work (downloads, building the `conf` file and service file) takes place in home dir.
* Fixed bug, was creating `addons` dir with ownership of `root`.
* Add configurable option to add user `odoo` to group `sudo` or not.
* Show proof that service is running at the end of the run.
* More to do, (put each step into its own function, and create reverse of each function for uninstaller) but this is a great start.

Newest WKHTMLtoPDF 0.12.4 (Nov 2016).

Install the newest version 0.12.4 (Nov 2016) of WKHTMLtoPDF.
Has about 140 commits newer than the previously used 0.12.1 (released 2014) which is obsolete unpatched and unsupported for years now.
https://github.com/wkhtmltopdf/wkhtmltopdf/releases

Fix service start bug. On 16.04 /etc/init.d fails.

Fix service start bug.
Put more blocks of procedural code into functions for easier updating it.
Clean up Enterprise install function.

Fix. Run `odoo-server` as an ordinary user odoo, not member of `sudo` (superadmin).

Running `odoo-server` service as ordinary user is working now.
Set `odoo` user to default as non-`sudo` group member.
This commit lets script continue OK when removing `odoo` user from `sudo` group when already not a member of the `sudo` group.

Fix error checking for install on empty server.

When `odoo-server` stopped, and try to `stop`, don't halt script, just continue.

Show version and install details. Upgrade pip.

Fixes bugs in `start.sh` and postgresql create database.

Better organized.
Easier to see bugs.
Fixes bug in start.sh (was using old name openerp instead of odoo)
Fixes bug, charset error when postgresql tries to create your database at the odoo welcome screen.

Cleanup. Functions. Update version.

Handles command line to install Enterprise: -E -e --enterprise

Save time, no need to edit the script and change a variable just to install Enterprise!
`./odoo_install.sh -E`
`./odoo_install.sh -e`
`./odoo_install.sh --enterprise`

Fix bug in enterprise install, addons_path was omitting custom.

Old bug in enterprise installs.
`addons_path` was failing to include the path `(home)/custom/addons`.
Fixed.

Add sudo. Add flag. Reduce error messages.

You should now be able to run without `sudo` before script name on command line.
Script uses `sudo` which prompts for password when you're not super-admin.

Odoo home folder, fix permission error message.

Fix bug when run install as non-superadmin

Bug. Was failing to create `odoo-server.conf` file.

Add uninstall command line feature. -U or --uninstall

Add missing python libs (from requirements.txt)

These python libraries are required and were missing, and caused serious errors in the `/var/log/odoo/odoo-server` log file:
```
num2words markupsafe ofxparse pillow pyldap pyserial qrcode six
```
Fixed by adding these libs to the function `install_python_libraries`.

Fixes errors (missing python libraries).

This commit fixes the following error.  A feature was broken because of the simple fact of not installing some required libraries.
```
2017-11-22 19:14:34,560 21522 WARNING ? odoo.addons.base.res.res_currency: The num2words python library is not installed, l10n_mx_edi features won't be fully available.
```
Previous commit fixed the above error, but had 2 syntax errors, which are fixed in this commit.

Version number.

Add options --update --upgrade to get newest code from `odoo` repo.

Add options `--update` `--upgrade`.
Either one will get newest code from `odoo` repo.

Version number. clear_install_log.

Make log entries go to the same log file. Not relative to current directory. Because current directory changes during install process.

Improved "--update" code.

Add -h --help option.

Fix missing sudo chown. Add --delete-start-over

* Fix bug, was missing `sudo` in in front of some `chown` commands, this would fail, rather than prompt for password.
* Add option `--delete-start-over`, this does full Uninstall, delete `odoo` user and home fdir, then creates `odoo` user as superadmin, and home dir. Just create a password for `odoo` user (command line: `passwd odoo`), and you're ready to test this install script as typical ordinary (non-`root`) user.

Fix bug install Enterprise (dir wasn't created)

1. Fix bug install Enterprise (dir wasn't created because of shell command variable did not exist in context!). Now it works.
2. Fix bug wasn't adding enterprise addons path. Fixed now it works.

Fix enterprise install bug. Add nginx + LE HTTPS.

1. Fix enterprise install bug (must specify current directory to avoid creating a new dir which puts the code one level too deep).
2. Add NGINX and Lets Encrypt support - not finished yet - command line parsing is not perfect.

Detect sudo and show warning. Number steps.

Next version should be able to run as non-`sudo` and install as much as possible without failing/exiting.
For systems where admin has already installed required packages, maybe on a previous installation.

Nginx + LE HTTPS work. Verifies domain exists.

Add HTTP/2.

Fix Livechat. Runs chat listener process.

I fixed Livechat.
Previously it wasn't listening on the livechat port.
Now it is listening.
However this livechat feature appears to not work on 16.04, probably because of this bug: odoo/odoo#20512
Conclusion, Livechat might work for you.
It will work on python 3.5 (16.04) only if your version of Odoo has the patch that avoids using the feature of python 3.5 that's broken and causing the http responses to be truncated.

Fix parameter checking. Improve run without sudo.

Parameter checking is more user friendly now.
Run without `sudo` in front of the command.  `Sudo` is in the code so `sudo` doesn't need  to be on the command line.
TODO: finish `virtualenv` + finish install as ordinary user (make sure system packages already installed).

FIx a few bigs.

* Fix bug causing script to fail on 14.04, must remove debian packages for `python-pypdf2` and `python3-suds` and install only thru `pip3`.
* TODO: Move all possible debian `python-` packages to install with `pip3`. This makes installer script much more portable across OS.
* Fix `sudo` missing bug on `create_startup_script` in statements `chown` and `mv`.
* Add `universe` repository, in function `update-server` because some extremely minimal servers are missing the default `universe` repo.

Fix typo. update_repo_in_current_dir updates db.

Version.

Fix bug (apt add repository universe).

* `apt-add-repository` is not a built in command! Must be added to a generic default system. Fixed.

Add feature, self-update.

* `odoo_install.sh --self-update` downloads the newest version of this script, saving to the same filename as running, even if different from the original scrip filename.

Fix self-update bug, download filename.

* Even when script filename is changed, must download from the same source filename.

Fix many issues. Add 2 features.

* Change: move `conf` file location to `/etc/odoo/odoo-server.conf` to make easier management of multiple Odoo instances on one server.
* Add command line option `--livechatport=8072` to make possible to install multiple Odoo instances on one server.
* Fix many issues mentioned by @Yenthe666

Move python libs from apt to pip.

Add option --upgrade-python-libraries

* Add option to upgrade to the newest version of python libraries. Many will want to test on these newer library versions, and if they work, run Odoo on these new python library versions, for the many security and bug fixes they offer.

Update the Help with --upgrade-python-libraries

* Add --upgrade-python-libraries to help.
* Improve help entries for other command options.

Remove ZSI. It's not a requirement.

* TODO: Add option to install exactly the python libs listed in `requirements.txt`

Tested OK ubuntu 16.04 lxc/openvz server.

* added `htop`, it helps show activity.
* added `testresources` it's required by `launchpadlib` (used by `bzr` ?) yet wasn't auto installed.

Add 2 python build requirements for minimal 16.04

* Minimal 16.04 appears to miss the build requirements `gcc` and `python3-dev`, needed to install `psutil` thru `pip3`.
* Do `apt-get update` to get all package indexes, before the very first `apt-get install`. Necessary when the OS is totally fresh and has never before run `apt-get update`, causing `apt-get install` to fail because no package indexes have been downloaded yet.

net-tools for netstat diagnostics. Works on 17.10

* Install on Ubuntu 17.10 Artful (note: `nginx` and `LE TLS cert` on 17.10 wasn't tested yet).
* Add package `net-tools` soon to be added feature to display/verify ports in-use by `odoo` and by `nginx`.

Fix download_odoo work when dir isnt empty.

* `git clone` fails when dir isn't absolutely empty! So, we must remove the directory and all its contents (to be sure all the git dotfiles are gone) so that `git clone` will work under all circumstances.

Add LE TLS cert workaround (SNI vulnerability)

* TLS SNI has been disabled at Lets Encrypt TLS certificate issuing servers.
 This is what broke the LE TLS cert feature.
 Workaround now we use `standalone` mode which has the side effect of turning off `nginx` web server for about 10 seconds while the remote Lets Encrypt issuing servers create the TLS cert.
 certbot/certbot#5405

Fix wkhtmltopdf dependencies, nginx upload size.

* Add `wkhtmltopdf` missing dynamic runtime dependencies `libxrender1 fontconfig xvfb` because it's not truly fully static even though it claims to be fully static.
* Set `max_client_body_size 200m;` to allow upload for the purpose to restore database backups. Default was 8MB (`8m`) far too small.

Add dependencies for livechat, css, etc.

* Add additional dependencies for livechat (`python-psycogreen`) + node stuff (previously believed to be for enterprise version only).

Upgrade to systemd service. Show free space, RAM.

* Upgrade to install a modern `systemd` service by default. Can still specify command line option `--sysvinit` to use old/obsolete SysV service.
* Show system statistics at start of script. Free disk space, and RAM memory.
@bmw

This comment has been minimized.

Copy link
Contributor

bmw commented Mar 21, 2018

On that note, I think this resolved issue has outlived its usefulness. As always, if anyone has an honest issue using Certbot or has a bug report or feature request, please feel free to make a new issue or topic on https://community.letsencrypt.org respectfully explaining it and people will be happy to help you.

@certbot certbot deleted a comment Mar 21, 2018

@certbot certbot locked as resolved and limited conversation to collaborators Mar 21, 2018

@certbot certbot deleted a comment from TomasHubelbauer Mar 21, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.