Quando DANE la consegna inizia a fallire dopo una modifica del certificato, stabilire innanzitutto se la chiave è cambiata, se il TLSA l'associazione utilizza quella chiave e quale certificato effettivamente serve ciascun destinatario. Un avviso di certificato generico può nascondere a DNSSEC fallimento, un errore selettore o un'implementazione parziale. Correggere il livello sbagliato può lasciare la posta in coda rendendo le prove più difficili da interpretare.
Preservare l'osservazione fallimentare
Riferimenti: RFC 7672 §2, RFC 7672 §3.
Registra l'implementazione del mittente, il timestamp, il dominio del destinatario, l'host MX selezionato, la porta, l'IP di ricezione e l'errore osservato. Conserva il risultato della convalida DNSSEC e la relativa risposta TLSA insieme al certificato o alla sua impronta pubblica. Se il mittente riprova con un altro host, tienilo come osservazione separata. Una dashboard che riepiloga l'intero dominio non può sostituire l'evidenza a livello di endpoint.
Distinguere il fallimento dell'handshake dal fallimento dell'autenticazione dopo un handshake. Un timeout di rete non dimostra che il digest TLSA non corrispondesse. Al contrario, la ricezione di un certificato non dimostra né una catena DNSSEC affidabile né un’autenticazione DANE riuscita. RFC 7672 definisce separatamente le fasi di rilevamento e convalida. RFC 7672 sezioni 2 e 3.
Controlla l'utilizzo e il selettore prima di confrontare i byte
Riferimenti: RFC 6698 §2.1.2, RFC 6698 §2.1.3, RFC 7672 §4.
Per un'associazione 3 1 1, estrarre il DER SPKI del certificato servito e calcolare SHA-256. Un rinnovo del certificato che riutilizza la stessa chiave può lasciare invariato questo digest. Una rotazione chiave non può. Con un selettore di certificato completo, un certificato rinnovato modifica l'associazione anche se la chiave viene mantenuta. Non utilizzare l'impronta digitale del certificato del browser in modo intercambiabile con un'impronta digitale SPKI.
Il dispositivo OpenSSL conservato del 7 novembre 2026, ispezionato ma non rieseguito qui, ha creato certificati A e B con chiavi diverse e una ristampa A2 con la chiave di A. I suoi calcoli registrati mostrano che A e A2 condividono il digest SPKI selezionato mentre B differisce. Quindi confronta deliberatamente B con l'associazione di A e registra il fallimento. Il test utilizza byte di certificato realmente generati, ma è una prova sintetica locale piuttosto che un incidente di produzione catturato.
Ricostruire i tempi DNS ed endpoint
Riferimenti: RFC 7671 §8.1, RFC 7672 §2.1.
Confrontare il tempo di attivazione della nuova chiave con la pubblicazione del set di associazioni sovrapposte e la scadenza dei dati memorizzati nella cache precedenti. Se B è stato distribuito mentre un mittente conservava record solo A, un mittente corretto può rifiutare B. Interrogare DNS autorevole dopo l'incidente e vedere B non smentisce lo stato precedente della cache.
Controlla tutti i backend e le famiglie di indirizzi. Un server che non è riuscito a ricaricarsi potrebbe mantenere A mentre altri server utilizzano B. Un set TLSA solo nuovo fallirebbe quindi solo una parte del traffico. I fallimenti DNSSEC hanno un'altra sequenza temporale: le firme, la delega e la convalida del risolutore devono essere esaminate senza trattare con disinvoltura i dati fasulli come non firmati. RFC 7672 sezioni 2.1 e 4.
Ripristina la coerenza anziché disabilitare i controlli
Riferimenti: RFC 7672 §3.1.1, RFC 7672 §4.
Laddove la chiave non sia compromessa, potrebbe essere opportuno ripristinare un certificato precedentemente coperto o associazioni correttamente sovrapposte, in base allo stato effettivo della cache e di implementazione. Coordina i proprietari di posta e DNS e verifica la riparazione dal lato mittente. Non dare per scontato che l'eliminazione di TLSA rimuoverà immediatamente i requisiti memorizzati nella cache e non convertirà un errore di sicurezza in una consegna non autenticata come soluzione alternativa predefinita.
Per DANE-EE, non importare tutte le regole PKIX del browser nella diagnosi: l'utilizzo del certificato ha una semantica di autenticazione specifica, incluso l'assenza di requisiti di corrispondenza del nome del certificato e la scadenza del certificato ignorata per l'utilizzo di DANE-EE 3 in RFC 7672 §3.1.1. Non estendere questa regola specifica a ogni utilizzo TLSA. Ciò non giustifica i certificati operativi scaduti laddove altri mittenti utilizzano PKIX o MTA-STS. Separatamente, le prove di revisione conservate del 7 novembre 2026 contengono un loopback con timestamp STARTTLS sessioni. Le sessioni sono state controllate ma non rieseguite per questa revisione. Un client controllato osserva il certificato B su una porta 127.0.0.1 registrata, estrae il peer SPKI e rifiuta un'associazione di sola A. Il controllo A-plus-B corretto per la sovrapposizione accetta il percorso. Separatamente, la verifica del certificato Python/OpenSSL rifiuta B rispetto al materiale attendibile A, mentre A ha successo. Il pacchetto di revisione privata conserva sette trascrizioni e byte di certificato peer per i quattro casi che raggiungono l'acquisizione del certificato. I casi di handshake non riuscito e no-STARTTLS non contengono byte del certificato peer acquisiti. Si tratta di un piccolo client di laboratorio con input TLSA configurati, non di un risultato o di una produzione DNSSEC Internet MTA incidente. Nessun messaggio è stato inviato; l'accettazione della produzione necessita ancora dell'endpoint previsto e della traccia del mittente.