SSTP e IKEv2 usano controlli dei certificati RRAS diversi

Sostituite «il certificato VPN» e potreste cambiare il servizio sbagliato. RRAS mantiene almeno tre controlli dei certificati, ciascuno appartenente a un protocollo e a un ruolo di connessione diversi. Nominare prima il protocollo trasforma una supposizione rischiosa in un singolo cambiamento di binding reversibile. Tutto ciò che segue dipende da quella sola frase.

Nomina il protocollo prima del certificato

Un listener SSTP presenta un certificato TLS a un client che si comporta come HTTPS. Una connessione IKEv2 site-to-site in entrata annuncia un’identità del server e convalida i certificati dei peer rispetto a una radice attendibile. Una definizione site-to-site per interfaccia porta una propria identità macchina.

Sono tre controlli con tre ambiti. Confonderli produce un cambiamento che sembra funzionare su un protocollo e non ha effetto sull’altro, cosa peggiore di un errore evidente. Annotate quale protocollo ha fallito, quale lato ha presentato il certificato e quale lato lo ha rifiutato prima di toccare qualsiasi cosa.

SSTP è un binding HTTPS

Per le distribuzioni Remote Access supportate, Set-RemoteAccess espone un parametro SslCertificate usato per la connettività SSTP e per il ruolo DirectAccess correlato a HTTPS.

Il suo ambito di convalida e distribuzione segue la configurazione di Remote Access, quindi un cambiamento di binding può raggiungere più di una connessione o di un nodo. In una distribuzione con bilanciamento del carico tale ambito include ogni nodo coperto dalla configurazione. Cambiare un nodo e testare un client lascia gli altri che presentano la vecchia foglia, ed è il tipo di modifica a metà che sopravvive a una finestra di manutenzione.

Verificate il nome del servizio previsto, la catena, la validità, l’uso previsto e la disponibilità della chiave privata prima dell’aggiornamento. Il certificato deve corrispondere al nome che il client controllerà, e un’etichetta di adattatore non è quel nome.

L’IKEv2 in entrata ha un proprio parametro

Set-VpnAuthProtocol configura l’autenticazione IKEv2 site-to-site in entrata, e CertificateAdvertised fornisce un certificato quando la modalità di autenticazione del tunnel li usa. Non è un comando generale per scegliere qualsiasi certificato del server sull’host.

Tenete separati due oggetti: la foglia che il server presenta come propria identità e la radice che usa per accettare i certificati dei peer. Scegliere quale emittente considerare attendibile non dice nulla su quale foglia presenti il server.

L’identità di una singola interfaccia site-to-site viene impostata tramite Set-VpnS2SInterface. Non è automaticamente il certificato SSTP, anche quando entrambi si trovano nello stesso archivio sulla stessa macchina.

Esamina prima il candidato

Una vista mirata dell’archivio del computer locale mostra i metadati pubblici senza esportare nulla di privato:

Get-ChildItem Cert:\LocalMachine\My |
    Select-Object Thumbprint, Subject, HasPrivateKey, NotAfter

Quell’elenco è un punto di partenza e non un test di idoneità. Esaminate le voci SAN, gli usi estesi della chiave, la catena e l’accesso dell’account di servizio alla chiave privata per il protocollo che state configurando.

Un certificato installato per un’identità client cloud non correlata non è adatto solo perché compare nello stesso archivio. La visibilità non è idoneità, e un’impronta in uno screenshot non dimostra nulla sulla capacità dell’account di servizio di leggere la chiave. Verificate esplicitamente tale accesso, perché un’autorizzazione mancante sulla chiave fallisce solo quando il servizio si riavvia e tenta di usare il certificato.

Registrate il binding attuale e confermate di poter ancora raggiungere l’host in un altro modo prima di cambiarlo. Il percorso di ripristino fa parte del cambiamento, non dell’incidente che segue.

Il rinnovo non è l’attivazione

Riemettere un certificato è un’azione diversa dal selezionarlo per il servizio in esecuzione. La nuova foglia può mantenere l’identità DNS prevista e portare comunque un’impronta diversa, quindi nulla la punta finché il binding non viene aggiornato. Il rinnovo cambia l’oggetto; l’attivazione cambia il riferimento a esso. Confondere i due è il motivo per cui un certificato rinnovato correttamente può restare inutilizzato per settimane.

Applicate il cambiamento supportato in una finestra adeguata, incluso qualsiasi riavvio documentato, poi esaminate il certificato da una nuova connessione del protocollo previsto. Una sessione client in cache può ancora mostrare la vecchia foglia e far sembrare guasto un cambiamento corretto.

Ritirate il certificato precedente tramite il processo normale solo dopo che tale controllo è passato. Il riferimento a Set-RemoteAccess documenta l’ambito del parametro SSL, incluso il suo effetto nelle distribuzioni con bilanciamento del carico, che è la parte da leggere prima di un cambiamento di binding.