Rendere il rinnovo un compito di continuità del servizio
Rinnovare il certificato HTTPS per un MTA-STS l'host della politica è completo solo quando il certificato corretto viene effettivamente fornito all'endpoint richiesto e un client di convalida può recuperare la politica. Una notifica di emissione riuscita non stabilisce la distribuzione, la completezza della catena di fiducia o la disponibilità. Organizzare il lavoro in base al servizio in esecuzione anziché all'ordine dei certificati.
Questa guida propone un controllo del rinnovo e una revisione fittizia dei fallimenti. Non emette certificati, non ispeziona chiavi private, non modifica l'hosting né si connette al dominio del cliente. Sono ancora necessari il certificato originale e le osservazioni HTTP. I proprietari dovrebbero concordare la procedura approvata di distribuzione e ripristino prima che un operatore tocchi il servizio.
Inventariare le due superfici del certificato
Il certificato policy-host autentica un nome come mta-sts.example.com durante il recupero HTTPS. I server SMTP riceventi presentano certificati separati per i loro nomi host MX . Tali servizi possono avere proprietari, sistemi di rinnovo e date di scadenza diversi. Rinnovarne uno non risolve l'altro, anche quando entrambi sono gestiti dallo stesso provider di hosting. RFC 8461 sezioni 3.3 e 4.2
Registra il nome host della policy, il team responsabile, la piattaforma di distribuzione, l'attuale impronta digitale del certificato pubblico, l'intervallo di validità e il meccanismo di rinnovo previsto. Includi ogni indirizzo o livello di servizio che può rispondere per l'endpoint. NotBefore e notAfter di un certificato ne delimitano il periodo di validità, mentre la convalida del percorso dipende anche da altri vincoli e attendibilità del certificato. Una data di scadenza apparentemente futura da sola non è un risultato di validazione positivo. RFC 5280 sezioni 4.1.2.5 e 6
Verificare l'identità e la catena prima della distribuzione
L'host della politica deve presentare un certificato non scaduto valido per l'identità DNS richiesta e concatenato a una radice attendibile dall'invio MTA. Delegare l'hosting tramite a CNAME non rende sufficiente un certificato per il nome host del provider. Conserva il nome host della policy originale nei test di convalida e documenta quale catena pubblica è previsto che il server invii. RFC 8461 sezioni 3.3 e 8.2
Utilizzare i nomi alternativi dell'oggetto del certificato durante la valutazione dell'identità del servizio prevista. RFC 9525 è l'attuale specifica generale dell'identità del servizio e rende obsoleta RFC 6125 citata dalla RFC 8461 . Mantenere esplicite le regole DNS-ID specifiche dell'applicazione di MTA-STS anziché sostituire silenziosamente il comportamento dell'applicazione non correlata. Un nome comune leggibile dall'uomo non è un motivo per rinunciare a una mancata corrispondenza del nome host. RFC 9525 sezioni 2 e 6
Pianificare il tempo sufficiente per recuperare in sicurezza
Scegli una scadenza di rinnovo interna che lasci tempo per emissioni non riuscite, errori di distribuzione e verifica. Il margine appropriato dipende dalla durata del certificato e dalla proprietà operativa; qui non viene stabilito alcun numero universale di giorni. Assegnare una persona responsabile e un contatto di riserva. Un lavoro pianificato senza una destinazione di avviso o un proprietario è una dipendenza non verificata, non un processo di rinnovo completo.
Mantieni la gestione dei certificati all'interno del sistema di gestione dei segreti approvato. Il pacchetto di prove deve contenere i dettagli del certificato pubblico e l'output di convalida, non le chiavi private o le credenziali dell'account. Definire cosa l'operatore può eseguire il rollback, come verrà verificata la validità attuale e quali errori richiedono un'escalation. Il ripristino di un certificato scaduto perché era la configurazione nota di ieri non è un piano di ripristino utile.
Testare l'endpoint distribuito anziché il file del certificato
Dopo una distribuzione autorizzata, il controllo proposto dovrebbe identificare l'esatto nome host, l'indirizzo, l'ora UTC, la catena osservata, il risultato della convalida del nome e l'esito dell'attendibilità. Laddove esistono più nodi di servizio, mantenere l'ambito effettivamente controllato. Il test locale riuscito di un operatore non può dimostrare che ogni mittente esterno si fida della stessa radice o raggiunge lo stesso nodo. Registra questi limiti invece di convertire un’osservazione in prontezza universale.
Quindi verificare che l'URL noto originale produca un HTTP 200 diretto con la policy prevista. Il lavoro sui certificati può alterare accidentalmente la selezione dell'host virtuale, il routing o i controlli di accesso alle applicazioni. MTA-STS vieta di seguire i reindirizzamenti HTTP durante il recupero, quindi il successo del browser dopo il reindirizzamento è inadeguato. La connessione TLS valida e la risposta HTTP utilizzabile sono condizioni di accettazione distinte. RFC 8461 sezioni 3.2–3.3
Esaminare una distribuzione parziale fittizia
Consideriamo example.com fittizio, il cui nome host della policy è servito da due nodi edge. Un sistema di rinnovo ottiene un nuovo certificato, ma solo un nodo lo ricarica. L'altro continua a fornire un certificato scaduto. Un test che raggiunge il nodo aggiornato passa; un mittente che raggiunge il secondo nodo non può autenticare la policy. Queste osservazioni sono inventate e non stabiliscono alcun comportamento reale del fornitore.
L'indagine proposta confronta le impronte digitali pubbliche e gli intervalli di validità sui nodi di servizio, seguiti dal recupero autenticato sul nome host invariato. Non inizia con l'allentamento dei controlli dei certificati o con l'eliminazione del record di rilevamento. Il proprietario della riparazione completerà la distribuzione approvata e verificherà entrambi i nodi. I certificati MX SMTP necessitano ancora della propria convalida poiché la riparazione dell'host della policy non dice nulla sul loro stato.
Comprendere il limite della cache durante un'interruzione
Un mittente di supporto con una policy memorizzata nella cache valida e non scaduta deve continuare a utilizzarla se non è possibile recuperare la policy attiva. Un mittente senza tale policy continua come se MTA-STS fosse assente dopo un errore di recupero. La durata della cache fornisce pertanto un vantaggio di continuità limitato per alcuni mittenti, non l'autorizzazione a far scadere il certificato HTTPS. Mittenti diversi possono occupare legittimamente stati diversi durante la stessa interruzione. RFC 8461 sezione 3.3
L'ID di rilevamento identifica l'istanza della policy, non il numero di serie del certificato. Se cambia solo il certificato e l'organismo della policy rimane identico, non dare per scontato che sia necessario un nuovo ID per rendere effettivo il rinnovo. Se cambia anche la policy, segui l'ordine di aggiornamento del corpo prima dell'ID e tieni conto delle policy memorizzate nella cache. Mantieni la distribuzione del certificato e la revisione della policy come modifiche revisionabili separatamente. RFC 8461 sezioni 3.1 e 8.1
Conservare le prove per il prossimo rinnovo
Salva il record di distribuzione approvato, i dettagli pubblici del certificato prima e dopo, i risultati del recupero autenticati e qualsiasi altra cosa rilevante TLS-RPT osservazioni. Un errore PKI Web della policy rientra nell'indagine dell'endpoint della policy; la scadenza del certificato SMTP segnalata riguarda la connessione ricevente. Controlla quale categoria è stata effettivamente segnalata. RFC 8460 sezione 4.3
L'attuale registro degli errata RFC 8461 include una correzione delle maiuscole segnalata sui certificati MTA di ricezione scaduti; non ammette certificati scaduti. Qui non viene fornita alcuna prova originale del rinnovo o dell'hosting. Il cancello operativo finale rimane una dimostrazione con timestamp del servizio distribuito, esaminato dal suo proprietario. Errata RFC 8461