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
