Re: Authenticating clients based on CA/CN-match

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

Re: Authenticating clients based on CA/CN-match

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

Re: Authenticating clients based on CA/CN-match

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

Re: Authenticating clients based on CA/CN-match

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

Re: Authenticating clients based on CA/CN-match

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

Re: Authenticating clients based on CA/CN-match

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

Re: Authenticating clients based on CA/CN-match

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

Re: Authenticating clients based on CA/CN-match

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? > >

Re: Authenticating clients based on CA/CN-match

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

Re: Authenticating clients based on CA/CN-match

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

Re: Authenticating clients based on CA/CN-match

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.

Re: Authenticating clients based on CA/CN-match

> 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

Re: Authenticating clients based on CA/CN-match

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

Re: Authenticating clients based on CA/CN-match

> 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

Re: Authenticating clients based on CA/CN-match

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

Re: Authenticating clients based on CA/CN-match

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

Re: Authenticating clients based on CA/CN-match

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

Re: Authenticating clients based on CA/CN-match

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

Authenticating clients based on CA/CN-match

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