<<Reiterate original post in new thread>>

In my config, I forward deliveries to Dovecot over LMTPS. The machine (there is just one for now) forwarding the mail has a certificate from a well known and trusted CA. How can I configure Dovecot to accept mail deliveries from that one machine?

Currently I have:

protocol lmtp{ login_trusted_networks = 192.168.x.y 0011:2233:4455:6677:8899:aabb:ccdd:eeff auth_ssl_require_client_cert = yes ssl_verify_client_cert = yes ssl_ca = (a private - single purpose CA) ...

The IP addresses are the addresses of the LMTPS client machine.

I have a created a CA for the sole purpose of signing the certificate of the LMTPS client. I regard this as a horrible horrible kludge.

I would like to be able to set ssl_ca to the root certificate of the public trusted CA but can't work out how to get Dovecot to check the name on the certificate.

<<End original post>>

On 17/05/2023 12:13 am, Jochen Bern wrote:

On 16.05.23 14:27, Sean Gallagher wrote:

...

I have a created a CA for the sole purpose of signing the certificate of the LMTPS client. I regard this as a horrible horrible kludge.

... how do you figure that? *Someone*, and that means you, has to specify which clients are allowed to connect. Which leaves three possibilities:

a) You run the CA and thus, the CA can do the selection for you. Which means that in order to deal with a single-permissible-client situation, you need the CA to issue client certs to just that one entity. b) The CA does *not* and issues (client) certs to entities you do *not* want to grant access. Then the selection job remains yours and, assuming that requiring a client cert from that CA makes any sense in the first place, auth_ssl_username_from_cert is there to help you (by making sure that the username will be "the ID" from the cert so that you can base some additional filtering on that). c) The CA is willing to enrich the certs it issues with DN parts, X509v3 extensions or the like signalling access rights as granted beforehand by a *fourth* party, as in, you. Which is a terrible can of worms as soon as things, especially the number of such fourth parties to support by the same CA, start to scale up IMHO. Which promptly brings us back to you running the CA yourself ...

We can start by ruling out possibility "c". If there was code in Dovecot to check esoteric X509v3 extensions, then surely there could be code to check the certificate name. There are obviously many other problems with getting third party CA's to do anything special for one client but exploring that won't add to this discussion.

Of the other two options, I currently have "a" but  would prefer to have "b" - if it can be implemented securely.

Before going into reasons, I would like to make an assertion that guides my thinking on this: Complexity is the enemy of security. Complexity implies large attack surfaces. It implies more code that is harder to debug. It implies fewer people willing and able to understand it and therefore, a more complex solution to any given problem is more likely to have vulnerabilities. Case in point: CVE-2019-3814. That said, any two people may weight "complexity" differently and so there is still room for personal preference.

possibility "a" has the advantage of a trivially simple security analysis. If the server requires a certificate from a specific CA, and that CA has only ever signed one certificate, you don't need to read the certificate to know what it says. The disadvantage of "a" is that it is not how PKI is understood to work. In fact it is Pre-Shared-Keys, dressed up as PKI. Maintaining different CA's for each service requires ongoing knowledge and effort. This is complexity that is best avoided. If systems are configured to work the "normal" way, they are more easily understood and maintained securely.

possibility "b" has the advantage of being immediately recognizable to anyone familiar with PKI. However it is not obvious that it will even work on Dovecot. as pointed out the "auth_ssl_username_from_cert" is generally used in Dovecot to do certificate based client authentication. This authentication happens in the "-login" process associated with each service, however the LMTP server does not have a login process and does not require explicit authentication. My current config accepts deliveries from Postfix. Postfix does not issue the AUTH command and deliveries proceed as expected. It is not obvious the this setting has any effect on the LMTP server. Even if we DID set the USERNAME to the certificate name, we still need to validate it somehow.

Perhaps I am missing some key piece of the puzzle, in which case please correct me, but it seems Dovecot is deficient in the authentication of LMTP client certificates. It continues to surprise me that this is not given a higher priority.

   Sean.

-- This email has been checked for viruses by AVG antivirus software. www.avg.com