Thanks for letting us know. Note there is a risk of you change getting overwritten if ever the Let's Encrypt app gets updated. There is a HowTo here which should be easily adaptable for Let's Encrypt and has a (currently) safer way for forcing a service restart.

Using the methodology in the HowTo, I think you can use the fullchain for the TLSCertificateFile and the CA should point to /etc/pki/tls/certs/ca-bundle.crt, but if yours works, it works.

I believe the Certificate Manager app is being re-written and may include app restart hooks as well.

Just thought I would share here that I got the letsencrypt certs working with ldaps

The pems below are symlinks into the /etc/letsencrypt/live/<my_domain>/

Made this change in the slapd.conf

TLSCACertificateFile   /etc/openldap/letsencrypt/fullchain.pem

TLSCertificateFile     /etc/openldap/letsencrypt/cert.pem

TLSCertificateKeyFile  /etc/openldap/letsencrypt/privkey.pem

I had to fix up permissions such that ldap group could read the certs.

I also added slapd to the daemon_list in
/usr/clearos/apps/lets_encrypt/libraries/Lets_Encrypt.php

hopefully this is all that is required to restart openldap once the certs renew.

I can now connect to ldaps from some immutable containers that were previously giving me cert chain errors.

Probably wouldnt take much to add this to the directory app so it could all be done from the UI.

Hope this helps someone

certbot still is at version 0.21 in the repo..., OTOH certbot now is releasing 0.28
including support for ACME v2, and plugins for various dns providers to support dns authentication.
What's the direction Clear OS will take.. Stick to old version or update.

Hi Nick,

Thank you for your quick reply and the how to for the webconfig. It is now clear to me, that it is not a solution for OpenVPN. I know the docu is still in development, but it might be good to remove OpenVPN from the description of the let's encrypt app, which states:

"Let's Encrypt is an open certificate authority that provides free SSL certificates. The app intelligently integrates the certificate lifecyle and management into Webconfig to be used by other services - Webconfig, website hosting, Openfire, OpenVPN etc. ."

Still a very nice app.

Thank you.

Best wishes,

Robert

That is more than what it can do, and, really, more than what you want it to do. The main thing is for the certificate(s) to be used in the Web Server and, as a secondary, in the Webconfig.

The problem with OpenVPN is that you want to create per-user certificates which must come from a Certificate Authority (even if it is you). The Lets Encrypt certificates do not let you sign other ones with them so you cannot create Lets Encrypt user certificates. The also expire every 90 days and OpenVPN does not have any obvious method to redistribute them either.

My experience of the mail apps (postfix/cyrus-imap) is that Let's Encrypt certificates are a pain as well. I tried it, but when mine expired and were renewed I had to go to each client and re-accept the certificates both for the sending and receiving server. This is at odds with the thoughts from the devs and I will need to re-test some time. In reality mail apps, are pretty flexible about the certificates they use and they seem to perform little validation on them. They just need to be there. My cyrus-imap certificate expired 4 years ago and my clients don't complain. The only client which I know complains is Outlook.

[edit]
And for the Web Server you change the certificates in Webconfig > Server > Web > Web Server and for the Webconfig in Webconfig > System > Settings > General Settings
[/edit]

Hi,

I would expected that I can chose the let's encrypt certificate in the certificate manager using the new let's encrypt app to be used by OpenVPN, webconfig, ... . Is it not intended for that or do I do something wrong?

Thank you.

Best wishes,

Robert

Hi Nuke,
It should be pretty easy to migrate. Disable any cron job you've set up as the app comes with its one. In the Webconfig Web Server screen, for each web site you have configured, edit it and you should find your certificates in the Digital Certificate dropdown. You should then be able to go back into the certificate manager and delete the Lets Encrypt certificate you originally imported.

The app has been designed on top of certbot so uses the standard certbot folder layout and will use any pre-existing certificates. It did with mine where it was a single certificate covering multiple sub-domains of my own domain and my poweredbyclear.com sub-domain at the same time.

I followed the directions here and on the Let's Encrypt site to install and get certificates for a couple of websites served up by my home server.

With v7.4 there is a new app in the Marketplace.

So any suggestions on how to migrate from the manual install following directions above to using the Marketplace app?

Thanks.

Merrill Cook wrote:

Nick Howitt wrote:
1 - You can use the storage manager app to achieve this but I think you'll need to get under the hood a little.

Good to know, except a search in the Marketplace for 'storage' doesn't show anything that resembles what you are describing, so it must not be for mere mortals. Maybe app-storage-manager ? (Yes, I can probably hunt around in the repositories for a list of app- packages to see for myself, just making a point about webconfig and Marketplace.)

There does not appear to be an app in the marketplace, but check it is not already installed under Webconfig > System > Storage > Storage Manager. Dave indicated it gets installed with things like the web server. Setting up the Storage Manager once ClearOS is installed and running requires command line work.

Nick Howitt wrote:

2 - If you use the default web site, that is what you will get, with all files in the traditional place under /var/www/html.

The virtual web app in webconfig doesn't seem to allow for an alternative port, which is a requirement in my use case. So I guess I have to try to make the flexshare work as the main web site. At least app-lets-encrypt solves the certificate problem flexshare caused.

No, it does not cater for alternative ports but that is pretty non-standard as would be the opening of a non-standard port in the firewall. ClearOS caters for the more normal usage of ports 80 and 443.

Nick Howitt wrote:
3 - Personally I never use the webconfig to view logs. I tend to look at the whole file in WinSCP.

Most of my point was that mere mortals using webconfig, or looking in /var/log (as it would say in a generic linux book) -- and probably using journalctl? -- would still not be able to find the file without a lot of hunting around with winscp, and even then each set of files is in a different location.

I've just had a look at the log viewer. All logs in all subdirectories are visible from the "Log file" dropdown box. It is pretty easy to browse an of the logs.

Nick Howitt wrote:
4 - I don't have my server set up that way, with people logging in. I use Simple Server mode.

Sorry, I don't find that option in webconfig for flexshares (and we discussed how making changes outside of webconfig usually leads to tears). So not an option for mere mortals? Or is there something I'm not seeing, or a doc article I should be looking at?

No it is a standard option in the Windows Networking set up. Go Webconfig > Server > File > Windows Networking (Samba) > Mode > Edit and change the mode to simple server.

Nick Howitt wrote:
1 - You can use the storage manager app to achieve this but I think you'll need to get under the hood a little.

Good to know, except a search in the Marketplace for 'storage' doesn't show anything that resembles what you are describing, so it must not be for mere mortals. Maybe app-storage-manager ? (Yes, I can probably hunt around in the repositories for a list of app- packages to see for myself, just making a point about webconfig and Marketplace.)

Nick Howitt wrote:

2 - If you use the default web site, that is what you will get, with all files in the traditional place under /var/www/html.

The virtual web app in webconfig doesn't seem to allow for an alternative port, which is a requirement in my use case. So I guess I have to try to make the flexshare work as the main web site. At least app-lets-encrypt solves the certificate problem flexshare caused.

Nick Howitt wrote:
3 - Personally I never use the webconfig to view logs. I tend to look at the whole file in WinSCP.

Most of my point was that mere mortals using webconfig, or looking in /var/log (as it would say in a generic linux book) -- and probably using journalctl? -- would still not be able to find the file without a lot of hunting around with winscp, and even then each set of files is in a different location.

Nick Howitt wrote:
4 - I don't have my server set up that way, with people logging in. I use Simple Server mode.

Sorry, I don't find that option in webconfig for flexshares (and we discussed how making changes outside of webconfig usually leads to tears). So not an option for mere mortals? Or is there something I'm not seeing, or a doc article I should be looking at?

Nick Howitt wrote:
Can this discussion go to another thread, if possible?

Absolutely. I only came to this discussion because installing app-php-packages broke a working web site (including all the lets encrypt settings) by installing flexshare as a dependency (but not the full app). But app-lets-encrypt did solve the letsencrypt part of problem quite nicely. Still haven't got all the pieces of the web site put back together, but at least app-lets-encrypt seems to work well.

Thanks.

Hi Merrill,
1 - You can use the storage manager app to achieve this but I think you'll need to get under the hood a little. Rather than just mounting a disk into /var/flexshare/shares it mounts and binds it so the disk can still be used for other stuff, depending on your directory structure.

2 - If you use the default web site, that is what you will get, with all files in the traditional place under /var/www/html. This folder is also mounted and bound into a flexshare so it also appears under /var/flexshare/shares/{your_site} but you are still seeing the same files, just from two different locations.

3 - Interesting idea. Probably easy for the access and error logs and needs a bit more thinking for virtual server logs. Personally I never use the webconfig to view logs. I tend to look at the whole file in WinSCP.

4 - I don't have my server set up that way, with people logging in. I use Simple Server mode. This allows to do the drive mappings permanently on each PC, transparently. This PC is always mapped to certain shares and my son's is mapped to some of the same shares and also his own share. The laptop and other PC used by my wife and me are set up the same way as this PC.

Can this discussion go to another thread, if possible? I don't know how to split it out in the forum, but is is now way off topic of the original post. I may ask the devs if they know how to split this thread.

Hi Peter

Thanks for the background on flexshare.

I can give you a history of my struggles using flexshare. But here are just a few highlights:

1) There's no way in webconfig to change the "root" for flexshares from /var/flexshare/shares to something on (what I think of as) my data drive. I've fiddled with flexshare.conf, but lacking documentation, I usually end up with something I don't want. The result is that I think of flexshares as limiting me to storing data on the root filesystem, meaning I should make just one logical volume that combines all available disks, which just seems wrong, though I know LVM can do it. I suppose I could mount /var/flexshare onto my data drive, or do a symlink, but that's not in webconfig either, and my experience with flexshare/webconfig is that if you make changes via the console, webconfig changes them back when it feels like it.

2) What I want is one web site. I don't want a default web site, a default flexshare website, a virtual site that I will use, and a virtual flexshare site that I will be forced to use sometimes except when it won't do what I want.

3) it looks like flexshare logs (including web virtual site logs) end up somewhere besides in /var/log/httpd. I can usually find the way to view the logs via webconfig, but it usually takes me a few tries and the list of logfiles is pretty long, so hunting through the picklist to find the log I want with several tries is annoying. Suggestion: how about a symlink in /var/log for the current access and error log, to make it easier for us to figure out where they get stored?

4) Flexshare seems to insist on using account authentication for file sharing. We got used to using samba with sharing limited only by LAN IP addresses on a machine not accessible from the public internet; setting it up with accounts and passwords started a minor rebellion.

In other words, I find flexshares inflexible and incredibly frustrating for making a web site, as well as for file sharing. Maybe if I was setting up something that matches EXACTLY the use case for which it was designed, I would find it convenient, but so far it hasn't matched my use cases. That's why I general uninstall it when making a web site and rely on apache conf files. So when I needed php 5.6, I was not happy at all to find that I needed to start wrestling with flexshares again, since it is a dependency of app-php-packages.

On Business I have app-lets-encrypt 1.0.3 and that does not yet have a cron job to update the certificates. Have a look at this post for an idea. You may need to extend the command if you also need it to restart the webconfig if you use LetsEncrypt for its certificate.

Peter Baldwin wrote:

Certificate is not in use.

The Certificate Manager can detect when a certificate is in use via ClearOS apps (e.g. Web Server), but it cannot detect usage inside custom configuration files. Sorry!

Webconfig must had an update ;-)

Now it is saying :

Deployed

This certificate is in use, so delete functions have been disabled

When will the app run an update of the certificate ?
Is there a cronjob needed or is webconfig handling this ?

Hi all,

Here's a little history on the Flexshare and Web Server apps.

Back in the day, Flexshares were used as file stores that could be accessed via FTP, Web and Samba. It was not intended for creating web sites, it was really intended for downloading documents via a web browser.

Along came the Web Server app. The underlying Flexshare engine provided most of the magic that was needed for implementing web sites, so the Flexshare library (but not the UI) was used. We thought about merging the Flexshare library into the Storage app, but then decided to avoid the risk of migrating from /var/flexshare to /var/storage. So yes, when you install the Web Server app, you will pull in the Flexshare (aka Storage) engine.

/etc/httpd/conf.d/ssl.conf

Windows XP was the last major software client that had the "one SSL certificate per IP" limitation. In ClearOS 7, the Web Server and Flexshare apps now allow SSL certificates on a per-share basis. I added a tracker item (https://tracker.clearos.com/view.php?id=17251) to clean up the ssl.conf file -- that should avoid some confusion.

OK, more testing on my test box.

You can add multiple sites with different domains through Webconfig > Server > Web and these go into flexshares. The one that is designated as your default site has /var/www/html bound into it. The other ones get flexshares created, and also a folder in /var/www/virtual and then the folder in /var/www/virtual is bound into the flexshare folder. This means that all the files physically are in /var/www/html or /var/www/virtual/{domain} but are bound into folders in /var/flexshare/shares. By default these work on both WAN and LAN (if you open the incoming WAN firewall).

If you make web sites in flexshares (Webconfig > Server > File > Flexshare), they are quite different. They get a URL based on your Hostname in Webconfig > Network > Settings > IP Settings and not the Internet Hostname as I previously thought. You get two URL's https://Hostname/flexshare/your_web_server_name and https://your_web_server_name.Hostname. Here the files just exist in /var/flexshare/shares and are not bound or linked into anything in /var/www. By default they will only work on your LAN but you can change it.

Both set-ups use virtual sites in flex-443.conf.



.... and I got openvpn-monitor working again.

Hi Merrill,
Please note that I am not particularly advising you to do anything. I am relatively new to web serving and I am trying to work out the ClearOS set up. Until recently my Micky-Mouse webserver ran from /var/www/html and from wherever Roundcubemail and SoGo put themselves, with the conf files in /etc/httpd/conf.d and I made myself a mini index on the landing screen. Then, after a few posts on LetsEncrypt (there is another thread), I decided to give LetsEncrypt a go as my work block sites with self-signed certificates. It was relatively easy to set up and I have a single cert for mydomain.com, www.mydomain.com, server.mydomain.com and me.poweredbyclear.com. To use the certificate I had to edit ssl.conf to point to my certificates. I was not even aware of the Default Web Server at this point.

Then I had a look at the Default Web Server and got into a small mess. Even if I unconfigured it, and, I thought, removed all traces of it, apache would not start until I put back its (empty) log file. I also needed to leave my certificates configured in flex-443.conf. Then I added the LetsEncrypt and the default ClearOS way of doing this is via the Web Server App. So I did that and my certificates refused to renew, but everything else worked. This is because everything else had a .conf file but not LetsEncrypt and certbot was left pointing at the old web root while trying to handshake with the new one. The Default site changed the web root to under the flexshares.

I am now trying to investigate how this works and I am getting inconsistent results. My VM is hosed for web serving - I get a PHP Ooops! so needs rebuilding sometime but it is only a play thing for trying new bits an and so on. I have a test box with a very default installation with a RAID mirror. When you create a Default Web Site there it mount binds /var/www/html into /var/flexshare/shares/{your_website}. This would have left certbot working, but on my production server it does not set up the bind mount which is why it broke. I'll probably set up the bind mount sometime. They have production and test servers have very different disk set ups. The test server is the default set up with RAID and using the LVM. My production server is an upgrade from v6 (so has lots or heritage) and has a more traditional disk partitioning scheme.

In the last couple of days following your posts I've tried playing with the flexshare servers and I am still trying to piece it together. To me it looks like you should perhaps call the Internet Name of your server just mydomain.com. Then I think the default web server gets called that as well. Then you set up flexshare servers which get allocated as subdomains of your main domain, so you may call one www to get www.mydomain.com (although, without a www flexshare, www.mydomain.com would be picked up by the default web server). They also get a path below the Default Domain. You can have multiple subdomains. This is up to you how you want to structure it.

Please have a little play with flexshares as I don't think you've quite grasped the concept. When you set them up you can decide if you want them for any or all of Samba, FTP and Web Serving. If you don't have one of those apps installed then you don't get the option to use it. It is not like you create a flexshare and then have to disable, say, samba access. It is the other way round. I also don't see that it will allow you to create two shares of the same name. I also don't think it will allow you to create a default website and a flexshare site of the same name - the flexshare is always a subdomain of the internet host name, I think.

There is also no problem with all sites running with port 443. The default site will intercept any calls to subdomains which don't exist (or to the domain). conf files in /etc/httpd/conf.d look after the rest.

Both the default web server and flexshare sites use the same flex-443.conf file but there is no apache requirement. You are welcome to create your own conf file for another virtual site and they *should* all happily work together.

Another thing I think I've see is flexshare sites also bind mounting to somewhere wlse like the main site. I think it was also under /var/www/html but I need to investigate

One thing I have not yet found in the webconfig is how to configure ClearOS for multiple domains e.g. mydomain.com and someotherdomain.com. It may or may not be possible but I am struggling to find the time to play around - especially as I can't get my openvpn-monitor site to work for the moment when it used to.

At the end of the day, you don't have to use any of this. You can use /var/www/html and manual conf files.

It sounds like you are saying that the way to make a secure web site is not to go to Server | Web | Web server app and make a virtual site but rather go through Server | File | Flexshare and make a flexshare, where I can enter the virtual web server information just like under Web Server. Then just disable the share part so it doesn't get in the way, and what I have left is the virtual web site I wanted. Then, I suppose, I should resist the temptation to use the web server app to do further configuration, right? So even though I have no need for FTP or SAMBA or other sharing, I still need to use File | flexshare since creating or configuring a virtual web site under the web app will only lead to tears, like ending up with a conf file that is overridden by flex-443.conf for the default.

I don't suppose I'm the only one who finds that counter-intuitive?

One thing that would make this a bit easier is if the webconfig would detect when there is a flexshare and a virtual web server using the same port and domain name, and offer some advice (or just not let it happen). Another option is to have the flexshare virtual web sites show up under the web server app as virtual sites (since they really are) - or make sure any virtual web site is configured to use flex-443 if it has the same name and port/interface as the default flexshare. And I suppose get rid of the default ssl.conf for httpd so people who snoop around the configuration files won't get confused. Or just make it so a virtual web site (with HTTPS) doesn't conflict at all with the default flexshare site and vice versa...

I did try app-lets-encrypt, and it does help a lot. Thanks to all who worked on that.

As for whether multiple virtual sites can use the same IP address and port: I'm used to needing to check that the reverse DNS matches the A record lookup on SSL. I suppose it doesn't matter unless you're going to get audited for PCI or something... So under those circumstances, one can do it. Or wait until we go to IPv6, and every virtual server can have its own unique set of IP addresses.

Hi Merrill,
You've raised quite a few points so i'll try to answer them.

The default website does indeed load into /var/flexshare/shares/{your_website}. It then bind mounts /var/www/html into it so your files really go in /var/www/html (except that it does not on my production box and I am not sure why for the moment, and my play VM is completely broken here). It loads as a virtual site ("<VirtualHost *:443>" in flex-443.conf) and you can create further website "flexshares" in the Flexshares module. Flexshares are multipurpose things which and be any or all of websites/samba shares/ftp servers. Flexshare websites are all set up a subdomains of your server name (and not your default web site). They can have their own certificates but I don't see how to give them their own site name on a different domain. If you are using virtual servers, why can't you have more than one site active on port 443?

The LetsEncrypt app uses the LetsEncrypt certificates in situ, so without copying them. Certbot manages the renewals and symlinking such that all the certificates go under /etc/letsencrypt/archive/{your_website}/ but symlinks the latest one (certificate, intermediate certificate and key) to /etc/letsencrypt/live/{your_website}/. This means the app only ever needs to point to /etc/letsencrypt/live/{your_website}/cert.pem, chain.pem (or fullchain.pem) and privkey.pem as they never change. The Flexshare and Webserver app then allows you to choose from your self-signed cert, LetsEncrypt or any other certificates you've imported. Have a look in flex-443.conf and you'll see how the certificates are called.

Don't worry about what the OP said. This app has come along after and directly reads the LetsEncrypt certificate without any exporting and importing. I think you are missing that the App was Peter responding to the OP saying there was already something in the pipeline to simplify what the OP posted.

FWIW certbot recommends you check the certificates twice daily for expiry. When I set mine up I checked daily because you can put a configlet in /etc/cron.daily very easily without bothering about crontab. The certificates get renewed every 2 months so they don't get near expiry.

I'm having a bit of a problem with Lets Encrypt and app-php-engines. I didn't have flexshare installed, since we aren't using it/them. But app-php-engines seems to be dependent on flexshares (which makes no sense to me -- why should a php add-on be dependent on flexshare?) and now webconfig resets flex-443.conf to use self-signed certs instead of the letsencrypt certs, and I can't find a way to tell apache to use ssl.conf which is where SSL was being configured before I installed app-php-engine. The flexshares app doesn't seem to be completely installed, meaning I don't see it anywhere in webconfig to try to tell it to use the correct certificates. (While on the subject, why is certificate setup done in flex-443 instead of ssl.conf, unless flexshare is a virtual web site designed to use its own separate certificates, which doesn't seem to be possible, or at least intuitive, in webconfig, especially if there is no need to have an unused virtual web site active ... and besides, there is only one port 443 available for the web server to use, so if we want to have a public-facing web site with SSL, there's no way I want flexshare anywhere near it.)

Anyway, before I spend a lot of time playing with it: does app-lets-encrypt tell the web server (that is, flexshare and webconfig) to use the Lets Encrypt certificate in /etc/letsencrypt/live/www.myserver.com/cert.pem, or does it copy the Let's Encrypt cert to /etc/pki/CA/sys-0-cert.pem or wherever the certificate manager (or is it flex share or web config or something else) expects it? Will I need to install the flexshare app from the marketplace in order to have a way to configure it to stop using its own cert and use the letsencrypt cert I want it to use, or does app-lets-encrypt take care of all that?

On the same subject, the OP note suggests using "https://server:81/app/certificate_manager/external/add"; to install the Let's Encrypt certificate. It looks like that means downloading the cert/key/chain to my local machine then uploading them again? Where do they go, and am I supposed to do this again every 90 days when Let's Encrypt renews? Why isn't there an option to enter a path to where the external certificate is stored on the server, that is, at /etc/letsencrypt/live/[domain]/cert.pem, instead of only uploading a file from my local machine?

It's good to know that the new app is using the right certificate files.

Please see the edit above.

As a note of caution to any existing LetsEncrypt users, this hosed my certificate renewal but only because of my particular set up. I had been using /var/www/html as my document root rather than the default website from the Webconfig which I was not aware of when I set my site up a long while ago. When you assign the certificates in the Webconfig Webserver menu, it activates virtual hosts in /var/flexshare/shares/{default_site} and this intercepts some of the handshaking certbot uses to renew certificates. To get round this I had to edit the conf file in /etc/letsencrypt/renewal to point to the new document root. I also copied over the .well-known folder but certbot may create it if it does not exist.

I would not consider this a bug at all, but rather my own fault for not setting up my website using ClearOS methods.

For the Apache version in ClearOS (2.4.6), the "cert.pem" and "chain.pem" are used. The details are in the link that you provided :-) https://certbot.eff.org/docs/using.html#where-are-my-certificates So from what I understand, it looks like:

Apache >= 2.4.8
SSLCertificateKeyFile -> privkey.pem
SSLCertificateFile -> fullchain.pem

Apache < 2.4.8 (ClearOS 7)
SSLCertificateKeyFile -> privkey.pem
SSLCertificateFile -> cert.pem
SSLCertificateChainFile -> chain.pem

To add to the confusion, it looks like the "Apache >= 2.4.8" style works just fine in ClearOS. Perhaps upstream has patched in support? There are over 100 upstream patches on top of Apache 2.4.6 - https://git.centos.org/blob/rpms!httpd.git/c7/SPECS!httpd.spec - so it's quite possible.

fullchain.pem = chain.pem + cert.pem.

In apache you can specify separately the chain (intermediate) and certificate file. ClearOS is set up to use certificates in this fashion as I understand certificate providers generally provide both the certificate and intermediate files. I believe you can get away with specifying the certificate file as fullchain.pem and not specify the chain file, but why bother as this would become a specific set up for LetsEncrypt instead of a general one for all external certificates.

In Peter's program there is no need to copy the certificate to domain.crt. His program configures flex-443.conf to read directly from the /etc/letsencrypt/live/{domain}/*.pem files which are symlinks to the latest certificate. It does not look in /etc/clearos/certificate_manager.d.

Peter Baldwin wrote:

Nick Howitt wrote:

Hi Peter,
When flex-443.conf picks up the certificates, is there any reason for using the fullchain.pem file as the chain file and not chain.pem? The fullchain.pem is a combined cert.pem and chain.pem and you are already picking up cert.pem as the SSLCertificateFile.

Right again Nick! I pushed that change through git last week - https://github.com/eglooca/app-lets-encrypt/commit/cd882a9e7b2d4369f3ad69aff969c16f3a944b51#diff-8e7476918fbf8094bf778783de7dbf30

Please notice that the "correct" certificate file is "fullchain.pem" not "cert.pem". Please have a look at the README file generated by certbot:

This directory contains your keys and certificates.



`privkey.pem`  : the private key for your certificate.

`fullchain.pem`: the certificate file used in most server software.

`chain.pem`    : used for OCSP stapling in Nginx >=1.3.7.

`cert.pem`     : will break many server configurations, and should not be used

                 without reading further documentation (see link below).



We recommend not moving these files. For more information, see the Certbot

User Guide at https://certbot.eff.org/docs/using.html#where-are-my-certificates.

Also, in the crontab script above, the "fullchain.pem" is copied to /etc/clearos/certificate_manager.d/domain.crt

Nick Howitt wrote:

Hi Peter,
When flex-443.conf picks up the certificates, is there any reason for using the fullchain.pem file as the chain file and not chain.pem? The fullchain.pem is a combined cert.pem and chain.pem and you are already picking up cert.pem as the SSLCertificateFile.

Right again Nick! I pushed that change through git last week - https://github.com/eglooca/app-lets-encrypt/commit/cd882a9e7b2d4369f3ad69aff969c16f3a944b51#diff-8e7476918fbf8094bf778783de7dbf30

Hi Peter,
When flex-443.conf picks up the certificates, is there any reason for using the fullchain.pem file as the chain file and not chain.pem? The fullchain.pem is a combined cert.pem and chain.pem and you are already picking up cert.pem as the SSLCertificateFile.

Certificate is not in use.

The Certificate Manager can detect when a certificate is in use via ClearOS apps (e.g. Web Server), but it cannot detect usage inside custom configuration files. Sorry!

Peter Baldwin wrote:

Hi Fargo2,

Thanks for the update... much appreciated! Just to let everyone know, the Let's Encrypt app is coming with the ClearOS 7.4 release (we're staging this release right now). You can install the app right now if you are feeling a bit adventurous:

yum --enablerepo=clearos-updates-testing,clearos-contribs-testing install app-lets-encrypt

The only missing piece is the renewal cronjob/logging. Everything else in the app is ready to go.

You should know that the ClearOS app works alongside the certbot command line tool. In other words, if you have already created certificates with certbot, the app will happily show the certificates in the ClearOS web interface (and also make the certificates available in the Certificate Manager).

Peter,

I've installed the app and looks like it installed correctly.
My previous created certificate is visable in the app, but i see at "Deployed" the message :

Certificate is not in use.

Apparently it is fine for the /etc/pki/CA/openssl.cnf file as it is not used by ClearOS, or, at least, not in this location.

Possible issue.

The app installed a file, /etc/letsencrypt/options-ssl-apache.conf, but I can't see it referenced anywhere in the httpd configuration files which is where I'd expect to find it (probably in the vhost definition in /etc/httpd/conf.d/flex-443.conf). The permitted SSLCipherSuite is very different between the two files and the SSLProtocol a little different.

Also the /etc/pki/CA/openssl.cnf file has been removed (renamed to .rpmsave) but there is no new file to replace it. This has be a little more concerned.

re Peter's comment on logging, certbot logs to /var/log/letsencrypt/letsencrypt.log and "rotates" earlier files each time it runs. These build up to the default of 1000 (3 years! of daily checking). It looks like you can add the --max-log-backups to the certbot line, perhaps setting it to something like 130 (so you always get 2 renewals in your logs). I'm going to give it a try. Alternatively you can use tmpwatch to trim the files back, but I prefer the idea of certbot's built-in functions.

[edit]
Crap. It looks like the docs I was reading were for v0.18 whereas we are at v0.14. Our version of certbot does not appear to support the --max-log-backups parameter:

[root@server ~]# certbot renew --max-log-backups=130 -q --post-hook "systemctl restart httpd.service"

usage:

  certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...



Certbot can obtain and install HTTPS/TLS/SSL certificates.  By default,

it will attempt to use a webserver both for obtaining and installing the

cert.

certbot: error: unrecognized arguments: --max-log-backups 130

So I am hoping the logs build to 1000 then start rotating. I'll find out in another two years ....... If not, it is quite easy to use the tmpwatch command. Also within the next two years I'd hope epel would upgrade their version. Looking at the certbot change log we need at least v 0.17 to get the --max-log-backups option.

I've got it installed. Re Peter's reference to a renewal cron job, for a while now, I've had a file (executable) in /etc/cron.daily with the following line in it:

certbot renew -q --post-hook "systemctl restart httpd.service"

The post-hook only fires when the certificates are renewed and I'm on my 5th renewal with no issues.

Peter Baldwin wrote:

Hi Fargo2,

Thanks for the update... much appreciated! Just to let everyone know, the Let's Encrypt app is coming with the ClearOS 7.4 release (we're staging this release right now). You can install the app right now if you are feeling a bit adventurous:

yum --enablerepo=clearos-updates-testing,clearos-contribs-testing install app-lets-encrypt

You're welcome.

This is a great news. I'll be looking forward to clearOS 7.4.

Thank you.

Mirrors are back up again.

Nick Howitt wrote:

Mirrors down?

[root@server certificate_manager.d]# yum clean all

Loaded plugins: clearcenter-marketplace, fastestmirror

ClearCenter Marketplace: fetching repositories...

Cleaning repos: clearos clearos-centos-sclo-rh clearos-centos-verified

              : clearos-contribs clearos-epel-verified clearos-fast-updates

              : clearos-infra clearos-verified libreswan private-clearcenter-ad

              : private-clearcenter-antimalware private-clearcenter-antispam

              : private-clearcenter-business private-clearcenter-content-filter

              : private-clearcenter-dyndns private-clearcenter-dynvpn

              : private-clearcenter-ids private-clearcenter-master-slave

              : private-clearcenter-rbs private-clearcenter-security-audit

              : private-clearcenter-verified-updates private-clearcenter-wpad

Cleaning up everything

Cleaning up list of fastest mirrors

[root@server certificate_manager.d]# yum --enablerepo=clearos-updates-testing,clearos-contribs-testing install app-lets-encrypt

Loaded plugins: clearcenter-marketplace, fastestmirror

ClearCenter Marketplace: fetching repositories...

Could not retrieve mirrorlist http://mirrorlist.clearos.com/clearos/mirrorlist/clearos-current-os-7 error was

14: curl#7 - "Failed connect to mirrorlist.clearos.com:80; No route to host"





 One of the configured repositories failed (Unknown),

 and yum doesn't have enough cached data to continue. At this point the only

 safe thing yum can do is fail. There are a few ways to work "fix" this:



     1. Contact the upstream for the repository and get them to fix the problem.



     2. Reconfigure the baseurl/etc. for the repository, to point to a working

        upstream. This is most often useful if you are using a newer

        distribution release than is supported by the repository (and the

        packages for the previous distribution release still work).



     3. Run the command with the repository temporarily disabled

            yum --disablerepo=<repoid> ...



     4. Disable the repository permanently, so yum won't use it by default. Yum

        will then just ignore the repository until you permanently enable it

        again or use --enablerepo for temporary usage:



            yum-config-manager --disable <repoid>

        or

            subscription-manager repos --disable=<repoid>



     5. Configure the failing repository to be skipped, if it is unavailable.

        Note that yum will try to contact the repo. when it runs most commands,

        so will have to try and fail each time (and thus. yum will be be much

        slower). If it is a very temporary problem though, this is often a nice

        compromise:



            yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true



Cannot find a valid baseurl for repo: clearos/7

Yes the: mirrorlist.clearos.com is down. I hard coded one of the repositories for a temporary solution. Example of : clearos.repo

# Can not access the above mirror list on 15 Sept 2017, hard coded the baseurl for all the clearos repo's

[clearos]

name=ClearOS $releasever - $basearch - OS

#baseurl=http://mirror.clearos.com/clearos/$releasever/os/$basearch/

baseurl=http://mirror1-newyork.clearos.com/clearos/$releasever/os/$basearch/

#mirrorlist=http://mirrorlist.clearos.com/clearos/mirrorlist/clearos-current-os-$releasever

enabled=1

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ClearOS-$releasever



[clearos-updates]

name=ClearOS $releasever - $basearch - Updates

#baseurl=http://mirror.clearos.com/clearos/$releasever/updates/$basearch/

baseurl=http://mirror1-newyork.clearos.com/clearos/$releasever/updates/$basearch/

#mirrorlist=http://mirrorlist.clearos.com/clearos/mirrorlist/clearos-current-updates-$releasever

enabled=1

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ClearOS-$releasever



[clearos-updates-testing]

name=ClearOS $releasever - $basearch - Updates (Testing)

#baseurl=http://mirror.clearos.com/clearos/$releasever/updates-testing/$basearch/

baseurl=http://mirror1-newyork.clearos.com/clearos/$releasever/updates-testing/$basearch/

#mirrorlist=http://mirrorlist.clearos.com/clearos/mirrorlist/clearos-current-updates-testing-$releasever

enabled=0

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ClearOS-Testing-$releasever



[clearos-infra]

name=ClearOS $releasever - $basearch - Infrastructure

#baseurl=http://mirror.clearos.com/clearos/$releasever/infra/$basearch/

baseurl=http://mirror1-newyork.clearos.com/clearos/$releasever/infra/$basearch/

#mirrorlist=http://mirrorlist.clearos.com/clearos/mirrorlist/clearos-current-infra-$releasever

enabled=1

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ClearOS-$releasever



[clearos-infra-testing]

name=ClearOS $releasever - $basearch - Infrastructure (Testing)

#baseurl=http://mirror.clearos.com/clearos/$releasever/infra-testing/$basearch/

baseurl=http://mirror1-newyork.clearos.com/clearos/$releasever/infra-testing/$basearch/

#mirrorlist=http://mirrorlist.clearos.com/clearos/mirrorlist/clearos-current-infra-testing-$releasever

enabled=0

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ClearOS-Testing-$releasever



[clearos-contribs]

name=ClearOS $releasever - $basearch - Contribs

#baseurl=http://mirror.clearos.com/clearos/$releasever/contribs/$basearch/

baseurl=http://mirror1-newyork.clearos.com/clearos/$releasever/contribs/$basearch/

#mirrorlist=http://mirrorlist.clearos.com/clearos/mirrorlist/clearos-current-contribs-$releasever

enabled=1

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ClearOS-$releasever



[clearos-contribs-testing]

name=ClearOS $releasever - $basearch - Contribs (Testing)

#baseurl=http://mirror.clearos.com/clearos/$releasever/contribs-testing/$basearch/

baseurl=http://mirror1-newyork.clearos.com/clearos/$releasever/contribs-testing/$basearch/

#mirrorlist=http://mirrorlist.clearos.com/clearos/mirrorlist/clearos-current-contribs-testing-$releasever

enabled=0

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ClearOS-Testing-$releasever

Mirrors down?

[root@server certificate_manager.d]# yum clean all

Loaded plugins: clearcenter-marketplace, fastestmirror

ClearCenter Marketplace: fetching repositories...

Cleaning repos: clearos clearos-centos-sclo-rh clearos-centos-verified

              : clearos-contribs clearos-epel-verified clearos-fast-updates

              : clearos-infra clearos-verified libreswan private-clearcenter-ad

              : private-clearcenter-antimalware private-clearcenter-antispam

              : private-clearcenter-business private-clearcenter-content-filter

              : private-clearcenter-dyndns private-clearcenter-dynvpn

              : private-clearcenter-ids private-clearcenter-master-slave

              : private-clearcenter-rbs private-clearcenter-security-audit

              : private-clearcenter-verified-updates private-clearcenter-wpad

Cleaning up everything

Cleaning up list of fastest mirrors

[root@server certificate_manager.d]# yum --enablerepo=clearos-updates-testing,clearos-contribs-testing install app-lets-encrypt

Loaded plugins: clearcenter-marketplace, fastestmirror

ClearCenter Marketplace: fetching repositories...

Could not retrieve mirrorlist http://mirrorlist.clearos.com/clearos/mirrorlist/clearos-current-os-7 error was

14: curl#7 - "Failed connect to mirrorlist.clearos.com:80; No route to host"





 One of the configured repositories failed (Unknown),

 and yum doesn't have enough cached data to continue. At this point the only

 safe thing yum can do is fail. There are a few ways to work "fix" this:



     1. Contact the upstream for the repository and get them to fix the problem.



     2. Reconfigure the baseurl/etc. for the repository, to point to a working

        upstream. This is most often useful if you are using a newer

        distribution release than is supported by the repository (and the

        packages for the previous distribution release still work).



     3. Run the command with the repository temporarily disabled

            yum --disablerepo=<repoid> ...



     4. Disable the repository permanently, so yum won't use it by default. Yum

        will then just ignore the repository until you permanently enable it

        again or use --enablerepo for temporary usage:



            yum-config-manager --disable <repoid>

        or

            subscription-manager repos --disable=<repoid>



     5. Configure the failing repository to be skipped, if it is unavailable.

        Note that yum will try to contact the repo. when it runs most commands,

        so will have to try and fail each time (and thus. yum will be be much

        slower). If it is a very temporary problem though, this is often a nice

        compromise:



            yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true



Cannot find a valid baseurl for repo: clearos/7

I'm feeling adventurous as I'm already using LetsEncrypt and I have my cron job running in cron.daily.

Do I just need to make the cron job restart httpd?

Hi Fargo2,

Thanks for the update... much appreciated! Just to let everyone know, the Let's Encrypt app is coming with the ClearOS 7.4 release (we're staging this release right now). You can install the app right now if you are feeling a bit adventurous:

yum --enablerepo=clearos-updates-testing,clearos-contribs-testing install app-lets-encrypt

The only missing piece is the renewal cronjob/logging. Everything else in the app is ready to go.

You should know that the ClearOS app works alongside the certbot command line tool. In other words, if you have already created certificates with certbot, the app will happily show the certificates in the ClearOS web interface (and also make the certificates available in the Certificate Manager).