Just as I thought I’d got Postfix and Dovecot woring at last.
I installed Thunderbird on my workstation and tried to send mail. It just sat there for ages and then times out.
I get this in Maillog
I checked. That file does contain a valid key. Could it be permissions?
Your log says: “…:fopen:No such file or directory…” So its not permissions.
As far as I remember, for security reasons, postfix does not accept symlinks to certificates.
With letsencrypt, the path to the certificate is a symlink. Because of that, after each update from
certbot, on my mail server, I copy the certificate to a location below /etc/pki/certs/. You can do that by configuring a post-update hook in certbot(letsencrypt).
How?
First, do the copy manually and adjust your postfix config just to make shure that it is actually the reson. If postfix works with the copied cert, then do the folleowing:
Edit /etc/letsencrypt/renewal/yourDomain.conf and add a line in the section [renewalparams]
renew_hook = /usr/local/libexec/ledeployhook
Then create a script named /usr/local/libexec/ledeployhook which should look similar to this:
#!/bin/bash
(
CDIR=/etc/letsencrypt/live
echo executing leposthook at `date`
env | grep RENEW
for d in ${RENEWED_DOMAINS} ; do
case "$d" in
myDomain.com)
echo "Deploying new postfix certificates"
cp $RENEWED_LINEAGE/privkey.pem /etc/pki/tls/private/myDomain.com.pem
cp $RENEWED_LINEAGE/cert.pem /etc/pki/tls/certs/myDomain.com.pem
cp $RENEWED_LINEAGE/chain.pem /etc/pki/tls/certs/myDomain.com-chain.pem
cp $RENEWED_LINEAGE/fullchain.pem /etc/pki/tls/certs/myDomain.com-fullchain.pem
/usr/bin/systemctl try-reload-or-restart postfix.service
;;
*)
echo "No post deploy actions"
esac
done
echo reloading httpd
/usr/bin/systemctl try-reload-or-restart httpd.service
) >> /var/log/letsencrypt/dh.out.log 2>> /var/log/letsencrypt/dh.err.log
Create /var/log/letsencrypt/ if it does not exist and make the script executable.
Now what have I done wrong (or what did the writer of the ‘How-To’ get wrong?
Linuxbabe. Postfix for CentOS. Of all the ‘how-to’ I’ve looked at, his seem to be the best. I found a couple of errors in his Dovecot how-to, but they SEEM to be sorted.
My linux skills are not good. You say “first do the copy manually to test,” but you didn’t specify copy what to where.
Please elaborate. If it works, I can probably manage the script
Then change the path in you postfix config from /etc/letsencrypt/live/hermes.myDomain.com/fullchain.pem to /etc/pki/tls/certs/myDomain.com-fullchain.pem and restart postfix.
Of course instead of naming it myDomain-fullchain.pem you can choose whatever you like. You jus must make shure that the name is the same in your postfix-config and the letsencrypt deplyoy-hook-script.
The biggest question is, were the letsencrypt certificates actually generated in the first place? Was certbot ran to generate them?
Provide a directory listing for /etc/letsencrypt/live to see if the directory for the domain exists, and then do a directory listing for /etc/letsencrypt/live/hermes.myDomain.com so we can see if this directory contains symlinks to /etc/letsencrypt/archive and the certificate files within them.
Providing the certificate files exist, then Apache should see them.
They exist ussually in /etc/letsencrypt/live/domainname/ AND those are symlinks to numbered files in …/…/archive/domainname/
As far as I remember (configured it a year ago on Fedora), contrary to apache, postfix does not allow symlinks as certificates. Hence the copy. (Also this helps with selinux, because the hierarchy below /etc/letsencrypt is usually not labelled properly)
Never had problems with postfix and symlinks and I use letsencrypt with postfix for many years now. I would expect more issues though with selinux if the contexts do not allow access to the certificates in that particular directory for postifx.
Copied the files, changed the line in main.mc, restarted Postfix, status OK
Tried to send mail from Thunderbird - got a message cnnection timed out.
Here’s the log from when I restarted Postfix
Sep 8 12:57:12 hermes postfix/master[35681]: daemon started -- version 3.5.8, configuration /etc/postfix
Sep 8 12:57:42 hermes dovecot[1652]: pop3-login: Disconnected: Disconnected: Too many bad commands (no auth attempts in 0 secs): user=<>, rip=192.168.0.2, lip=192.168.0.216, session=<Oz93TCjoYujAqAAC>
Sep 8 12:59:02 hermes postfix/smtpd[35814]: warning: cannot get RSA private key from file "/etc/letsencrypt/live/myDomain.com/privkey.pem": disabling TLS support
Sep 8 12:59:02 hermes postfix/smtpd[35814]: warning: TLS library problem: error:02001002:system library:fopen:No such file or directory:crypto/bio/bss_file.c:288:fopen('/etc/letsencrypt/live/myDomain.com/privkey.pem','r'):
Sep 8 12:59:02 hermes postfix/smtpd[35814]: warning: TLS library problem: error:20074002:BIO routines:file_ctrl:system lib:crypto/bio/bss_file.c:290:
Sep 8 12:59:02 hermes postfix/smtpd[35814]: warning: TLS library problem: error:140B0002:SSL routines:SSL_CTX_use_PrivateKey_file:system lib:ssl/ssl_rsa.c:521:
Sep 8 12:59:08 hermes postfix/smtpd[35814]: connect from main.corp.myDomain.com[192.168.0.2]
Sep 8 12:59:08 hermes postfix/smtpd[35814]: discarding EHLO keywords: CHUNKING
Sep 8 12:59:08 hermes postfix/smtpd[35814]: lost connection after STARTTLS from main.corp.myDomain.com[192.168.0.2]
There is NO certificate for myDomain.com. it’s hosted in Canada and they don’t support Let’s Encrypt, so I guess the inly way I’ll be able to get it to work is without using STARTTLS (it works fine then and mails go through because I have an SPF and DMARC record).
I have three alternatives:
(a) Stay with GW 7
(b) use postfix without TLS
(c) change hosting providers.
I’m sort of looking at (b), but how is Dovecot going to react without TLS?
Now you have a different error. There are TWO files. The error NOW is mentioning the private key part. So you do something similar with that (copying it) …
With or without the .office - whatever you like - its only a filename. As I said before, you just make shure that the postfix configuration has the correct file path. Just look in /etc/postfix/main.cf (or use the postconf command as shown in your HowTo)
You postfix has two config variables that specify the path to your certificate and the corresponding private key. In your HowTo, those wer set by these commands:
Whatever your files path are, just make shure, that these two config vars correspont to your real environment. So if you have the two files in /etc/foo/bar.pem and /etc/foo/baz.pem then those two
config vars obviously shoul reflect that. It has nothing to do what the actual domain in the cert is.
… it’s hosted in Canada and they don’t support Let’s Encrypt,
Not true, obviously.
They might not “support” it - regarding answering of customer support requests, but ince it only relies on https and domain ownership there ist nothing special that would not work with any provider. If it would not work, you would not be able to obtain the certificate in the first place.
Wow! I did that, restarted Postfix and whaddya know? IT WORKS!
A 1,000 x thanks for the help from all concerned,
Now. Is this going to affect Dovecot? I’ve got my GW 7 server on priotity 0 and this one on priority 5. Now I know Postfix is happy.
The only way I can test Dovecot is to bring down my GW 7 server and I can’t do that until the weekend. My daughter is looking for a job (her last company closed because of Covid) and she’s getting emails from the VDAB and recruitment agencies.
There’s a ton of emails I need to transfer from GW to Hermes. I think imapsync may well do the job, but I have questions about that. They can wait until we have Dovecot working. I can start working on it on Saturday and hopefully it will be working by Monday. (I did say hopefully!)
I think we can say that this is a SUCCESS and when I have problems with Dovecot, I’ll open a new thread.
First, do the copy manually and adjust your postfix config just to make shure that it is actually the reson. If postfix works with the copied cert, then do the folleowing:
Edit /etc/letsencrypt/renewal/yourDomain.conf and add a line in the section [renewalparams]
renew_hook = /usr/local/libexec/ledeployhook
Then create a script named /usr/local/libexec/ledeployhook which should look similar to this:
#!/bin/bash
(
CDIR=/etc/letsencrypt/live
echo executing leposthook at `date`
env | grep RENEW
for d in ${RENEWED_DOMAINS} ; do
case "$d" in
myDomain.com)
echo "Deploying new postfix certificates"
cp $RENEWED_LINEAGE/privkey.pem /etc/pki/tls/private/myDomain.com.pem
cp $RENEWED_LINEAGE/cert.pem /etc/pki/tls/certs/myDomain.com.pem
cp $RENEWED_LINEAGE/chain.pem /etc/pki/tls/certs/myDomain.com-chain.pem
cp $RENEWED_LINEAGE/fullchain.pem /etc/pki/tls/certs/myDomain.com-fullchain.pem
/usr/bin/systemctl try-reload-or-restart postfix.service
;;
*)
echo "No post deploy actions"
esac
done
echo reloading httpd
/usr/bin/systemctl try-reload-or-restart httpd.service
) >> /var/log/letsencrypt/dh.out.log 2>> /var/log/letsencrypt/dh.err.log
Create /var/log/letsencrypt/ if it does not exist and make the script executable.
Before i finish up on this, let me clarify where I ned to put the script file I just created?
Now. Is this going to affect Dovecot? I’ve got my GW 7 server on priotity 0 and this one on priority 5. Now I know Postfix is happy.
It might. I dont have any experience with DoveCot or GroupWise. I’m using cyrus. Most likely, DoveCot has similar certificate variables in it’s config. But regarding simultaneously running DoveCot and GroupWise, this should not be a problem at all as long as they are running on different machines. Why would you need to shutdown your GW in order to test DoveCot? It’s running on a different host, does it?
I don’t follow. GW 7 is running on a VMWare ESX 6 virtual machine the server name is tsgw1
The new machine we just sorted is also running on a VMWare 6 virtual machine. The only difference is this one runs on linux, has a name of hermes. The IP addresses are also different of course.
If I bring down GW and Dovecot needs work and mail isn’t getting delivered, and these job offers aren’t valid for long. If you don’t respond right away, you go to the bottom of the queue. She’s a VMWare specialist.
Clarifications:
2. … in the section [renewalparams] - meaning below according to ini-file syntax.
3. /usr/local/libexec/ledeployhook (create directory if it does not yet exist).
