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. You are simply not going to succeed until *you* figure out what security differences you have in your new installation. So dovecot can read the files. Every single attempt to connect via openssh depends on dovecot reading your certificate and key files. They are pointless exercises until dovecot actually loads your files. Focus on the real problem if you wish to fix your service. On 12/15/18 5:12 PM, C. Andrews Lavarre wrote:> 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.Regards, Phil
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 for some reason cannot read it. Now, that is curious, since I can cat the path/to/file and read the cert or key... Now, while the /path/to/file permission is presently ?root:root 0777 (y es, I know 0777 is not good, but I was trying to eliminate any prevention to reading it)?it is actually a soft link to yet another file. Let'sEncrypt has to be renewed every so often so the cert engine (certbot) recreates the softlink to the new cert so that we don't need to edit 10-ssl.conf.? So I have entered the actual full path/to/file for the cert and key (not the softlinks) to eliminate that possibility, buty it didn't help. So it's something else.? As you say, focus on the problem: Simply put, why can 2.3.1 not read a file while we can list and print out (ls, cat) the file? What changed in that regard from 2.2.x to 2.3.1? ---- I'm very grateful for the time folks have spent on this, including my own time. I'm not being rude, just factual. This is what is happening. But "something is wrong with your configuration", ?while equally factual, is also equally ineffective.? OTOH, in my experience factually describing an anomaly can lead to someone wondering why it might be, and if they are more knowledgeable of the inner workings of the system be better able to understand why that might be.? For example, I didn't know anything about AppArmor before, now I do, have gone down that rabbit hole, and seem to be able to say, nope, that's not the problem. So now I can move on to checking out something else.? Similarly, under BASH the path/to/files are all correct and I can read them from the command line. And 2.2.x didn't have any problem with them. So why might 2.3.1 not be able to read them? So we all need to leave this alone, for now. I'll work along, and when/if I figure it out shall return to report. I'm sure it's something simple: Easy when you know how. :-) Thanks again. Andy On Sun, 2018-12-16 at 07:41 -0500, Phil Turmel wrote:> 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.??You > are > simply not going to succeed until *you* figure out what security > differences you have in your new installation.??So dovecot can read > the > files.??Every single attempt to connect via openssh depends on > dovecot > reading your certificate and key files.??They are pointless exercises > until dovecot actually loads your files.??Focus on the real problem > if > you wish to fix your service. > > On 12/15/18 5:12 PM, C. Andrews Lavarre wrote: > > > > 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. > > Regards, > > Phil-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20181216/535f33f5/attachment.html>
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.?-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20181216/e1ea17ad/attachment-0001.html>
As a LetsEncrypt user myself, I have: ssl_cert = </etc/letsencrypt/live/myserver/fullchain.pem ssl_key = </etc/letsencrypt/live/myserver/privkey.pem 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 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 for some reason cannot read > it. Now, that is curious, since I can *cat* the path/to/file and read > the cert or key... > > Now, while the /path/to/file permission is presently *root:root 0777 > *(yes, I know 0777 is not good, but I was trying to eliminate any > prevention to reading it)**it is actually a soft link to yet another > file. Let'sEncrypt has to be renewed every so often so the cert engine > (*certbot*) recreates the softlink to the new cert so that we don't > need to edit *10-ssl.conf*. > > So I have entered the actual full path/to/file for the cert and key > (not the softlinks) to eliminate that possibility, buty it didn't > help. So it's something else. > > As you say, focus on the problem: Simply put, why can 2.3.1 not read a > file while we can list and print out (*ls, cat*) the file? What > changed in that regard from 2.2.x to 2.3.1? > > ---- > > I'm very grateful for the time folks have spent on this, including my > own time. I'm not being rude, just factual. This is what is happening. > > But "something is wrong with your configuration", ?while equally > factual, is also equally ineffective. > > OTOH, in my experience factually describing an anomaly can lead to > someone wondering why it might be, and if they are more knowledgeable > of the inner workings of the system be better able to understand why > that might be. > > For example, I didn't know anything about AppArmor before, now I do, > have gone down that rabbit hole, and seem to be able to say, nope, > that's not the problem. So now I can move on to checking out something > else. > > Similarly, under BASH the path/to/files are all correct and I can read > them from the command line. And 2.2.x didn't have any problem with > them. So why might 2.3.1 not be able to read them? > > So we all need to leave this alone, for now. I'll work along, and > when/if I figure it out shall return to report. I'm sure it's > something simple: Easy when you know how. :-) > > Thanks again. > > Andy > > On Sun, 2018-12-16 at 07:41 -0500, Phil Turmel wrote: >> 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. You are >> simply not going to succeed until *you* figure out what security >> differences you have in your new installation. So dovecot can read the >> files. Every single attempt to connect via openssh depends on dovecot >> reading your certificate and key files. They are pointless exercises >> until dovecot actually loads your files. Focus on the real problem if >> you wish to fix your service. >> >> On 12/15/18 5:12 PM, C. Andrews Lavarre wrote: >>> 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. >> >> >> >> Regards, >> >> Phil-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20181216/74ef2c54/attachment.html>