SSTP și IKEv2 folosesc controale de certificat RRAS diferite

Dacă înlocuiți „certificatul VPN”, puteți schimba serviciul greșit. RRAS păstrează cel puțin trei controale de certificat, fiecare aparținând unui protocol și unui rol de conexiune diferite. Dacă numiți mai întâi protocolul, o presupunere riscantă devine o singură modificare reversibilă a legăturii. Tot ce urmează depinde de acea singură frază.

Numiți protocolul înainte de certificat

Un receptor SSTP prezintă un certificat TLS unui client care se comportă ca HTTPS. O conexiune IKEv2 site-la-site de intrare anunță o identitate de server și validează certificatele partenerilor față de o rădăcină de încredere. O definiție site-la-site pentru interfață poartă propria identitate de mașină.

Sunt trei controale cu trei domenii. Confundarea lor produce o modificare care pare să funcționeze pe un protocol și nu are niciun efect pe celălalt, ceea ce este mai rău decât un eșec evident. Notați ce protocol a eșuat, ce parte a prezentat certificatul și ce parte l-a respins înainte de a atinge ceva.

SSTP este o legătură HTTPS

Pentru implementările Remote Access acceptate, Set-RemoteAccess expune un parametru SslCertificate folosit pentru conectivitatea SSTP și pentru rolul DirectAccess legat de HTTPS.

Domeniul său de validare și implementare urmează configurația Remote Access, astfel încât o modificare a legăturii poate ajunge la mai mult de o conexiune sau un nod. Într-o implementare cu echilibrare a încărcării, acel domeniu include fiecare nod pe care îl acoperă configurația. Modificarea unui nod și testarea unui client lasă restul să prezinte vechiul certificat frunză, iar acesta este exact tipul de modificare pe jumătate care supraviețuiește unei ferestre de mentenanță.

Înainte de actualizare, verificați numele de serviciu așteptat, lanțul, valabilitatea, utilizarea prevăzută și disponibilitatea cheii private. Certificatul trebuie să corespundă numelui pe care îl va verifica clientul, iar o etichetă de adaptor nu este acel nume.

IKEv2 de intrare are propriul parametru

Set-VpnAuthProtocol configurează autentificarea IKEv2 site-la-site de intrare, iar CertificateAdvertised furnizează un certificat când modul de autentificare al tunelului le folosește. Nu este o comandă generală pentru a alege orice certificat de server de pe gazdă.

Țineți separate două obiecte: certificatul frunză pe care serverul îl prezintă ca identitate proprie și rădăcina pe care o folosește pentru a accepta certificatele partenerilor. Alegerea emitentului în care aveți încredere nu spune nimic despre certificatul frunză pe care îl prezintă serverul.

Identitatea unei interfețe site-la-site individuale se stabilește prin Set-VpnS2SInterface. Nu este automat certificatul SSTP, chiar și când ambele se află în același depozit pe aceeași mașină.

Inspectați mai întâi candidatul

O vizualizare concentrată a depozitului mașinii locale arată metadate publice fără a exporta nimic privat:

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

Acea listă este un punct de plecare, nu un test de adecvare. Inspectați intrările SAN, utilizările extinse ale cheii, lanțul și accesul contului de serviciu la cheia privată pentru protocolul pe care îl configurați.

Un certificat instalat pentru o identitate de client cloud fără legătură nu este adecvat doar pentru că apare în același depozit. Vizibilitatea nu este eligibilitate, iar o amprentă într-o captură de ecran nu dovedește nimic despre faptul dacă contul de serviciu poate citi cheia. Verificați explicit acel acces, deoarece o permisiune lipsă pentru cheie eșuează doar când serviciul repornește și încearcă să folosească certificatul.

Înregistrați legătura curentă și confirmați că puteți ajunge în continuare la gazdă pe altă cale înainte de a o schimba. Calea de recuperare face parte din modificare, nu din incidentul care urmează.

Reînnoirea nu este activare

Reemiterea unui certificat este o acțiune diferită de selectarea lui pentru serviciul care rulează. Noul certificat frunză poate păstra identitatea DNS dorită și totuși purta o amprentă diferită, așa că nimic nu indică spre el până când legătura nu este actualizată. Reînnoirea schimbă obiectul; activarea schimbă referința la el. Confundarea celor două este motivul pentru care un certificat reînnoit corect poate sta nefolosit săptămâni întregi.

Aplicați modificarea acceptată într-o fereastră adecvată, inclusiv orice repornire documentată, apoi inspectați certificatul dintr-o conexiune nouă a protocolului dorit. O sesiune de client din cache poate afișa în continuare vechiul certificat frunză și poate face o modificare corectă să pară stricată.

Retrageți certificatul anterior prin procesul normal numai după ce acea verificare trece. Referința Set-RemoteAccess documentează domeniul parametrului SSL, inclusiv efectul său în implementările cu echilibrare a încărcării, iar aceasta este partea care merită citită înainte de o modificare a legăturii.