Am 16.12.2018 um 22:32 schrieb Benny Pedersen via dovecot:
Alexander Dalloz skrev den 2018-12-16 21:30:
Am 16.12.2018 um 19:41 schrieb Tim Dickson:
permissions should be 644 or 444 owned by root.
The key file should even only be readable by root and not the world.
0400 would be a good
Alexander Dalloz skrev den 2018-12-16 21:30:
Am 16.12.2018 um 19:41 schrieb Tim Dickson:
permissions should be 644 or 444 owned by root.
The key file should even only be readable by root and not the world.
0400 would be a good choice.
all ssl pem files must only be readeble from root,
Tim, Daniel, Aki, all. Problem solved. Well, sort of:
It is AppArmor.
I disabled AppArmor based on another sufferer's experience, and I
quote:
https://forums.opensuse.org/showthread.php/531740-Unexpected-pe
rmissions-issue-with-Dovecot
I have made some progress on solving
Am 16.12.2018 um 19:41 schrieb Tim Dickson:
permissions should be 644 or 444 owned by root.
The key file should even only be readable by root and not the world.
0400 would be a good choice.
Alexander
permissions should be 644 or 444 owned by root.
if the permissions are too open, ssl/dovecot will refuse to load them.
you may even see a message about it if you have verbose messages/ check
your sys logs.
I had this problem once with certs that checked out fine, correct < in
dovcot config but
As a LetsEncrypt user myself, I have:
ssl_cert = So nothing further should be required. You say Dovecot fails to start -
have you tried simply executing "dovecot -F"?
Daniel
On 12/16/2018 6:19 AM, C. Andrews Lavarre wrote:
Phil hi.
Thank you for explaining what the symbol does... so it is
For what it's worth, this gives the server an A:
https://www.ssllabs.com/ssltest/analyze.html?d=mail.privustech.
com
So there is no problem with the certificates and key...
Thanks again.
On Sun, 2018-12-16 at 09:19 -0500, C. Andrews Lavarre wrote:
> So it's something else.
Phil hi.
Thank you for explaining what the symbol does... so it is like the
BASH from symbol. OK.That is new information.
So without it dovecot reads the path/to/file as if it were a hashed
cert, which of course doesn't work. So with the symbol dovecot tries to
follow the path to read the cert but
Andy,
This is just rude. You have been told multiple times that the less-than
symbol is required to read the certificate from the file. Otherwise,
the filename is parsed as if it is the certificate itself. Which yields
garbage.
If dovecot can't read that file, it is *not* dovecot's fault.
Alexander hi.
Aki caught the STARTTLS issue as well, I corrected it, but it still
doesn't work.
Enjoy your weekend. I intend to enjoy mine!
:-)
Thanks again for your time.
Andy
Forwarded Message
From: C. Andrews Lavarre
To: Aki Tuomi
Subject: Re: Upgrade to 2.3.1 has failed
Alexander, Thanks, as described before, if I include the "<" then
Dovecot fails to start at all.
Thank you again for your time. I have forwarded my latest to Aki to the
group.
Enjoy your weekend.
Best regards, Andy
On Sat, 2018-12-15 at 23:08 +0100, Alexander Dalloz wrote:
> Am 15.12.2018 um 19:43
Am 15.12.2018 um 19:43 schrieb Aki Tuomi:
I've posted te full output from dovecot -n to https://pastebin.com/F8Ra
C4bt
You again broke your setup. From your pastebin:
ssl_cert = /etc/certbot/live/privustech.com/fullchain.pem
That's missing the "<" in front of the path to the certificate
Am 15.12.2018 um 19:02 schrieb C. Andrews Lavarre:
The openssl command I have tried (that used to work with Dovecot 2.2)
is:
openssl s_client -connect mail.privustech.com:143
I have also tried
openssl s_client -connect mail.privustech.com:143 -servername
mail.privustech.com
That command is missing -starttls imap? or are you using port 993?
On 15 December 2018 at 20:02 "C. Andrews Lavarre" <
alava...@gmail.com> wrote:
Excellent, thank you again.
The openssl command I have tried (that used
Excellent, thank you again.
The openssl command I have tried (that used to work with Dovecot 2.2)
is:
openssl s_client -connect mail.privustech.com:143
I have also tried
openssl s_client -connect mail.privustech.com:143 -servername
mail.privustech.com
I've posted the full output
Am 15.12.2018 um 17:16 schrieb C. Andrews Lavarre:
to /etc/apparmor.d/local/usr.lib.dovecot.imap-login but still
cannot login with either the mail client or with explicit openssl: it
complains
error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown
Alexander good afternoon. Thank you. I have spent the day learning
about AppArmor:
• I've reviewed your link, found /etc/apparmor.d/ and its local/
directory.
• I ran aa-logprof and it found the change in stat to old-stat
that is discussed in the upgrade documentation. So I Allow
Am 14.12.2018 um 19:58 schrieb C. Andrews Lavarre:
Thanks for the input. I've checked out your suggestions (details below)
but unfortunately no joy.
I also restored my backup 10-ssl.conf. It indeed has the "<" sign with
a space before the explicit paths to the files:
ssl_cert =
Hi,
the
Aki hello, thank you. Hopefully excerpts and top posting are acceptable
in the mailing list?
On that assumption:
Thanks for the input. I've checked out your suggestions (details below)
but unfortunately no joy.
I also restored my backup 10-ssl.conf. It indeed has the "<" sign with
a space before
> On 14 December 2018 at 02:12 "C. Andrews Lavarre" wrote:
>
>
> Problem:
> We had Dovecot v2.2 working just fine under openSUSE Leap 42.3. But we
> upgraded openSUSE to Leap 15.0.
> In the process, Dovecot got upgraded from 2.2 to 2.3.1. It no longer
> works and I haven't figured out how to
Problem:
We had Dovecot v2.2 working just fine under openSUSE Leap 42.3. But we
upgraded openSUSE to Leap 15.0.
In the process, Dovecot got upgraded from 2.2 to 2.3.1. It no longer
works and I haven't figured out how to downgrade to the older working
version.
The key issue seems to be the change
21 matches
Mail list logo
