To follow up on my previous email,
It seems the lmtp deamon does NOT support ssl_ca selection based on remote IP. It also does NOT seem to support authorization. The solution I arrived at was to create a separate CA, used solely for the purpose of authorizing LDAP clients.
openssl genpkey-algorithm rsa-pkeyopt rsa_keygen_bits:4096 -out /etc/ssl/private/ca_dovecot_lmtps.key openssl req-x509 -new -subj '/CN=Dovecot LMTP Authorization CA' -key /etc/ssl/private/ca_dovecot_lmtps.key-nodes -sha256 -days 3650 -addext 'keyUsage=keyCertSign,cRLSign' -out /etc/ssl/private/ca_dovecot_lmtps.pem
This CA can then be used to sign certificates for LMTP clients to use when delivering mail.
export lmtpsrc=msa openssl genpkey-algorithm rsa-pkeyopt rsa_keygen_bits:2048 -out /etc/ssl/private/_lmtp.${lmtpsrc}.example.com.key openssl req-new -nodes -key /etc/ssl/private/_lmtp.${lmtpsrc}.example.com.key-sha256 -out /etc/ssl/private/_lmtp.${lmtpsrc}.example.com.csr-subj "/CN=${lmtpsrc}.example.com" cat <<EOF >/etc/ssl/private/_lmtp.${lmtpsrc}.example.com.ext basicConstraints = critical, CA:FALSE keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = serverAuth, clientAuth subjectAltName = DNS:${lmtpsrc}.example.com subjectKeyIdentifier =hash authorityKeyIdentifier = keyid:always, issuer:always EOF openssl x509-req -CA /etc/ssl/private/ca_dovecot_lmtp.pem-CAkey /etc/ssl/private/ca_dovecot_lmtp.key-sha256 -days 3650 -in /etc/ssl/private/_lmtp.${lmtpsrc}.example.com.csr-extfile /etc/ssl/private/_lmtp.${lmtpsrc}.example.com.ext-out /etc/ssl/private/_lmtp.${lmtpsrc}.example.com.pem
The Dovecot configuration looks like this
protocol lmtp { mail_uid = nobody auth_ssl_require_client_cert = yes ssl_verify_client_cert = yes ssl_ca = </etc/ssl/private/ca_dovecot_lmtps.pem
ssl = required ssl_cert = </etc/ssl/mda.example.com-chain.pem ssl_key = </etc/ssl/private/mda.example.com.key ssl_require_crl = no }
This solution seems secure and manageable so long as the number of LMTP sources stays small, but overall, feels very unsatisfactory.
I would regard Dovecot's inability to inspect the LMTP certificate's subject name as a BUG that should be prioritized.
As it stands, I would not be surprised to find real-world deployments of Dovecot that are insecure, as _ANY_ host with a valid certificate could originate mail. As a quick illustration, I created another certificate with an invalid name from my "/CN=Dovecot LMTP Authorization CA" authority. The mail was accepted without complaint. In "normal" setups, a certificate from any public CA would be accepted.
Feb 11 14:29:52 imaps mail.info dovecot: lmtp(16386): Received valid SSL certificate: /CN=Dovecot LMTP Authorization CA Feb 11 14:29:52 imaps mail.info dovecot: lmtp(16386): Received valid SSL certificate: /CN=evil.example.com Feb 11 14:29:52 imaps mail.debug dovecot: lmtp(16386): Debug: SSL: where=0x2001, ret=1: SSLv3/TLS read client certificate Feb 11 14:29:52 imaps mail.debug dovecot: lmtp(16386): Debug: SSL: where=0x2001, ret=1: SSLv3/TLS read certificate verify Feb 11 14:29:52 imaps mail.debug dovecot: lmtp(16386): Debug: SSL: where=0x2001, ret=1: SSLv3/TLS read finished Feb 11 14:29:52 imaps mail.debug dovecot: lmtp(16386): Debug: SSL: where=0x20, ret=1: SSLv3/TLS write session ticket Feb 11 14:29:52 imaps mail.debug dovecot: lmtp(16386): Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write session ticket Feb 11 14:29:52 imaps mail.debug dovecot: lmtp(16386): Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write session ticket Feb 11 14:29:52 imaps mail.debug dovecot: lmtp(16386): Debug: SSL: where=0x2002, ret=1: SSL negotiation finished successfully
-- This email has been checked for viruses by AVG antivirus software. www.avg.com