Retransmissão baseada em certificado do cliente Postfix 2.10

Question

Estou tentando configurar 2 instâncias do Postfix 2.10.1, cada uma em sistemas CentOS 7 separados, para permitir a retransmissão baseada em certificado de um sistema (que chamaremos de client.example.com ) para o outro ( server.example.com ), mas eu acertei um obstáculo. O servidor absolutamente se recusa a aceitar o relé com base na impressão digital do certificado do cliente.

Veja com o que estou trabalhando:

Saída do postconf -n no servidor :

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5
html_directory = no
inet_interfaces = all
inet_protocols = ipv4
local_recipient_maps =
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = localhost
mydomain = example.com
myhostname = server.example.com
mynetworks = 127.0.0.0/8
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES
relay_clientcerts = hash:/etc/postfix/relay_clientcerts
relayhost = [192.168.1.3]
sample_directory = /usr/share/doc/postfix-2.10.1/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_recipient_restrictions = permit_tls_clientcerts, reject_unauth_destination
smtpd_tls_CAfile = /etc/pki/tls/certs/cacert.pem
smtpd_tls_ask_ccert = yes
smtpd_tls_cert_file = /etc/pki/tls/certs/server.example.com.crt
smtpd_tls_fingerprint_digest = sha1
smtpd_tls_key_file = /etc/pki/tls/private/server.example.com.key
smtpd_tls_loglevel = 2
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550

Saída do postconf -n no cliente :

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5
html_directory = no
inet_interfaces = localhost
inet_protocols = all
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = $myhostname, localhost.$mydomain, localhost
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES
relayhost = [server.example.com]
sample_directory = /usr/share/doc/postfix-2.10.1/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_tls_CAfile = /etc/pki/tls/certs/cacert.pem
smtp_tls_cert_file = /etc/pki/tls/certs/client.example.com.crt
smtp_tls_fingerprint_digest = sha1
smtp_tls_key_file = /etc/pki/tls/private/client.example.com.key
smtp_tls_loglevel = 3
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550

Conteúdo de relay_clientcerts no servidor (isso corresponde exatamente à impressão digital nos logs e a saída do comando openssl x509 -fingerprint ... ):

12:34:56:78:90:AB:CD:EF:FE:DC:BA:09:87:65:43:21:C0:DE:BE:EF client.example.com

Correio de saída sendo iniciado no cliente por meio de e-mail :

mail -s "Hello world" [email protected]
hello world
.

Saída de log do servidor:

Nov 30 21:40:39 server postfix/smtpd[7859]: client.example.com[192.168.1.1]: subject_CN=client.example.com, issuer=ca.example.com, fingerprint=12:34:56:78:90:AB:CD:EF:FE:DC:BA:09:87:65:43:21:C0:DE:BE:EF, pkey_fingerprint=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
Nov 30 21:40:39 server postfix/smtpd[7859]: Trusted TLS connection established from client.example.com[192.168.1.1]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Nov 30 21:40:39 server postfix/smtpd[7859]: NOQUEUE: reject: RCPT from client.example.com[192.168.1.1]: 454 4.7.1 <[email protected]>: Relay access denied; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<client.example.com>
Nov 30 21:40:39 server postfix/smtpd[7859]: disconnect from client.example.com[192.168.1.1]

Saída de log do cliente:

Nov 30 21:40:39 client postfix/smtp[15525]: server.example.com[192.168.1.2]:25: subject_CN=server.example.com, issuer_CN=ca.example.com, fingerprint=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX, pkey_fingerprint=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
Nov 30 21:40:39 client postfix/smtp[15525]: Trusted TLS connection established to server.example.com[192.168.1.2]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Nov 30 21:40:39 client postfix/smtp[15525]: 563502306537: to=<[email protected]>, relay=server.example.com[192.168.1.2]:25, delay=431, delays=430/0.02/0.07/0.11, dsn=4.7.1, status=deferred (host server.example.com[192.168.1.2] said: 454 4.7.1 <[email protected]>: Relay access denied (in reply to RCPT TO command))

Detalhes adicionais:

• Ambos os sistemas possuem certificados válidos assinados pela minha CA interna
• Ambos os sistemas possuem registros A e PTR válidos
• Posso consultar com êxito a impressão digital no banco de dados relay_clientcerts com postmap -q
• Especificar smtpd_recipient_restrictions = permit_tls_clientcerts, permit_mynetworks, reject_unauth_destination e mynetworks = 127.0.0.0/8, 192.168.1.0/24 no servidor faz permitir que o cliente retransmita mensagens pelo servidor sem problemas

Eu examinei a documentação do Postfix, o arquivo da lista de usuários do postfix-users e o Google em geral, e minha configuração parece correta para mim (pelo menos, correta o suficiente para funcionar). Meu entendimento é que a combinação de permit_tls_clientcerts e relay_clientcerts deve ser suficiente para permitir o relé. Obviamente, ou eu estou errado ou simplesmente não estou vendo isso.

O que estou perdendo é que está impedindo o servidor de permitir o relé com base na impressão digital do cliente?

    

Answer 1

Continuei pesquisando na documentação do Postfix e tropecei na resposta:

No Postfix 2.10, um novo parâmetro de configuração chamado smtpd_relay_restrictions foi introduzido para resolver problemas em que políticas permissivas de bloqueio de spam em smtpd_recipient_restrictions resultavam em políticas de retransmissor permissivas. De acordo com a documentação ( link ), esse parâmetro aceita os mesmos valores e deve "preferencialmente" ser usado para configurar a política de retransmissão:

As of Postfix 2.10, relay permission rules are preferably implemented with smtpd_relay_restrictions, so that a permissive spam blocking policy under smtpd_recipient_restrictions will no longer result in a permissive mail relay policy.

...

Specify a list of restrictions, separated by commas and/or whitespace. Continue long lines by starting the next line with whitespace. The same restrictions are available as documented under smtpd_recipient_restrictions.

O que não ficou imediatamente aparente (para mim, pelo menos) foi que o parâmetro smtpd_relay_restrictions tem um valor padrão de permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination (como foi revelado executando postconf sem opções), e substitui smtpd_recipient_restrictions completamente quando tem um valor não vazio. Da documentação:

For backwards compatibility, sites that migrate from Postfix versions before 2.10 can set smtpd_relay_restrictions to the empty value, and use smtpd_recipient_restrictions exactly as before.

A solução, portanto, é configurar smtpd_relay_restrictions para o valor vazio em main.cf e utilizar smtpd_recipient_restrictions como nas versões anteriores, ou para configurar a política de retransmissão usando o novo parâmetro. Eu escolhi o último, e o relé baseado em certificado agora está funcionando como esperado.