> On Sep 17, 2017, at 3:29 PM, martin f krafft <madd...@madduck.net> wrote:
>
> also sprach Viktor Dukhovni <postfix-us...@dukhovni.org> [2017-09-17 18:09
> +0200]:
>> Can you explain your use-case in a bit more detail? What sort of
>> SMTP clients are these, that they authenticate using TLS client
>> certificates not issued by a CA you control and you're then
>> providing submission access to said clients based on their domain
>> as found in the certificate CN?
>
> I have three distinct use-cases, but they're all more or less the
> same, involving 107 hosts altogether spread across the globe in
> untrusted networks, often with weird firewalling or other policies.
> There are several hundreds of users making use of cron and other
> things that basically require sendmail on each host. To keep our
> sanity, we currently have it such that all hosts forward their mail
> to a smarthost via the submission port, TLS-secured, and
> authenticated with the TLS cert fingerprint (using
> check_ccert_access).
I think you're saying your organization places machines you (collectively)
build on other people's networks, but the machines need to send call
home to send email, which is sometimes outbound to other domains?
> Our recent move to Letsencrypt means that the hosts now get new
> client certificates every 2–3 months.
You don't have to the same key/cert across the board, the client
certificate for submission does not need to be (and perhaps should
not be) the one that's issued by Let's Encrypt (LE).
Are you using LE to obtain certificates that are trusted by other
parties, or using LE because "certbot", ... make it easy to automate
renewal?
How does one of these far-flug clients get an LE certificate in your
domain in the first place?
> Given that we trust Letsencrypt (for benefit of doubt) —
I am trying to understand why you want to delegate relay control
decisions for your domain to LE.
> Given that LE's challenge-response means that only we can issue
> certs that contain example.org in the CN or SubjectAltNames list —
Can you explain a bit more detail here?
> Why do I have to give postfix the fingerprints. Wouldn't it be just
> as safe and a lot easier to say "certs matching¹ .example.org issued
> by LE" and be done with it.
Well, it isn't typically "just as safe", the LE enrollment process
is often vulnerable to on-path or BGP-route forgery MiTM attacks
between the CA and the domain for which the certificates are being
issued.
What I am trying to understand is the circumstances that lead you
to use LE for issuing submission client certificates...
>> Though most CAs have not yet stopped putting nonempty subject DNs
>> in certificates, the right place for certificate names is the
>> subjectAlternativeName extension, which bears zero or more DNS
>> names and perhaps names of other types too.
>
> So there exists no longer a canonical name/identity of
> a certificate?
The canonical identity is the issuer DN + serial number.
The subject DN can be an empty RDN sequence. Mind you,
at the moment all the LE certificates I've seen have
a nonempty CN as the sole component of the subject DN,
and this may not change for a long time, but it is not
guaranteed indefinitely...
> I am well aware of SubjectAltNames, but I am unsure
> they're ordered, or whether there even exists such a convention
> that e.g. the first one is the primary name.
There is no meaningful ordering of SANs.
--
Viktor.
