User menu

Search form

You are here

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

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

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.

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:

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.

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

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:

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

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

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:

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.

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:

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.

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.

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.

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

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.

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

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