martin f krafft wrote:
In fact, there are three options right now:
a/ collect and deploy the fingerprints, as you say
b/ use a self-signed certificate with life-time 99 years just for
this purpose
c/ use public key fingerprints instead of the cert fingerprints
I think (a) is really j
also sprach Viktor Dukhovni [2017-09-18 22:39
+0200]:
> > No, they're all managed centrally and pushed regularly.
>
> So, though this is not your best option, you can centrally capture
> the updated fingerprints and automate their deployment (along with
> the most recent previous fingerprint to
martin f krafft wrote:
also sprach Viktor Dukhovni [2017-09-18 00:31
+0200]:
So your certral system generates the keys, and obtains the LE
certificates on behalf of the far-flung hosts? And then pushes
these keys to the hosts over an SSH tunnel?
Is that only for the initial key issuance? An
On Mon, Sep 18, 2017 at 10:09:14PM +0200, martin f krafft wrote:
> > Is that only for the initial key issuance? And then each host
> > rotates the certs independently of the central system using the
> > existing key to authenticate to LE?
>
> No, they're all managed centrally and pushed regularl
also sprach Viktor Dukhovni [2017-09-18 00:31
+0200]:
> So your certral system generates the keys, and obtains the LE
> certificates on behalf of the far-flung hosts? And then pushes
> these keys to the hosts over an SSH tunnel?
>
> Is that only for the initial key issuance? And then each host
A very interesting discussion...
On 17/09/17 22:49, Viktor Dukhovni wrote:
There is no meaningful ordering of SANs.
Can you explain a bit more detail here? (c) :) I though you can list
SANs in the order you want in your certificate request and everything
else will preserve it, and that applies
martin f krafft:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> also sprach Wietse Venema [2017-09-17 21:51 +0200]:
> > I wonder, if this is used for 'internal' email traffic, why bother
> > with certificates that require frequent renewal? If the organization
> > is
On Sun, Sep 17, 2017 at 11:04:47PM +0200, martin f krafft wrote:
> > 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?
>
> I'
also sprach Wietse Venema [2017-09-17 21:51 +0200]:
> I wonder, if this is used for 'internal' email traffic, why bother
> with certificates that require frequent renewal? If the organization
> is that large, I would expect that all external email is handled
> by relay hosts on the perimeter, inst
also sprach Viktor Dukhovni [2017-09-17 21:49
+0200]:
> 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?
I'll go with that.
> Yo
I wonder, if this is used for 'internal' email traffic, why bother
with certificates that require frequent renewal? If the organization
is that large, I would expect that all external email is handled
by relay hosts on the perimeter, instead of allowing direct mail
from random 'internal' hosts.
> On Sep 17, 2017, at 3:29 PM, martin f krafft wrote:
>
> also sprach Viktor Dukhovni [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 contro
also sprach Viktor Dukhovni [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 ba
> On Sep 17, 2017, at 11:41 AM, martin f krafft wrote:
>
> If a client connects and presents a certificate from a CA listed in
> smtpd_tls_CA_file, then I don't see a reason why the new
> check_certname_access shouldn't be able to cast an "OK" and thereby
> permit accepting/relaying of the messa
also sprach Wietse Venema [2017-09-17 17:26 +0200]:
> > > 2) Use a new check_certname_access feature to reject out-of-doman
> > >names. Postfix should not make 'allow' decisions based on name
> > >information in a certificate with an untrusted CA.
>
> Any CA that is not in smtpd_tls_CA_fi
martin f krafft:
> also sprach Wietse Venema [2017-09-17 16:34 +0200]:
> > 1) Use smtpd_tls_CA_file to trust ONLY the letsencrypt CA.
>
> Right, especially since I could set this only for the smtpd handling
> submissions and need not impose this setting on regular port 25 SMTP
> connections.
>
>
also sprach Wietse Venema [2017-09-17 16:34 +0200]:
> 1) Use smtpd_tls_CA_file to trust ONLY the letsencrypt CA.
Right, especially since I could set this only for the smtpd handling
submissions and need not impose this setting on regular port 25 SMTP
connections.
I suppose it would get difficult
I suggest that we keep it simple:
1) Use smtpd_tls_CA_file to trust ONLY the letsencrypt CA.
2) Use a new check_certname_access feature to reject out-of-doman
names. Postfix should not make 'allow' decisions based on name
information in a certificate with an untrusted CA.
Wietse
Hello,
As far as I can tell, postfix can authenticate its clients using
certificates in two ways:
check_ccert_access (also permit_tls_clientcerts), which
authorizes clients based on the cert fingerprint;
permit_tls_all_clientcerts, which authorizes clients if they
present a cert signed b
19 matches
Mail list logo
