<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>As a LetsEncrypt user myself, I have:</p>
    <p>ssl_cert = </etc/letsencrypt/live/myserver/fullchain.pem<br>
      ssl_key = </etc/letsencrypt/live/myserver/privkey.pem<br>
    </p>
    <p>So nothing further should be required.  You say Dovecot fails to
      start - have you tried simply executing "dovecot -F"?<br>
    </p>
    <pre class="moz-signature" cols="72">Daniel

</pre>
    <div class="moz-cite-prefix">On 12/16/2018 6:19 AM, C. Andrews
      Lavarre wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:1544969960.4571.36.camel@gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div>Phil hi.</div>
      <div><br>
      </div>
      <div>Thank you for explaining what the symbol does... so it is
        like the BASH <b>from</b> symbol. OK.That is new information.</div>
      <div><br>
      </div>
      <div>So without it dovecot reads the <b>path/to/file</b> as if it
        were a hashed cert, which of course doesn't work. So <b>with</b>
        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 <b>cat</b> the path/to/file and read the cert or key...</div>
      <div><br>
      </div>
      <div>Now, while the /path/to/file permission is presently  <b>root:root
          0777 </b>(yes, I know 0777 is not good, but I was trying to
        eliminate any prevention to reading it)<b> </b>it is actually a
        soft link to yet another file. Let'sEncrypt has to be renewed
        every so often so the cert engine (<b>certbot</b>) recreates the
        softlink to the new cert so that we don't need to edit <b>10-ssl.conf</b>. </div>
      <div><br>
      </div>
      <div>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. </div>
      <div><br>
      </div>
      <div>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 (<b>ls, cat</b>)
        the file? What changed in that regard from 2.2.x to 2.3.1?</div>
      <div><br>
      </div>
      <div>----</div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>But "something is wrong with your configuration",  while
        equally factual, is also equally ineffective. </div>
      <div><br>
      </div>
      <div>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. </div>
      <div><br>
      </div>
      <div>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. </div>
      <div><br>
      </div>
      <div>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?</div>
      <div><br>
      </div>
      <div>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. :-)</div>
      <div><br>
      </div>
      <div>Thanks again.</div>
      <div><br>
      </div>
      <div>Andy</div>
      <div><br>
      </div>
      <div>On Sun, 2018-12-16 at 07:41 -0500, Phil Turmel wrote:</div>
      <blockquote type="cite">
        <pre>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:
<blockquote type="cite">
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.
</blockquote>


Regards,

Phil
</pre>
      </blockquote>
    </blockquote>
  </body>
</html>