On Mon, Mar 23, 2026 at 03:07:57PM +0100, P v via Postfix-users wrote:
> We provide a service in which some mails from other organizations are not
> routed the normal way but through our service.
In other words an outbound smarthost relay.
> This is normally not a special system that sends this emails but the normal
> mail gateway of the organization. So there is a normal certificate of a CA
> deployed there.
That's a design error. The keypair (private key and certificate) used
to authenticate to your relay should be *dedicated* for just connections
via your service, and should be independent of any public certificate
that the same system uses for receiving mail from others.
Otherwise, you're basically delegating to every random CA on the plant
the pwoer to authorise relay access through your system, which is not
a good idea. Keys held by your customers that enable them to relay
through your systems need to be registered with you and not rotated
without prior notice to you and consent from your side.
1. Client generates a replacement key, but does not immediately start
using it.
2. Client notifies you of their intent to use the new key over a
trusted and confirmed channel.
3. You check with the customer that you've receive the correct key.
4. After they confirm that the right key has been sent, you enable
the customer to use either the old or the new key.
5. Some time later customer cuts over to the new key and notifies
you that the old key can be retired.
6. You retire the old key.
A sensible customer will not choose to go through this process too
frequently. If customers have account admin logins, the process
can be mostly automated on your end, with the authorised admin
registering the new key, confirming its validity, and later
confirming cutover.
> To authenticate them we used a combination of the ip address,
> certificate fingerprint and domain.
It should be a public key fingerprint, not a certificate fingerprint.
> So to be a bit more flexible with the certificate I implemented a
> policy service that checks the CN of the certificate and the issuing
> CA, so if the certificate was changed, it would still work.
That's not a robust design. I haven't yet implemented support for
client-side DANE TLSA records that could in theory make it possible for
clients to publish the key fingerprints in their own DNS(SEC), but
likely most of your customer domains are not signed, so that would not
solve your problem.
> Now with the next change and the missing EKU for client
> authentication, I'm facing a new challenge and thats why I started
> this topic, because maybe there is something I was missing. But I
> think we should rethink the entire process and maybe implement
> authentication with SASL or self deployed client certificates as the
> people in this thread recommended.
Yes, client certs are just weird passwords, that your side can't leak,
and which are are unlikely to be weak choices on the user side. You can
use SASL, or you can even generate the keys and certs for the clients to
use, with their account admin able to download a PKCS#12 blob with the
private key and cert to use. That obviates the need for the customer
to use some other CA, and makes it more clear that the cert in question
is just for access to your relay, separate from any cert they use
inbound.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
