SgtWirehead's picture

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: 
Jeremy Davis's picture

Ok for starters, in v14.x Webmin and Webshell are both behind stunnel. Stunnel is sort of like a proxy as it provides an encrypted tunnel between external and internal resources. Both Webmin and Webshell listen on (non-encrypted) ports, but only on localhost (so aren't accessible remotely). Stunnel listens remotely (only on https) and provides a tunnel to whatever apps are configured behind it (in this case Webmin and Webshell).

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:

nano /etc/stunnel/stunnel.conf
Then look for this line:
cert = /etc/ssl/private/cert.pem
and adjust it to point to your new Let's Encrypt cert. Exit and save (control-x IIRC). Then restart:
service stunnel4 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:
nano /etc/apache2/mods-available/ssl.conf
Adjust the following certificate path to match that of your new certificate:
SSLCertificateFile /etc/ssl/private/cert.pem
Then restart Apache:
service apache2 restart

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:

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:
<VirtualHost *:443>
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.

SgtWirehead's picture

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.com

certbot-auto --apache -d example.com

it 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?


Jeremy Davis's picture

My guess is that the file is not what Apache was expecting. Perhaps fullchain.pem is not compatible with Apache in this context? I suggest that you check the Apache error log and hopefully that will provide some additional info.

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.

SgtWirehead's picture

ok i started again and did the following

/etc/init.d/apache2 stop
/etc/init.d/shellinabox stop
/etc/init.d/webmin stop

i did this to stop any interfearance from the webservers that are running.

then i did

apt-get install git

then

git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt

then

cd /opt/letsencrypt

then created the certificates with letsencrypt. recived NO errors or extra options this time during creation :D

./letsencrypt-auto certonly --standalone -d example.com -d www.example.com

then followed your instructions

changed the certificate line in

/etc/stunnel/stunnel.conf

to

etc/letsencrypt/live/example.com/cert.pem

then for Option 1: adjust global Apache conf

SSLCertificateFile etc/letsencrypt/live/example.com/cert.pem

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.pem: server certificate only.
  • chain.pem: root and intermediate certificates only.
  • fullchain.pem: combination of server, root and intermediate certificates (replaces cert.pem cert.pem and chain.pemchain.pem).
  • privkey.pem: private key (do not share this with anyone!).

so i am asuming there is somthin wrong with the command i did for the certifficate creation with

./letsencrypt-auto certonly --standalone -d example.com -d www.example.com

must this need to point to the localhoast loopback at 127.0.0.1?

 


Jeremy Davis's picture

Firstly, you have leading slashes missing from your certificate path. Without the leading slash, this is a relative path:
etc/letsencrypt/live/example.com/cert.pem
You need to an absolute path (note the leading slash):
/etc/letsencrypt/live/example.com/cert.pem

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:

SSLCertificateFile    /etc/letsencrypt/live/example.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/example.com/fullchain.pem

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.

SgtWirehead's picture

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

SSLCertificateFile    /etc/letsencrypt/live/example.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/example.com/fullchain.pem

 

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


Jeremy Davis's picture

Ah another Aussie?! Or is the "wombat" terminology going global?! :)

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:

[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

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:

apachectl configtest

If my suspicions are correct, then it will output something like this:

Syntax OK

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

SgtWirehead's picture

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

apachectl configtest

 

yealding the following error

AH00526: Syntax error on line 88 of /etc/apache2/mods-available/ssl.conf : 
SSLCertificateFile; file'/etc/letsencrypt/live/example.com/cert.pem' 
does not exist or is empty

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

# access here, or in any related virtual host.
<Directory />
#    Options FollowSymLinks
    Options ExecCGI FollowSymLinks SymlinksIfOwnerMatch
    AllowOverride None
    Require all denied
</Directory>

 

 


Jeremy Davis's picture

It's all good. I actually had a little giggle to myself! :)

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:

ls -l /etc/letsencrypt/live/example.com/cert.pem
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:
  • White: means it's just a "normal" file (what a .pem file should be)
  • Cyan (light blue/green): means that it's a symlink pointing to a valid file/dir. The "-> file/or/path" shows the file it's pointing to. E.g. "ls -l /etc/apache2/sites-enabled/"
  • Red: means that it's a broken symlink which points to a non-existent path.

    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.

  • SgtWirehead's picture

    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

    SSLCertificateFile; file'/etc/letsencrypt/live/example.com/cert.pem' 
    does not exist or is empty

     

    has turnkey by chance changed somthing in?

    /etc/apache2/sites-enabled/default-ssl.conf

    The lets encrpt team in some post have mentioned highly custominsed apache2's may not work with lets encrypt.


    Jeremy Davis's picture

    As posted earlier, using 'ls -l /etc/letsencrypt/live/example.com/cert.pem' might shed some light on what is going on?

    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:

    root@odoo ~# ls -l /etc/apache2/sites-enabled 
    total 0
    lrwxrwxrwx 1 root root 35 Feb  1 06:11 odoo.conf -> ../sites-available/odoo.conf
    lrwxrwxrwx 1 root root 31 Feb  1 06:14 adminer.conf -> ../sites-available/adminer.conf

    Assuming you didn't explicitly configure and enable default-ssl, then please disable it and restart Apache. E.g.:

    a2dissite default-ssl
    service apache2 restart

    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.

    Jeremy Davis's picture

    I have spent quite a bit of time fiddling around with this. I thought it may have been an issue with the Odoo proxy, but it actually runs deeper than that. Essentially it appears that certbot is enabling 000-default-ssl.conf, but that conflicts with the default Odoo config. FWIW in the Odoo appliance, Apache is simply there as a reverse proxy for the Odoo application (which is served by a python server which is not suitable for webfacing production use).

    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.

    SgtWirehead's picture

    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

     


    Jeremy Davis's picture

    Below is a config which I have confirmed works. As you can probably see, the domain I've been working with is www.jeremydavis.org. I haven't yet tested the implementation of the certs with Webmin and Webshell, but I'm hoping that should work fine too. It's probably already been created, but if not, please make sure that /var/www/lets-encrypt exists and is owned by www-data.
    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:

    service apache2 restart
    SgtWirehead's picture

    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?

    ./letsencrypt-auto certonly --standalone -d example.com -d www.example.com

    or

    ./letsencrypt-auto --apache -d example.com

    or other?

     

    If i use

    ./certbot-auto --apache -d example.com

    it ask me what config file to use, so i chose the adminer.conf

    1: adminer.conf        |             | HTTPS | Enabled 

    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.

     

                                                                               

                                                                   


    Jeremy Davis's picture

    FWIW I'm currently working on making this all work "TurnKey" style so you won't need to worry too much about any of this in a week or so...

    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).

    SgtWirehead's picture

    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.


    SgtWirehead's picture

    hi


    Jeremy Davis's picture

    We've gone a slightly different approach with our implementation and are using a separate (micro) webserver to serve the Let's Encrypt challenges when required. That way it will work consistently with all of our appliances, regardless of what (if any) webserver they use and regardless of how it is configured.

    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...

    SgtWirehead's picture

    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?


    Jeremy Davis's picture

    We have finalised the Let's Encrypt stuff and that's ready to roll. But we're not sure when we'll get to updating and releasing the new Odoo appliance. We are going to do things a little differently for v14.2 than we've done before.

    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