Distingue la scadenza dal fallimento della catena di fiducia, preserva l'endpoint segnalato e convalida il certificato effettivamente fornito dopo il rinnovo.
Leggi con precisione la categoria dei risultati
Riferimenti: RFC 8460 §4.3.1, RFC 8460 §4.3.2.
certificato scaduto significa che chi ha segnalato ha osservato un certificato scaduto. certificate-not-trusted copre diverse condizioni, tra cui autorità di certificazione sconosciute, errori di catena e vincoli sui nomi. Il codice del motivo dell'errore può restringere la diagnosi ma è un testo fornito dal reporter, non un contratto del parser universale. Non etichettare ogni rapporto certificato non attendibile come intermedio mancante senza prove. Iniziare con il contesto della policy e segnalare l'endpoint di ricezione in modo che un problema relativo al certificato SMTP non venga confuso con sts-webpki-invalid su un MTA-STS Host dei criteri HTTPS.
Controlla il certificato che ha raggiunto il mittente
Un gestore di certificati che mostra un certificato rinnovato non stabilisce che ogni ascoltatore SMTP lo serva. Registra il numero di serie o l'impronta digitale, l'intervallo di validità, la catena e il timestamp del test dall'effettivo controllo dell'endpoint autorizzato. Confronta questi valori attraverso i percorsi di ricezione implicati dai report. Un processo obsoleto, un host di backup dimenticato o una distribuzione incompleta del sistema di bilanciamento del carico possono lasciare attivi i vecchi certificati. Rivedere la precisione dell'orologio quando i limiti di validità appaiono incoerenti, ma non modificare gli orologi o fidarsi dei negozi semplicemente per superare un test fallito.
Riprodurre un problema di sovrapposizione dei rinnovi
L'esercizio sintetico definisce un vecchio certificato valido fino a t=100 ed uno nuovo valido da t=90 fino a t=200. A t=110, un ascoltatore che sta ancora servendo il vecchio certificato fallisce il controllo della finestra di validità del modello, mentre un ascoltatore che serve il nuovo certificato lo supera. Ciò riproduce la distinzione di distribuzione senza generare un certificato reale. Non dimostra la fiducia della catena, la corrispondenza dei nomi, il comportamento di revoca o le convenzioni di confine dell'implementazione. Questi necessitano di un vero validatore TLS e di prove di endpoint controllate.
Investigare la fiducia senza aggirarla
Riferimenti: RFC 8461 §4.2, RFC 7672 §3.1.1.
Cattura la foglia e la catena intermedia servita, quindi confronta la ragione del reporter con un ambiente di test mantenuto. Un emittente considerato attendibile da un computer locale potrebbe non essere accettato dal mittente interessato. Elementi intermedi mancanti, un certificato autofirmato imprevisto e un vincolo specifico della policy sono riparazioni diverse. Documentare il modello di convalida selezionato. SMTP DANE con l'utilizzo di DANE-EE ha una semantica di fiducia diversa rispetto a Web PKI, quindi una conclusione in stile STS sulle autorità di certificazione pubbliche non può essere semplicemente applicata a ogni TLSA rapporto.
Chiudi il cerchio su distribuzione e reporting
Riferimenti: RFC 8460 §4.1.
Applicare il rinnovo approvato o la correzione a catena a ciascun ascoltatore interessato, verificare il comportamento di ricarica e conservare la prova del certificato presentato dopo la modifica. Confronta i report i cui periodi di osservazione cadono dopo la riparazione e tiene conto dei ritardi di aggregazione. Pianifica il monitoraggio del rinnovo con tempi di consegna sufficienti per la proprietà e l'implementazione e monitora separatamente se il nuovo certificato viene effettivamente distribuito. Non ridurre automaticamente l'applicazione di una policy di trasporto per nascondere gli errori dei certificati. Questa guida registra solo i test di laboratorio controllati; non rinnova i certificati di produzione, non altera gli archivi fiduciari della produzione né dimostra il ripristino della produzione.
Conservate prove storiche e controlli attuali
Le osservazioni di trasporto riportate di seguito sono state acquisite il 7 novembre 2026 e ispezionate, non rieseguite come test di rete, per questa revisione. I nuovi controlli del modello offline vengono registrati separatamente.
L'acquisizione di loopback conservata include un certificato firmato dalla CA del laboratorio attendibile la cui validità è terminata prima del test; fallisce con il codice di verifica 10, il certificato è scaduto. Una foglia autofirmata separata fallisce con il codice di verifica 18, certificato autofirmato. Il controllo valido ha esito positivo con lo stesso nome host previsto. Le prove dell'handshake con timestamp e i certificati pubblici vengono conservati, consentendo di ispezionare separatamente la scadenza e i fallimenti di fiducia. Le chiavi private sono temporanee e rimosse. L'implementazione effettiva del rinnovo del servizio e la verifica della distribuzione di tutti gli ascoltatori rimangono al di fuori di questo lab. Il trasportatore storico richiede Python con crittografia e socket di loopback. I suoi risultati sono prove di laboratorio limitate, non lo stato attuale dei servizi o l’interoperabilità della produzione.
Base della fonte primaria
Da qui provengono le definizioni dei campi e i limiti di reporting RFC 8460 , Reporting TLS SMTP, sezioni 3 e 4. Quando si discute della convalida STS, consultare RFC 8461. Le raccomandazioni operative si distinguono dai requisiti del protocollo.