<div dir="auto">Nicely done, Josh! Happy Thanksgiving!</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 21, 2018, 20:45 Josh Grosse <<a href="mailto:josh@jggimi.net">josh@jggimi.net</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The TL;DR - I figured out my error.  As expected, it was<br>
in my test configuration files.<br>
<br>
For anyone actually interested:<br>
<br>
I'd asked if anyone had an inkling why my perfectly valid<br>
self-signed x509 certificates were failing in a lab that I<br>
had prepared for a migration to the new OpenSMTPd release.<br>
It's an isolated test environment to prevent any test <br>
results from getting away from me and annoying the Internet.<br>
<br>
I set up the test environment because much of the mail server<br>
logical flow and the provisioning syntax has changed, and<br>
I have two mail servers with complex flows between them, <br>
using PKI and authentication to eliminate several forms<br>
of attack on the main internet-facing MTA, and vxlan(4)<br>
to tunnel SMTP traffic between these servers.<br>
<br>
But my test environment was not functioning properly, <br>
because of certificate failures.  My production <br>
environment runs fine, using a public CA and their<br>
provided certificates.<br>
<br>
For this test environment, I'd followed the starttls(8)<br>
man page, studied and re-studied the smtpd.conf(5) man<br>
page, and was at a loss.  So I took the opportunity this<br>
week to ask at the meeting if anyone had advice.<br>
<br>
My own thought was to reach out to the lead developer<br>
Gilles Chehade, who has been kind enough to offer<br>
support to the user community on provisioning problems.<br>
But I was hoping to avoid bothering him.  Again. :)<br>
<br>
This evening, one of the *many* tests I ran was without<br>
authentication.  And suddenly my certificates were <br>
acceptable between my two test MTAs. .<br>
<br>
Authentication is a form of password protection, and can<br>
be used -- when the session is encrypted -- of ensuring <br>
that the two ends of the session are from known and <br>
trusted mail systems.  The authentication in SMTP happens<br>
in plain text, so OpenSMTPd rightly only permits it when<br>
the SMTP session occurs in encrypted form.<br>
<br>
With OpenSMTPd, this encryption requires TLS or SMTPS.<br>
You can't configure it without encryption.  And encryption<br>
requires an X.509 certificate.  And in my enclosed little<br>
lab (virtual machines on a laptop), self-signed seemed<br>
like it should have been a perfect solution.<br>
<br>
What I discovered was that if one is using TLS or SMTPS<br>
without authentication ... then a self-signed certificate<br>
is perfectly OK.  But, if you enable authentication, then<br>
you must have a cert signed by a valid CA.<br>
<br>
This restriction is hidden in plain sight, in smtpd.conf(5),<br>
but I missed it, as it just happened to be the last line<br>
in a paragraph on authentication tables:<br>
<br>
        The label corresponds to an entry in a credentials table,<br>
        as documented in table(5).  It is used with the<br>
        "smtp+tls" and "smtps" protocols for authentication.<br>
        Server certificates for those protocols are verified by<br>
        default.<br>
<br>
My next tests will be to override the default with "tls no-verify"<br>
and if succesful, I can complete my testing without having to<br>
deal with the hassle of obtaining new certs just for my lab<br>
machines, and then openg up my lab's network to the Internet<br>
for verifying the certs.  I want to make sure my mail servers<br>
are operating properly and not spewing traffic they shouldn't <br>
be.  <br>
<br>
_______________________________________________<br>
Semibug mailing list<br>
<a href="mailto:Semibug@lists.nycbug.org" target="_blank" rel="noreferrer">Semibug@lists.nycbug.org</a><br>
<a href="http://lists.nycbug.org/mailman/listinfo/semibug" rel="noreferrer noreferrer" target="_blank">http://lists.nycbug.org/mailman/listinfo/semibug</a><br>
</blockquote></div>