The main advantage I can see is if you use Outlook which comes up with an SMTP and IMAP certificate warning every time you start it with a self-signed certificate. The warnings only go away when you have a fully verified certificate.

Other reasons are:
- Let's Encrypt is a more secure certificate (2048bit/sha256 vs 1024bit/sha1 (although that is an old 6.x certificate)).
- Email clients do not need you to accept the certificate when setting up.

Beyond that I am not too sure, but I'm not a security expert. I don't know if having a more secure certificate means your e-mail exchanges are more secure. I can also see a possible down-side. If someone is trying to attack you with a bot on a secure e-mail port the bot needs to do the extra step of accepting your certificate if it is self-signed which may stop some of them but that is speculation.

Email clients with the exception of Outlook seem to be very unpicky about the quality of the certificates. My 6.x cyrus-imap certificate expired in 2013 but the e-mail clients kept using it in 7.x without any more intervention until I started using Let's Encrypt certificates.

[edit]
ClearOS 7.x cyrus-imapd certificates are 2048bit/sha256 but expired one year after installation.
Postxix certificates are also 2048bit/sha256 but are valid for 10 years.
These are the same as Let's Encrypt so no more secure.
[/edit]

Nick your the man, thanks ! I really need to stop bye more often twitter is starting to annoy me

Nick Howitt wrote:

For e-mail apps please see this HowTo. If you implement the certificates for any other apps, please let me know the details of how and I will add them to the HowTo and make it generic rather than just for mail apps.

Hi Nick,

what is the advantage of using SSL certificate for email ?

The update of the letsencrypt certificate doesn't work again.
Maybe due an update or something.

I'm having the same problem with "--standalone", but only i can change it anywhere now.
It looks like the "renew" scripte hase changed

/usr/clearos/apps/lets_encrypt/deploy/renew

#!/usr/clearos/sandbox/usr/bin/php

<?php



/**

 * Let's Encrypt renew wrapper.

 *

 * @category   apps

 * @package    lets-encrypt

 * @subpackage scripts

 * @author     eGloo <developer@egloo.ca>

 * @copyright  2017 Marc Laporte

 * @license    http://www.gnu.org/copyleft/gpl.html GNU General Public License version 3 or later

 * @link       https://github.com/WikiSuite/app-lets-encrypt

 */



///////////////////////////////////////////////////////////////////////////////

//

// This program is free software: you can redistribute it and/or modify

// it under the terms of the GNU General Public License as published by

// the Free Software Foundation, either version 3 of the License, or

// (at your option) any later version.

//

// This program is distributed in the hope that it will be useful,

// but WITHOUT ANY WARRANTY; without even the implied warranty of

// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

// GNU General Public License for more details.

//

// You should have received a copy of the GNU General Public License

// along with this program.  If not, see <http://www.gnu.org/licenses/>;.

//

///////////////////////////////////////////////////////////////////////////////



///////////////////////////////////////////////////////////////////////////////

// B O O T S T R A P

///////////////////////////////////////////////////////////////////////////////



$bootstrap = getenv('CLEAROS_BOOTSTRAP') ? getenv('CLEAROS_BOOTSTRAP') : '/usr/clearos/framework/shared';

require_once $bootstrap . '/bootstrap.php';



///////////////////////////////////////////////////////////////////////////////

// D E P E N D E N C I E S

///////////////////////////////////////////////////////////////////////////////



use \clearos\apps\lets_encrypt\Lets_Encrypt as Lets_Encrypt;

clearos_load_library('lets_encrypt/Lets_Encrypt');



///////////////////////////////////////////////////////////////////////////////

// M A I N

///////////////////////////////////////////////////////////////////////////////



$le = new Lets_Encrypt();

$le->renew(TRUE);

SSL can also be used to do: DomainKeys Identified Mail (DKIM): https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

You also don’t need to run you own CA for this, nor do you have to buy a certificate from one of the major Certificate Authorities.

Hi Philippe,
They serve very different purposes. Using ssl for pop/imap/smtp secures the transaction between you and the server. Using an external (including Let's Encrypt) has some advantages but probably not many unless you use Outlook.
DKIM is a way for the recipient to confirm that the domain of the sender's e-mail address really has come from that domain.

BTW, did you see my DKIM howto?

Nick Howitt wrote:

Hi Philippe,
They serve very different purposes. Using ssl for pop/imap/smtp secures the transaction between you and the server. Using an external (including Let's Encrypt) has some advantages but probably not many unless you use Outlook.
DKIM is a way for the recipient to confirm that the domain of the sender's e-mail address really has come from that domain.

BTW, did you see my DKIM howto?

Your are right not exactly SSL, in regards to your HOWTO, I did thank you though I could not get:

dig -t any YYYYMM_domainkey.mydomain.com

to work. Sorry for diluting this thread.

Philippe Eveleigh wrote:
in regards to your HOWTO, I did thank you though I could not get:

dig -t any YYYYMM_domainkey.mydomain.com

to work. Sorry for diluting this thread.

Typo on my side. It should read:

dig -t any YYYYMM._domainkey.mydomain.com

A "." after YYYYMM. I'll correct the HowTo. Thanks for pointing it out.

Nick Howitt wrote:

Philippe Eveleigh wrote:
in regards to your HOWTO, I did thank you though I could not get:

dig -t any YYYYMM_domainkey.mydomain.com

to work. Sorry for diluting this thread.

Typo on my side. It should read:

dig -t any YYYYMM._domainkey.mydomain.com

A "." after YYYYMM. I'll correct the HowTo. Thanks for pointing it out.

Your welcome but I should have been more precised, I can only make it work with the following cmd:

dig -t txt YYYYMM._domainkey.mydomain.com

Nick Howitt wrote:

Yes I think that is the problem. In that solution, each time the certificates were copied to a new location and then the application config files were pointed to the new location. These files are not being updated when the certificates renew. Now we just link directly to the certificates in /etc/letsencrypt/live. You have to be careful to choose the right certificate (either the cert + chain, or just the fullchain). Have a look at the howto for the mail apps. Alternatively, if you can locate the certificates you've linked to, you can delete them and then create symlinks of the same name pointing to the Let's Encrypt live certificates (which are themselves symlinks pointing to the latest certificates but this is managed by certbot). Also note the group ownership bits from the HowTo.

For Apache and the webconfig, if you can undo the conf file edits, you can directly use the webconfig to use the Let's Encrypt certificates.

Hello Nick,

I hope you can help further with this.
I'm confused what must be the exact location of the certificate files.

I've have to following setup (changes).

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

#   Server Certificate:

#SSLCertificateFile /etc/pki/tls/certs/localhost.crt

SSLCertificateFile /etc/letsencrypt/live/pdebrabander.nl/cert.pem



#   Server Private Key:



#SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

SSLCertificateKeyFile /etc/letsencrypt/live/pdebrabander.nl/privkey.pem



#   Server Certificate Chain:

#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt

SSLCertificateChainFile /etc/letsencrypt/live/pdebrabander.nl/chain.pem

/etc/httpd/conf.d/flex-443.conf

<VirtualHost *:443>

	ServerName pdebrabander.nl

	DocumentRoot /var/www/html

	ErrorLog /var/log/httpd/error_log

	CustomLog /var/log/httpd/access_log combined

	SSLEngine on

	SSLCertificateFile /etc/letsencrypt/live/pdebrabander.nl/cert.pem

	SSLCertificateKeyFile /etc/letsencrypt/live/pdebrabander.nl/privkey.pem

	SSLCertificateChainFile /etc/letsencrypt/live/pdebrabander.nl/chain.pem

#	SSLCertificateFile /etc/clearos/certificate_manager.d/LetsEncrypt.crt

#	SSLCertificateKeyFile /etc/clearos/certificate_manager.d/LetsEncrypt.key

#	SSLCertificateChainFile /etc/clearos/certificate_manager.d/LetsEncrypt.intermediate

	# No weak export crypto allowed

	SSLHonorCipherOrder on

	SSLProtocol all -SSLv2 -SSLv3 -TLSv1

	SSLCipherSuite ECDH+AESGCMH+AESGCM:ECDH+AES256H+AES256:ECDH+AES128H+AES:ECDH+3DESH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!3DES:!aNULL:!MD5

	SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0

</VirtualHost>

/usr/clearos/sandbox/etc/httpd/conf.d/certs.conf

SSLCertificateFile /etc/letsencrypt/live/pdebrabander.nl/cert.pem

SSLCertificateKeyFile /etc/letsencrypt/live/pdebrabander.nl/privkey.pem

SSLCertificateChainFile /etc/letsencrypt/live/pdebrabander.nl/chain.pem

what should be correct location where the app is putting the new certificate files ?

Yes I think that is the problem. In that solution, each time the certificates were copied to a new location and then the application config files were pointed to the new location. These files are not being updated when the certificates renew. Now we just link directly to the certificates in /etc/letsencrypt/live. You have to be careful to choose the right certificate (either the cert + chain, or just the fullchain). Have a look at the howto for the mail apps. Alternatively, if you can locate the certificates you've linked to, you can delete them and then create symlinks of the same name pointing to the Let's Encrypt live certificates (which are themselves symlinks pointing to the latest certificates but this is managed by certbot). Also note the group ownership bits from the HowTo.

For Apache and the webconfig, if you can undo the conf file edits, you can directly use the webconfig to use the Let's Encrypt certificates.

Hi,

I see this every day in letsencrypt.log

2018-03-04 03:15:02,394EBUG:certbot.main:certbot version: 0.21.1

2018-03-04 03:15:02,394EBUG:certbot.main:Arguments: ['--standalone', '--max-log-backups', '200', '--preferred-challenges', 'http-01', '--renew-hook', '/sbin/trigger lets_encrypt']

2018-03-04 03:15:02,394EBUG:certbot.mainiscovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)

2018-03-04 03:15:02,410EBUG:certbot.log:Root logging level set at 20

2018-03-04 03:15:02,410:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log

2018-03-04 03:15:02,425:WARNING:certbot.renewal:An error occurred while parsing /etc/letsencrypt/renewal/pdebrabander.nl.conf. The error was Too many flags setting configurators/installers/authenticators 'webroot' -> 'standalone'. Skipping the file.

2018-03-04 03:15:02,427EBUG:certbot.renewal:Traceback was:

Traceback (most recent call last):

  File "/usr/lib/python2.7/site-packages/certbot/renewal.py", line 78, in _reconstitute

    restore_required_config_elements(config, renewalparams)

  File "/usr/lib/python2.7/site-packages/certbot/renewal.py", line 174, in restore_required_config_elements

    if item_name in renewalparams and not cli.set_by_cli(item_name):

  File "/usr/lib/python2.7/site-packages/certbot/cli.py", line 209, in set_by_cli

    plugin_selection.cli_plugin_requests(detector))

  File "/usr/lib/python2.7/site-packages/certbot/plugins/selection.py", line 241, in cli_plugin_requests

    req_auth = set_configurator(req_auth, "standalone")

  File "/usr/lib/python2.7/site-packages/certbot/plugins/selection.py", line 219, in set_configurator

    raise errors.PluginSelectionError(msg.format(repr(previously), repr(now)))

PluginSelectionError: Too many flags setting configurators/installers/authenticators 'webroot' -> 'standalone'



2018-03-04 03:15:02,427EBUG:certbot.log:Exiting abnormally:

Traceback (most recent call last):

  File "/usr/bin/certbot", line 9, in <module>

    load_entry_point('certbot==0.21.1', 'console_scripts', 'certbot')()

  File "/usr/lib/python2.7/site-packages/certbot/main.py", line 1240, in main

    return config.func(config, plugins)

  File "/usr/lib/python2.7/site-packages/certbot/main.py", line 1142, in renew

    renewal.handle_renewal_request(config)

  File "/usr/lib/python2.7/site-packages/certbot/renewal.py", line 443, in handle_renewal_request

    len(renew_failures), len(parse_failures)))

Error: 0 renew failure(s), 1 parse failure(s)

What does it mean and how to resolve this ?

Mine won't try to renew for a while with the new process so I don't know what to expect.

The log looks like it is complaining at the contents of /etc/letsencrypt/renewal/pdebrabander.nl.conf, so what is in it? At a guess you may want to munge your account number. Is there anything obviously wrong in the "[[webroot_map]]" section?

Can you also confirm you have tcp port 80 open?

Nick Howitt wrote:

Mine won't try to renew for a while with the new process so I don't know what to expect.

The log looks like it is complaining at the contents of /etc/letsencrypt/renewal/pdebrabander.nl.conf, so what is in it? At a guess you may want to munge your account number. Is there anything obviously wrong in the "[[webroot_map]]" section?

Can you also confirm you have tcp port 80 open?

Port 80 is open.
I'm using letsencrypt for a while now and starting from 05-febr. the logfiles are filled with this error (i think after the last renewal)

.conf file:

# renew_before_expiry = 30 days

version = 0.21.0

cert = /etc/letsencrypt/live/pdebrabander.nl/cert.pem

privkey = /etc/letsencrypt/live/pdebrabander.nl/privkey.pem

chain = /etc/letsencrypt/live/pdebrabander.nl/chain.pem

fullchain = /etc/letsencrypt/live/pdebrabander.nl/fullchain.pem

archive_dir = /etc/letsencrypt/archive/pdebrabander.nl



# Options used in the renewal process

[renewalparams]

authenticator = webroot

installer = None

account = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

server = https://acme-v01.api.letsencrypt.org/directory

webroot_path = /var/www/html,

renew_hook = /sbin/trigger lets_encrypt

pref_challs = http-01,

[[webroot_map]]

pdebrabander.nl = /var/www/html

www.pdebrabander.nl = /var/www/html

EDIT:

Can the cli.ini the problem ?

# Uncomment and update to generate certificates for the specified

# domains.

domains = pdebrabander.nl, www.pdebrabander.nl



# Uncomment to use the webroot authenticator. Replace webroot-path with the

# path to the public_html / webroot folder being served by your web server.

authenticator = webroot

webroot-path = /var/www/html



# Uncomment to use the standalone authenticator on port 443

server = https://acme-v01.api.letsencrypt.org/directory



# Uncomment to use a text interface instead of ncurses

text = True



# Uncomment and update to register with the specified e-mail address

email = xxxxxx@xxxxxxxxxxx.nl



agree-tos = True

renew-by-default = True

This is a old configuration file (11-12-2016), setup when I stated to use letsencrypt.


How can i run a manual update of the certificate as per webconfig ?

Digging further, I think there is a problem in the renewal command. Can you try editing /usr/clearos/apps/lets_encrypt/deploy/renew and change:

RESULT=`certbot renew --standalone --max-log-backups $MAX_LOGS --preferred-challenges http-01 --renew-hook "/sbin/trigger lets_encrypt" >/var/clearos/lets_encrypt/renew.log 2>&1`

to

RESULT=`certbot renew --max-log-backups $MAX_LOGS --preferred-challenges http-01 --renew-hook "/sbin/trigger lets_encrypt" >/var/clearos/lets_encrypt/renew.log 2>&1`

so removing the "--standalone" switch, then run the command:

/etc/cron.d/app-lets-encrypt

.... and digging even further, running the cron.d job would probably also work without any modifications if you stop the web server.

Nick Howitt wrote:

Digging further, I think there is a problem in the renewal command. Can you try editing /usr/clearos/apps/lets_encrypt/deploy/renew and change:

RESULT=`certbot renew --standalone --max-log-backups $MAX_LOGS --preferred-challenges http-01 --renew-hook "/sbin/trigger lets_encrypt" >/var/clearos/lets_encrypt/renew.log 2>&1`

to

RESULT=`certbot renew --max-log-backups $MAX_LOGS --preferred-challenges http-01 --renew-hook "/sbin/trigger lets_encrypt" >/var/clearos/lets_encrypt/renew.log 2>&1`

so removing the "--standalone" switch, then run the command:

/etc/cron.d/app-lets-encrypt

This did the trick !!
Thanks for your help, Nick.

Is this now save if there will be an update of the app ?

You've now got 2 months until you require an update to the app.

I like the idea behind the change, if intentional, as it removes the requirement to have a configured and running web server. Unfortunately it then breaks if you do have one, so somehow it needs to detect your set up. I've filed a bug with WikiSuite and I also have a follow up question for the devs as there may be a further issue.

Nick Howitt wrote:

You've now got 2 months until you require an update to the app.

I like the idea behind the change, if intentional, as it removes the requirement to have a configured and running web server. Unfortunately it then breaks if you do have one, so somehow it needs to detect your set up. I've filed a bug with WikiSuite and I also have a follow up question for the devs as there may be a further issue.

I leave it as it is for the moment.
My webserver went down after trying to get things setup correctly and did not startup anymore.

I think when i installed letsencrypt manually over a year ago, some paths are setup differently are got broken.
Web server is running again and i will check it another day again.

Nick Howitt wrote:
When the app was updated I was able to force an update by removing the validity check in the PHP code and adding the --force-renewal to the renew line and it worked OK and this morning I was able to create a new certificate.

How did you force the renewal ?

Somehow my app-letsencrypt is not setup correctly with the app (i think).

------------
update

Could it be that the changes i'd made for the external-letsencrypt over a year a go could break the app ?

LINK

The update that was pushed through around 08 March took out the script and moved the renewal mechanism into PHP code which I fand hard to read. It has also changed the renewal mechanism to use the --standalone mode which means you do not have to have a web server running. In fact it will shut down the web server as it runs. It also does a validity first and only attempts a renewal if necessary.

If you renewed you certificates recently, they won't need renewal yet. What is making you say the renewal is not working again?

When the app was updated I was able to force an update by removing the validity check in the PHP code and adding the --force-renewal to the renew line and it worked OK and this morning I was able to create a new certificate.

Those settings look fine and are working OK for apache. I don't think your photo comes from Holland but I get no security errors viewing the site with https. Checking the padlock icon in Firefox I see your certificate was renewed yesterday and is valid to 15/06. Did you manually renew that?

In which app are you seeing the certificate errors?

Nick Howitt wrote:

Those settings look fine and are working OK for apache. I don't think your photo comes from Holland but I get no security errors viewing the site with https. Checking the padlock icon in Firefox I see your certificate was renewed yesterday and is valid to 15/06. Did you manually renew that?

In which app are you seeing the certificate errors?

The photo is Momument Valley is the US ;-)

I've removed the old manual added certificate and check every setting as far as possible. (https://ipaddress:81/app/certificate_manager)
No external addresses any more here
The renewal is this the manually renewal of the certificates, because i cannot update the certificate with the app.
It is still gives the --standalone error. So i can not test whether the update by the app is working.

I agree with youthat every looks correct, but i can not thest if the app configuration is working now.

I had a hack a couple of weeks ago for testing and this is what I think I did. Edit /usr/clearos/apps/lets_encrypt/libraries/Lets_Encrypt.php. Comment out lines around 449 - 452 - the ones containing:

        if (!$this->renew_required()) {

            clearos_log('lets_encrypt', lang('lets_encrypt_renew_not_required'));

            return;

        }

My line numbers may be slightly out as I've applied a logging fix. Change line 469 or thereabouts to:

'renew --standalone --force-renew ' .

Then you can run /etc/cron.d/app-lets-encrypt and it should renew your certificate whatever. Obviously do it for testing only otherwise it will renew your certificate every night.

Nick Howitt wrote:

I had a hack a couple of weeks ago for testing and this is what I think I did. Edit /usr/clearos/apps/lets_encrypt/libraries/Lets_Encrypt.php. Comment out lines around 449 - 452 - the ones containing:

        if (!$this->renew_required()) {

            clearos_log('lets_encrypt', lang('lets_encrypt_renew_not_required'));

            return;

        }

My line numbers may be slightly out as I've applied a logging fix. Change line 469 or thereabouts to:

'renew --standalone --force-renew ' .

Then you can run /etc/cron.d/app-lets-encrypt and it should renew your certificate whatever. Obviously do it for testing only otherwise it will renew your certificate every night.

Unfortunately not succes with the renewal

2018-03-19 19:01:57,904EBUG:certbot.main:certbot version: 0.21.1

2018-03-19 19:01:57,904EBUG:certbot.main:Arguments: ['--standalone', '--force-renew', '--max-log-backups', '200', '--preferred-challenges', 'http-01', '--renew-hook', '/sbin/trigger lets_encrypt']

2018-03-19 19:01:57,904EBUG:certbot.mainiscovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)

2018-03-19 19:01:57,919EBUG:certbot.log:Root logging level set at 20

2018-03-19 19:01:57,919:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log

2018-03-19 19:01:57,921:WARNING:certbot.storage:Attempting to parse the version 0.22.0 renewal configuration file found at /etc/letsencrypt/renewal/pdebrabander.nl.conf with version 0.21.1 of Certbot. This might not work.

2018-03-19 19:01:57,935:WARNING:certbot.renewal:An error occurred while parsing /etc/letsencrypt/renewal/pdebrabander.nl.conf. The error was Too many flags setting configurators/installers/authenticators 'webroot' -> 'standalone'. Skipping the file.

2018-03-19 19:01:57,936EBUG:certbot.renewal:Traceback was:

Traceback (most recent call last):

  File "/usr/lib/python2.7/site-packages/certbot/renewal.py", line 78, in _reconstitute

    restore_required_config_elements(config, renewalparams)

  File "/usr/lib/python2.7/site-packages/certbot/renewal.py", line 174, in restore_required_config_elements

    if item_name in renewalparams and not cli.set_by_cli(item_name):

  File "/usr/lib/python2.7/site-packages/certbot/cli.py", line 209, in set_by_cli

    plugin_selection.cli_plugin_requests(detector))

  File "/usr/lib/python2.7/site-packages/certbot/plugins/selection.py", line 241, in cli_plugin_requests

    req_auth = set_configurator(req_auth, "standalone")

  File "/usr/lib/python2.7/site-packages/certbot/plugins/selection.py", line 219, in set_configurator

    raise errors.PluginSelectionError(msg.format(repr(previously), repr(now)))

PluginSelectionError: Too many flags setting configurators/installers/authenticators 'webroot' -> 'standalone'

I think i've found the problem.
After search the web i've found this : LINK

I've deleted /etc/letsencrypt/cli.ini and then renewed letsencrypt and the certificates were updated.

Great. That is one of the issues with a "legacy" set up when it becomes mainstream. Luckily for me I kept very close to the method that was adopted by ClearOS and it worked "out of the tin".

I've got Let's Encrypt working except for app-owncloud.
I don't see anything here on that.
Looking for some guidance.

Bryan,

Probably better to start a new post...this one has been 'asked and answered' with an accepted answer.

OwnCloud uses the standard Apache engine. I'm assuming you're just wondering why https://example.com/owncloud isn't using the LetsEncrypt certificates? You can do this by installing the 'Web Server' app from the Marketplace and then configuring to select your certs.

B.