This is a follow-up.

I also get connection timeout when I try to telnet to port 25 just to see if something is listening.

OK so as I dug in to it, turns out my IMAP service was stopped. The problem is I cannot START it. When I try on the webpanel, it just returns to a stopped state with no error message about why it won't start.

Another follow up:

I uninstalled letsencrypt and deleted the changes made when following the instructions. Only then was I able to start the mail server. There is some problem with the recipe for using Let's Encrypt to provide secure access to SMTP/IMAP.

I will update here if I can get a working lets encrypt

K

For error messages you generally need to check the messages and maillog files. You can also do "systemctl status postfix cyrus-imapd" and you sometimes see things there.

The easiest area to fall down with is skipping the certificate permissions and adding the various users to the ssl-cert group. You can check group membership with "id postfix" and "id cyrus"

Just my 2 cents. Lets Encrypt is a pain in the neck to keep functioning on a production server. I tried it on my home server, and had it working, but there's just far too much manual configuration and too many things that can break. Do a google search for inexpensive certificates from a trusted source. On my server at home, I believe I paid $30 for 2 years for a single server certificate and I have it working with Cyrus IMAP and Postfix SMTP as well as Apache web server and Webconfig.

I'm not sure I'm allowed to post URLs to the sites where the certificates are sold, but maybe an admin can chime in.

I'm afraid I have to disagree. I wrote the howto based on my implementation years ago and the howto has been updated once to copy with a change in the certbot permissions. I have never had to change my set up and never had a failure.

FWIW the app is a third party app and was only ever designed to cover the web server and webconfig. It is just that the community saw the certificates could be used further and they developed the howto. I wrote it up and tweaked it. I also then added to it for some other apps such as plex. I've been using the certificates since at least 2017, before even the app existed.

Hi Nick. What are you disagreeing with?

That it is a pain in the neck compared to a commercial certificate. You need to do almost as many changes to the commercial cert and a commercial cert needs to be regularly renewed as well. LE is set and forget.

Well okay, you've had good luck with them. When I tried them, the first time they renewed, it failed, and it had to be re-registered. As luck would have it, it failed while I was out of state, so I had a server down for a couple days. It worked the second time, with the same configuration, but I just didn't trust them after that.

On my production server at work, the certificates only need to be renewed every 3 years, and I guess I've been doing it manually so long that I don't consider it difficult. We used to run our mail servers on slackware. That took a bit more time.

If I have a minute, I'll take a look at your how-to on the subject. Always good to have another perspective.

By the way. I like the certificate app in ClearOS. I wish it worked with the various IMAP/POP and SMTP servers as well, but for what it does it works well. Mostly what I like about it, is updates don't break the configuration. That used to happen with manual configuration of config files to install certificates. Especially Apache.

Nick Howitt wrote:

That it is a pain in the neck compared to a commercial certificate. You need to do almost as many changes to the commercial cert and a commercial cert needs to be regularly renewed as well. LE is set and forget.

I have used LE for a few servers, and once configured and working my experience has been 'Set & forget'. I have access to commercial certs, but they are OS agnostic, so no automation available (AFAIK) and require manual upgrades.

I will be trying again this weekend to get this sorted. Been with ClearOS since the ancient days of Clarkconnect, so hoping I can make this work.

Axigen was a breeze to set up, but also a bear with LE- they did offer some free hand-holding though and I was able to get LE working just fine. My issue with their offering was no clear system to migrate users/messages in the backend. They have a wonderful migration tool, but every user has to login to new server to initiate migration of their data.

With my ClearOS test, I was easily able to migrate users and messages on the backend with rsync, then run cyradmin tools to clean up.

The only stumbling block for me is getting the certs. I already have go-ahead to buy a 3-year sub, but need to make sure I won't get bitten by Cert issues.

K

Be wary with commercial certificates. Standards changed in Q3 last year and most (all?) big certificate providers will now only supply you with a certificate lasting 12 or 13 months. If you buy a 3 year package, you may well still have to renew the certificate annually. I think best practices now say the certificate should only last 12 months, but 13m gives you a bit of time to renew it and get it into place before the next one expires. The big certificate providers now work to this.

Hi Nick (if you're available?)

I ran "systemctl status postfix cyrus-imapd"

and got this clue regarding the privkey.pem file:
Mar 01 15:34:19 newmail.bamfieldmsc.ca imaps[22416]: unable to get private key from '/etc/letsencrypt/live/newmail.bamfieldmsc.ca/privkey.pem'
Mar 01 15:34:19 newmail.bamfieldmsc.ca imaps[22416]: TLS server engine: cannot load cert/key data

I noticed that the "live" site files are links to files stored in:
/etc/letsencrypt/archive/newmail.bamfieldmsc.ca/

I checked to ensure permissions were identical in the folders, and I even tried full rwx permissions to no avail

cheers
Ken

Restarted email services and now when I try the command " systemctl status postfix cyrus-imapd" I get a different error:

Mar 01 17:06:47 newmail.bamfieldmsc.ca imaps[31569]: Fatal error: tls_start_servertls() failed
Mar 01 17:06:47 newmail.bamfieldmsc.ca imaps[31570]: imaps TLS negotiation failed: f12.immuniweb.com [192.175.111.233]
Mar 01 17:06:47 newmail.bamfieldmsc.ca imaps[31570]: Fatal error: tls_start_servertls() failed
Mar 01 17:06:48 newmail.bamfieldmsc.ca imaps[31571]: imaps TLS negotiation failed: f13.immuniweb.com [192.175.111.240]
Mar 01 17:06:48 newmail.bamfieldmsc.ca imaps[31571]: Fatal error: tls_start_servertls() failed
Mar 01 17:06:48 newmail.bamfieldmsc.ca imaps[31578]: imaps TLS negotiation failed: f03.immuniweb.com [64.15.129.102]
Mar 01 17:06:48 newmail.bamfieldmsc.ca imaps[31578]: Fatal error: tls_start_servertls() failed
Mar 01 17:06:48 newmail.bamfieldmsc.ca imaps[31579]: imaps TLS negotiation failed: f16.immuniweb.com [192.175.111.243]
Mar 01 17:06:48 newmail.bamfieldmsc.ca imaps[31579]: Fatal error: tls_start_servertls() failed
Mar 01 17:06:49 newmail.bamfieldmsc.ca imaps[31581]: starttls: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits new) no authentication

I guess next link in chain is now issue.

K

That was 1am for me when you posted! What is the output to:

ls -l /etc/letsencrypt

ls -l /etc/letsencrypt/archive/newmail.bamfieldmsc.ca/

grep ssl /etc/group

Nick Howitt wrote:

That was 1am for me when you posted! What is the output to:

ls -l /etc/letsencrypt

ls -l /etc/letsencrypt/archive/newmail.bamfieldmsc.ca/

grep ssl /etc/group

Hi Nick

Here is result:

[root@newmail ~]# ls -l /etc/letsencrypt/archive/newmail.bamfieldmsc.ca/
total 16
-rwxr--r-- 1 root root 1862 Mar 1 15:00 cert1.pem
-rwxr--r-- 1 root root 1586 Mar 1 15:00 chain1.pem
-rwxr--r-- 1 root root 3448 Mar 1 15:00 fullchain1.pem
-rwxr----- 1 root ssl-cert 1704 Mar 1 15:00 privkey1.pem

[root@newmail ~]# grep ssl /etc/group
ssl-cert:x:993:clearsync,postfix,cyrus

I am so close; I can migrate accounts, rsync the mail folders, and cyradm all the messages so user have access. This SSL/TLS is the final stumbling block to us making the move.

Thanks
Ken

And:

ls -l /etc/letsencrypt

The other two bits look OK.

[edit]
I'm not sure how you got execute permissions on the certs!
[/edit]

Nick Howitt wrote:

And:

ls -l /etc/letsencrypt

The other two bits look OK.

[edit]
I'm not sure how you got execute permissions on the certs!
[/edit]

Execute perms was likely me trying chmod 777 to get SOMETHING to happen ¯\_(ツ)_/¯ and not fulling restoring to original.

Result:
[root@newmail ~]# ls -l /etc/letsencrypt
total 0
drwx------ 3 root root 42 Mar 1 14:59 accounts
drwxr-x--- 3 root ssl-cert 36 Mar 1 15:00 archive
drwxr-xr-x 2 root root 62 Mar 1 15:00 csr
drwx------ 2 root root 62 Mar 1 15:00 keys
drwxr-x--- 3 root ssl-cert 50 Mar 1 15:00 live
drwxr-xr-x 2 root root 41 Mar 1 15:00 renewal
drwxr-xr-x 5 root root 43 Feb 28 04:15 renewal-hooks


I will go back an remove the perms if not needed.
K

That looks OK as well. Is postfix working OK?

What about:

grep ^tls /etc/imapd.conf

I get:

[root@server ~]# grep ^tls /etc/imapd.conf

tls_ca_file: /etc/pki/tls/certs/ca-bundle.crt

tls_key_file:    /etc/letsencrypt/live/www.howitts.co.uk/privkey.pem

tls_cert_file:   /etc/letsencrypt/live/www.howitts.co.uk/fullchain.pem

tls_ca_path:    /etc/pki/tls

Nick Howitt wrote:

That looks OK as well. Is postfix working OK?

What about:

grep ^tls /etc/imapd.conf

I get:

[root@server ~]# grep ^tls /etc/imapd.conf

tls_ca_file: /etc/pki/tls/certs/ca-bundle.crt

tls_key_file:    /etc/letsencrypt/live/www.howitts.co.uk/privkey.pem

tls_cert_file:   /etc/letsencrypt/live/www.howitts.co.uk/fullchain.pem

tls_ca_path:    /etc/pki/tls

OK so after I tried that, I saw I was missing the tls_ca_path statement. Added that to my imapd.conf and here is result:
[root@newmail etc]# grep ^tls /etc/imapd.conf
tls_cert_file: /etc/letsencrypt/live/newmail.bamfieldmsc.ca/fullchain.pem
tls_key_file: /etc/letsencrypt/live/newmail.bamfieldmsc.ca/privkey.pem
tls_ca_path: /etc/pki/tls
tls_ca_file: /etc/pki/tls/certs/ca-bundle.crt


After all that I went and tried to test email ports at https://ssl-tools.net/mailservers

When I ran my domain: bamfieldmsc.ca it keeps wanting to connect to mail3.bamfieldmsc.ca (205.250.85.209) despite the fact that days ago I changed the MX record to reflect server at 205.250.85.198/newmail.bamfieldmsc.ca is the proper MX.

I will chase that down right away as well

thanks
Ken

That is odd. My cyrus-imapd starts without tls_ca_path (which seems to be deprecated in favour of tls_client_ca_dir). Does your /etc/pki/tls/certs/ca-bundle.crt exist as a symlink to /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem and is it the path readable by anyone (I think this means you need an "r-x" in the "other" permissions of all the parent folders).

Nick Howitt wrote:

That is odd. My cyrus-imapd starts without tls_ca_path (which seems to be deprecated in favour of tls_client_ca_dir). Does your /etc/pki/tls/certs/ca-bundle.crt exist as a symlink to /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem and is it the path readable by anyone (I think this means you need an "r-x" in the "other" permissions of all the parent folders).

Yes to the links. Permissions are r-x for other.

I don't know what I borked, but now server not throwing certificate alerts to new email clients. Unfortunately it is now not accepting incoming messages. Send just fine.

I think I will have to go back to square one. There may be a DNS/MX record problem. Waiting to hear back from our DNS registrar.

K

Can you post the output to:

postconf -n

iptables -nvL INPUT

If postfix is running, these certificates should only affect sending mail and not receiving mail. They are separate things covered by different parameters (smtp_ vs smtpd_). Receiving is still on port 25 but sending on 587 to postfix (which then goes out onto the internet on 25).

Nick Howitt wrote:

Can you post the output to:

postconf -n

iptables -nvL INPUT

If postfix is running, these certificates should only affect sending mail and not receiving mail. They are separate things covered by different parameters (smtp_ vs smtpd_). Receiving is still on port 25 but sending on 587 to postfix (which then goes out onto the internet on 25).

Hi Nick. Want to thank you for the help so far!

OK to update:

I somehow lost SSH access to the server. The SSHD refuses to start via webconsole. I am not on site, but have an assistant who I asked to re-install the OS- so I am scrapping this trial and starting over.

I cannot be the only person running into this issue. This is not a custom install, and I am performing all certificate settings using the provided tools, not CLI kung-fu.

I still need certificates to work on the IMAP and SMTP ports at the end of the day. This is becoming a given for all email clients.

cheers
Ken

OK, for the record:

fresh install
email apps from marketplace
generate self-signed
generate Lets' Encrypt
Can send/receive but client apps still have to manually accept with notice "certificate untrusted localhost localdomain"
This would seem to be where my self-certs or lets encrypt is not pushing the FQDN of the server?

Have you been through the Let's Encrypt Howto to set up the e-mail packages to use your certificates? If not,they will use the self-signed ones (actually I don't think they use them either and they use the bootstrap ones). You must also make sure the your LE certificate covers the FQDN that you use for you mail server. As an example, if your domain is example.com and you use smtp.example.com for your smtp server and imap.example.com for picking up your e-mails, then your certificate will need to cover all three domains. Then, in your mail app, you need to use an FQDN from the certificate and not an IP address. Typically you will also have a DNS server entry covering all three domains/subdomains connecting them to your ClearOS LAN IP so that when you are on your LAN a local IP is served by the DNS server rather than your external IP.