Configurare DANE per SMTP: record TLSA e DNSSEC per il tuo server di posta

Cosa significa

Per impostazione predefinita, i server che ti consegnano la posta usano TLS (STARTTLS) solo "se possibile" e non controllano il tuo certificato. Un attaccante sulla rete potrebbe eliminare STARTTLS o presentare un certificato falso. DANE per SMTP (RFC 7672) chiude questa falla: pubblichi nel DNS un record TLSA che indica quale certificato o chiave usa il tuo server di posta, e DNSSEC dimostra che quel record è autentico. I server di invio che supportano DANE rifiutano quindi di consegnare senza un TLS valido e corrispondente.

Un record TLSA per un server di posta si pubblica su _25._tcp. seguito dal nome host dell'MX:

_25._tcp.mail.yourdomain.com. IN TLSA 3 1 1 8f1c...e4a2

I tre numeri significano: 3 = il certificato del server stesso (DANE-EE), 1 = confronta solo la chiave pubblica (non l'intero certificato), 1 = hash SHA-256. 3 1 1 è la scelta abituale per SMTP.

DANE e MTA-STS risolvono lo stesso problema in modi diversi. MTA-STS usa HTTPS e funziona senza DNSSEC; DANE richiede DNSSEC. Puoi pubblicarli entrambi e usare TLS-RPT (trattato nella guida MTA-STS) per ricevere report per tutti e due.

Perché succede

Potresti configurare DANE perché:

• un audit di sicurezza, una norma pubblica o di settore, o un test del tipo internet.nl lo richiede (frequente nei Paesi Bassi e in Germania);
• vuoi proteggere la posta in arrivo dagli attacchi di downgrade;
• un test DANE segnala che il tuo record TLSA non corrisponde più dopo il rinnovo di un certificato, e per questo i mittenti DANE smettono di consegnarti la posta.

Come verificare

1. DNSSEC: la zona del nome host del tuo MX deve essere firmata. Con dig, cerca il flag ad da un resolver che esegue la validazione:

   dig +dnssec MX yourdomain.com @1.1.1.1
   ;; flags: qr rd ra ad;

   Se l'MX punta all'host del tuo provider (Google, Microsoft 365...), è la loro zona che deve avere DNSSEC e TLSA, non la tua.
2. Record TLSA:

   dig +dnssec TLSA _25._tcp.mail.yourdomain.com

3. Confronta con il certificato in uso:

   openssl s_client -connect mail.yourdomain.com:25 -starttls smtp \
     -servername mail.yourdomain.com </dev/null 2>/dev/null \
     | openssl x509 -noout -pubkey \
     | openssl pkey -pubin -outform DER | openssl dgst -sha256

   L'hash deve essere uguale all'ultimo campo del record TLSA.
4. Strumento di Postfix: posttls-finger -t30 -T180 -c -L verbose,summary yourdomain.com mostra se la validazione DANE riesce.
5. Usa lo scanner di domini per confermare i nomi host dei tuoi MX prima di iniziare.

Come risolvere

1. Attiva DNSSEC

Attiva DNSSEC presso il tuo provider DNS, poi aggiungi il record DS presso il tuo registrar (molti lo fanno automaticamente). Controlla con Whois quale registrar gestisce il dominio. Senza una catena DNSSEC valida, i record TLSA vengono ignorati.

2. Ottieni l'hash della chiave del server

Sul server di posta, a partire dal file del certificato in uso:

openssl x509 -in /etc/ssl/mail/fullchain.pem -noout -pubkey \
  | openssl pkey -pubin -outform DER | openssl dgst -sha256

3. Pubblica il record TLSA

Host:  _25._tcp.mail      (for MX host mail.yourdomain.com)
Type:  TLSA
Usage: 3   Selector: 1   Matching type: 1
Value: <the SHA-256 hex hash>

Pubblica un record per ogni nome host MX. Il certificato deve comunque essere un normale certificato valido con un nome corrispondente all'host, così i mittenti senza DANE e MTA-STS continuano a funzionare.

4. Pianifica i rinnovi dei certificati

È qui che si rompe la maggior parte delle configurazioni DANE. Con 3 1 1 l'hash segue la chiave, non il certificato, quindi:

• Rinnova i certificati mantenendo la stessa chiave privata (per esempio con l'opzione --reuse-key di Certbot), oppure
• Usa uno schema "attuale + successiva": genera in anticipo la chiave successiva, pubblica un secondo record TLSA per essa, attendi almeno due TTL, poi passa il server alla nuova chiave e rimuovi il vecchio record più tardi.

5. Valida DANE quando invii (facoltativo)

Se usi Postfix e un resolver locale che valida DNSSEC, attiva DANE per la posta in uscita in main.cf:

smtp_dns_support_level = dnssec
smtp_tls_security_level = dane

Per le basi di TLS sul tuo server, vedi email inviate senza TLS.

Verifica che sia risolto

Attendi la scadenza delle cache DNS, poi esegui di nuovo dig +dnssec TLSA (deve tornare con il flag ad), confronta l'hash con il certificato in uso ed esegui di nuovo posttls-finger. Invia un'email da una casella esterna al tuo dominio e controlla nel log di posta che la connessione sia avvenuta in TLS. Esegui anche un test Delivmail dal tuo server, per confermare che l'invio funziona ancora. Ricontrolla dopo ogni rinnovo del certificato.