You are here
SgtWirehead - Mon, 2017/01/09 - 06:38
Hi all,
Ive been trying to get Letsencrypt on v14.1 with Odoo though webmin but am having no joy. has anyone got this working and how. Step by step instructions wold be awsome please.
So far I have letsencrypt installed and the webmin plugin is showen. I have tryied to generate the setificats but when i enable ssl I loose access to webmin and the ather Web interfaces. So i am assuming that webmin has no real control over ssl and Odoo, if this is the case how and were do I put the certificats for Odoo??
Forum:
Tags:
Perhaps let me explain a little...
So to use an alternate cert with Webmin (and Webshell) you'll need to configure stunnel to use it (and not Webmin).
It should (hopefully) be as simple as editing the stunnel config file to point to the new cert location and restarting stunnel.
So if you log into your server via SSH, you can edit the config file with nano. Open it like this:
Then look for this line: and adjust it to point to your new Let's Encrypt cert. Exit and save (control-x IIRC). Then restart: Odoo itself is proxied by Apache, so you will need to add the new cert to that as well. You have a couple of options there. Possibly the most straightforward (option 1 below) is to adjust the global Apache SSL config file. Note that this will have global consequence so if you reconfigure Apache to serve something else, that will also inherit this SSL cert. If you don't want that, follow the alternate "option 2".Option 1: adjust global Apache conf
Use nano again to edit the config: Adjust the following certificate path to match that of your new certificate: Then restart Apache:Option 2: adjust Odoo only config
The alternative is to add the certificate declaration line to the existing Odoo Apache config file. Again use nano:
This time we add a new line the same as the line that is in the global conf (note local conf overrides global conf). Add it directly below the line that says: So the updated file will look something like this (this is just a snippet, not the whole file):[...] <VirtualHost *:443> SSLCertificateFile /path/to/your/cert.pem SSLEngine on [...]Then restart Apache as per above note.Hope that helps.
Thanks
Hi Jeremy,
Thank you heaps for the much needed instructions, i will try all of them in clones of my VM's and chose the most suitable method for my needs.
Update:
Just tried Option 1 after using the lets encrypt..
certbot-auto --apache -d example.com./certbot-auto --apache -d example.comcertbot-auto --apache -d example.comit askes me the following i chose option 3.
We were unable to find a vhost with a ServerName or Address of luxurycleaningservices.ath.cx.
Which virtual host would you like to choose?
(note: conf files with multiple vhosts are not yet supported)
-------------------------------------------------------------------------------
1: adminer.conf | | HTTPS | Enabled
2: 000-default.conf | | |
3: default-ssl.conf | | HTTPS |
-------------------------------------------------------------------------------
Select the appropriate number [1-3] then [enter] (press 'c' to cancel):
I pointed the config files to /etc/letsencrypt/live/example.com/fullchain.pem: combination of server, root and intermediate certificates (replaces cert.pem and chain.pem).
then rebooted. LSB and apatche fail to start!? so reverted the config files any ideas?
Hmm, that's not good!
Assuming you still have the original self-signed cert.pem, then you should be able to compare the contents of what you have, with s known good format that Apache will accept. It may require a little trial and error to work out what is required.
FWIW you can just restart the services from the commandline (as noted in my previous post). That will tighten up your feedback loop.
I have never used Certbot so I have no idea how it works or what it does, so I can't really guide you there.
oh dear..
ok i started again and did the following
i did this to stop any interfearance from the webservers that are running.
then i did
then
then
then created the certificates with letsencrypt. recived NO errors or extra options this time during creation :D
then followed your instructions
changed the certificate line in
to
then for Option 1: adjust global Apache conf
with same resault LSB and apatche fail to start!?
looking at the error log there seem to be a lot of errors relating to localhoast loopback at 127.0.0.1!
lets encrypts explination of the keys...
Each key (.pem) file serves a different purpose:
cert.pemandchain.pemchain.pem).so i am asuming there is somthin wrong with the command i did for the certifficate creation with
must this need to point to the localhoast loopback at 127.0.0.1?
A few things
Next, after a quick google, it looks like you can't use "fullchain.pem" in the context you are trying to. Here's what you should need to put in your /etc/apache2/mods-available/ssl.conf file. Note you need to replace this line with the first line, then add the other 2 lines directly below:
Also, I assume that you aren't really using "example.com" are you? You need to substitute your real domain name everytime "example.com" is mentioned!
As for your errors about localhost in your Apache logs, you can fix them by explicitly stating the ServerName (and "ServerAlias" if desired). I.e. in your Apache site/virtualhost config file (/etc/apache2/site-available/odoo.conf) you need to replace "localhost" with "example.com" on this line.
You also probably want to set the server/domain name for networking. I found an answer on ServerFault that should do the trick. It's referring to Debian 7 (aka Wheezy) but it's close enough. FWIW TurnKey v14.x is based on Debian 8 (aka Jessie).
If you still have troubles, please post the last 10-15 lines of your Apache error log.
Apache error log
Hi Jerome,
You will have bear with me as I am part blind makes things tricky, not a complete wombat mate. my paths are fine that's just my bad typing sorry for that and Noo! I'm not using example.com i just did not want to list my web address publicly here, was going to leave the hostname stuf till last as there are some aspects of odoo requireing loopback e.g. sendmail is bound to localhost.
ok i have added the 2 lines in /etc/apache2/mods-available/ssl.conf file
last 10-15 lines of Apache error log
[Wed Jan 11 11:16:20.567039 2017] [proxy:error] [pid 25915] AH00959: ap_proxy_connect_backend disabling worker for (127.0.0.1) for 60s
[Wed Jan 11 11:16:20.567048 2017] [proxy_http:error] [pid 25915] [client 123.2.156.211:51368] AH01114: HTTP: failed to make connection to backend: 127.0.0.1, referer: https://luxurycleaningservices.ath.cx/web/
[Wed Jan 11 11:16:38.544907 2017] [proxy:error] [pid 26582] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:8072 (127.0.0.1) failed
[Wed Jan 11 11:16:38.545007 2017] [proxy:error] [pid 26582] AH00959: ap_proxy_connect_backend disabling worker for (127.0.0.1) for 60s
[Wed Jan 11 11:16:38.545016 2017] [proxy_http:error] [pid 26582] [client 123.2.156.211:51377] AH01114: HTTP: failed to make connection to backend: 127.0.0.1, referer: https://luxurycleaningservices.ath.cx/web/
[Wed Jan 11 11:16:51.475825 2017] [proxy:error] [pid 25937] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:8072 (127.0.0.1) failed
[Wed Jan 11 11:16:51.475907 2017] [proxy:error] [pid 25937] AH00959: ap_proxy_connect_backend disabling worker for (127.0.0.1) for 60s
[Wed Jan 11 11:16:51.475918 2017] [proxy_http:error] [pid 25937] [client 123.2.156.211:51394] AH01114: HTTP: failed to make connection to backend: 127.0.0.1, referer: https://luxurycleaningservices.ath.cx/web/
[Wed Jan 11 12:07:33.261872 2017] [proxy:error] [pid 24129] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:8072 (127.0.0.1) failed
[Wed Jan 11 12:07:33.262094 2017] [proxy:error] [pid 24129] AH00959: ap_proxy_connect_backend disabling worker for (127.0.0.1) for 60s
[Wed Jan 11 12:07:33.262104 2017] [proxy_http:error] [pid 24129] [client 123.2.156.211:51657] AH01114: HTTP: failed to make connection to backend: 127.0.0.1, referer: https://luxurycleaningservices.ath.cx/web/
[Wed Jan 11 12:07:55.400322 2017] [proxy:error] [pid 24129] AH00940: HTTP: disabled connection for (127.0.0.1)
[Thu Jan 12 06:25:05.995155 2017] [mpm_prefork:notice] [pid 648] AH00171: Graceful restart requested, doing restart
I wasn't suggesting that you're a wombat! :)
FWIW we get all sorts using TurnKey and I have learned that it doesn't pay to make too many assumptions about a user's level of knowledge and understanding. As a general rule, I find that issues often get resolved faster if I err on the side of risking offending those who know what they're doing. Apologies if you thought I was suggesting things that are obvious to you!
From your log it actually looks like the real problem is connecting to the Odoo backend!? See this particular entry:
TBH I would have assumed that the proxy side of things should "just work" regardless of the Apache front end certificate used. It seems perhaps not?!
Following a brief google, I discovered a tool that may assist us to confirm whether or not it's actually an Apache config issue. Or whether it's something funky going on between Apache and Odoo.
So please redo your latest config updates. Before you try restarting Apache, please run this and see what it says:
If my suspicions are correct, then it will output something like this:
In which case, I'm sure it is something specifically related to proxying and/or Odoo itself. TBH, other than ensuring that Odoo is running, I'm not really sure what else the issue might be. Perhaps you may get some hints from the Odoo error log. IIRC you can find that in /var/log/openerp-server
Apologies for the Wombat comment
yeah i am from Oz as well. I've been using linux for ni on 30 years since i started with RHL v4 - v5 moved on to Debian 10 years ago, but i would still consider myself a novice with linux as well. and lets encrypt is extreamly new so i have no knolage of it as yet as this is my first time using it.
I ran
yealding the following error
Well the .pam files are there and there symlinks that maybe the problem, maybe apache2.conf is not following them?!
So i changed the below code in apache2.conf to try and have it follow the symlinks for the certs. no joy
No worries on the wombat! :)
Ah ok, so you've been using Linux A LOT longer then me! :) I've only been using Linux heavily for about 8 or 9 years. Although it's pretty much all I use for the last ~4 years. I run Debian Jessie on my laptop and I find it a huge improvement over Windows (7). As for Let's Encrypt, I'm actually yet to even try it myself, hence my guessing at possible solutions. Anyway, but on topic:
Firstly, thanks for your patience, but it sounds like we're at least having some progress.
Apache should have no issue following symlinks on the config side of things. FWIW the parent Apache process actually runs as root, but then launches forked processes under the www-data user. AFAIK the update your tried is related to content being served rather than also applying to config info (although I could be wrong there...).
Personally, what I'd be inclined to do is to first double check that there aren't any typos and that the file Apache is looking for does exist. So I'd start with:
That should give you some insight into whether or not the "file" exists, whether or not it's a symlink and if it is a symlink, whether the target file it's pointing to exists or not. Depending on how impaired your vision is, it may not be much use to you, but the colour of the filename gives some indication:If that all checks out, perhaps it's worth testing just updating the Apache config to point directly to the actual real cert file(s)? At least for testing that will likely eliminate some possible issues.
lets encrypt error on google
Seems to be a common theme for lots of people, one of whitch is permitions on the symlinked .pem files so i changed them to 755 as sujested by lets encrypt team. still no go
has turnkey by chance changed somthing in?
The lets encrpt team in some post have mentioned highly custominsed apache2's may not work with lets encrypt.
Did you check what 'ls -l' tells you?
Also, did you enable the default-ssl vhost? Perhaps that's the issue? Unless you have explicitly enabled and reconfigured it, it's probably clashing with the odoo config. You should only have odoo and adminer enabled - i.e. your sites-enabled directory should look like this:
Assuming you didn't explicitly configure and enable default-ssl, then please disable it and restart Apache. E.g.:
As for TurnKey compatibility with Let's Encrypt; lot's of others have reported success. Although no one has explicitly commented on the Odoo appliance so I'm not 100% sure there. We are planning to include a TurnKey specific Let's Encrypt config script in the next release (which I'm currently working on). So I will be doing some more testing in the next few days. I hope to have that wrapped up this week, early next week at the latest. I will let you know once it's ready.
In the meantime, it is quite possible that the default TurnKey config is not compatible with the "automagical" certbot configuration. But you should still be able to manually configure it to work. So long as you have valid certs, there is no reason why the TurnKey config shouldn't work. Whilst we harden the default Apache config, we do not rebuild the Apache binaries or anything like that (we use the Debian packages from the official main repo.
Looks like certbot is causing the issue
I also owe you an apology as I missed your point in your second post that the Odoo Apache config wasn't offered as an option. Anyway, it looks like certbot client just isn't smart enough to deal with a reverse proxy. FWIW disabling the 000-default-ssl.conf works around the immediate issue. But if I understand correctly simply doing that will cause future issues when it next wants to update.
As you are probably aware, to confirm that you own the domain, Let's Encrypt uses a challenge-response model. The are a few different ways that can be done, but the most common is that the challenge is issued to the Let's Encrypt client (certbot in your case) by way of a specific path. To be approved, the server needs to provide the correct response by way of serving the specific path from the server.
As Apache is only acting as a reverse proxy, certbot enables another site that will allow it to serve what it needs to. But that breaks the reverse proxy config for Odoo. I have mucked around with it and managed to get it working. I need to do some more testing and I'll post back ASAP.
No worries
Thanks Jeromy
I had been doing some reading my self and found that to be the case.
All good I will wait for you to play with it a bit more cos i'm at a loss now, reverse proxy is a bit beond me as i have only ever used single webservers with single sites.
look forward to any updates
Here's a working config
root@odoo ~# cat /etc/apache2/sites-available/odoo.conf ServerName localhost <VirtualHost *:80> RewriteEngine on ReWriteCond %{SERVER_PORT} !^443$ RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L] </VirtualHost> <VirtualHost *:443> SSLEngine on ServerAdmin webmaster@localhost Alias /.well-known/acme-challenge /var/www/lets-encrypt <Directory /var/www/lets-encrypt> Options None AllowOverride None Require all granted </Directory> ProxyRequests Off SSLCertificateFile /etc/letsencrypt/live/www.jeremydavis.org/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/www.jeremydavis.org/privkey.pem <Proxy *> Order deny,allow Allow from all </Proxy> ProxyVia On ProxyPass /.well-known ! # Needed for real time message / chat feature (longpolling) ProxyPass /longpolling/poll http://127.0.0.1:8072/longpolling/poll/ timeout=200 ProxyPass /longpolling/poll/ http://127.0.0.1:8072/longpolling/poll/ timeout=200 ProxyPassReverse /longpolling/poll/ http://127.0.0.1:8072/longpolling/poll/ ProxyPass / http://127.0.0.1:8069/ timeout=200 ProxyPassReverse / http://127.0.0.1:8069/ RequestHeader set "X-Forwarded-Proto" "https" # Fix IE problem (http error 408/409) SetEnv proxy-nokeepalive 1 </VirtualHost>Obviously you'll need to restart Apache to apply the new config:
wow you have a working Odoo :)
Well yours is looking good so far, nice to see your work is progressing.
what combination did you use on the command line for Lets Encrypt?
or
or other?
If i use
it ask me what config file to use, so i chose the adminer.conf
this leaves all of the turnkey web interfaces intack but knocks Odoo on the head. (may be a clue there for that side of things).
I've been playing with the various switches but have not got the right combination as yet.
Its not properly set up, but it works for now...
I did exactly what you did initially (which broke Odoo). Then I just updated my config (as per above). My suspicion is that it will break again when it tries to renew.
Unfortunately I'm not 100% sure how to ensure that renewing the cert won't break it using Certbot. And I'm not really that keen to spend time trying to work it out as we're not actually going to use Cerbot. FWIW in our opinion, it leaks too much info. The implementation we're going with is called Dehydrated. But I still have work to do on it...
Once I have worked it all out and tested sufficiently, then we'll be releasing our next version of TurnKey (14.2). Once we have Core v14.2 released, then I'll document how to upgrade an existing v14.x server to use our Let's Encrypt implementation.
In the meantime AFAIK, you can get Certbot to just generate the certificates and not do any of the config stuff. You'll need to reload the Apache config when the cert is updated though so you may need to create a custom cron job to update the cert and reload Apache (service apache2 reload).
Bonza crack on mate
Bonza mate I'll let you crack on with it as it sounds like ya as bussy as a cat burying shite, hope ya not gona be out back of Burke with it or it turns into a dogs breakfast on ya. If ya ever in Brisvagus give us a coey and I'll take ya out for a tinny or two.
hi Jeremy, how are you
hi Jeremy, how are you progressing with this sofar, any instructions yet for 14.1?
Yes we're having significant progress.
If you are at all interested in helping test it out, please have a look at this thread on our issue tracker. Actually, this post is probably the place to start.
Please note though, if you have already installed Let's Encrypt's Certbot, then you will need to roll back any changes that you made to install that. The version of python-dialog Certbot requires is much newer than the legacy version TurnKey uses (updating it is one of our many todos). In fact TBH, it will be much easier to test on a vanilla TurnKey install...
Thanks Jeremy,
Thanks Jeremy,
Been following you links and readning thought the code :) I found it very interesting, I rely apreciate the time you lot put in a lot of ppl do see this. as a gestamate how far off would 14.2 with latest odoo be?
We have finalised the Let's Encrypt stuff
Previously we release all appliances at the same time, and all the same version. From here on in, appliances may be at different versions. So we will release Core v14.2 first and then release the other appliances (as v14.2) in batches. Odoo definitely won't be in the first batch as it hasn't been updated yet. But we will get to it eventually. The main thing this change to release regime will mean is that the particularly popular appliances can be updated more regularly without needing to wait for a new full release.
I intend to announce each new appliance release batch on our blog as we go. So if keep an eye on that (or any of our social media accounts - which get updates from our blog) then you'll know as soon as it gets published. Regardless, I'll try to remember to post back here once things are a little clearer re v14.2 Odoo.
Add new comment