SSTP e IKEv2 usan controis de certificado RRAS diferentes

Se substitúe «o certificado VPN», pode cambiar o servizo incorrecto. RRAS mantén polo menos tres controis de certificado, cada un pertence a un protocolo e a un rol de conexión diferentes. Nomear primeiro o protocolo converte unha suposición arriscada nun único cambio de vinculación reversible. Todo o seguinte depende desa única frase.

Nomea o protocolo antes do certificado

Un oínte SSTP presenta un certificado TLS a un cliente que se comporta como HTTPS. Unha conexión IKEv2 de sitio a sitio entrante anuncia unha identidade de servidor e valida os certificados dos pares contra unha raíz de confianza. Unha definición de sitio a sitio por interface leva a súa propia identidade de máquina.

Son tres controis con tres ámbitos. Confundilos produce un cambio que parece funcionar nun protocolo e non ten efecto no outro, o que é peor ca un fallo evidente. Anote que protocolo fallou, que lado presentou o certificado e que lado o rexeitou antes de tocar nada.

SSTP é unha vinculación HTTPS

Nas implementacións de Remote Access compatibles, Set-RemoteAccess expón un parámetro SslCertificate usado para a conectividade SSTP e para o rol DirectAccess relacionado con HTTPS.

O seu ámbito de validación e despregamento segue a configuración de Remote Access, polo que un cambio de vinculación pode chegar a máis dunha conexión ou nodo. Nunha implementación con balanceo de carga ese ámbito inclúe cada nodo que cobre a configuración. Cambiar un nodo e probar un cliente deixa o resto presentando o certificado folla antigo, e este é o tipo de cambio a medias que sobrevive a unha ventá de mantemento.

Antes da actualización, verifique o nome de servizo esperado, a cadea, a validez, o uso previsto e a dispoñibilidade da clave privada. O certificado ten que coincidir co nome que comprobará o cliente, e unha etiqueta de adaptador non é ese nome.

O IKEv2 entrante ten o seu propio parámetro

Set-VpnAuthProtocol configura a autenticación IKEv2 de sitio a sitio entrante, e CertificateAdvertised fornece un certificado cando o modo de autenticación do túnel os usa. Non é un comando xeral para escoller calquera certificado de servidor no host.

Manteña separados dous obxectos: o certificado folla que o servidor presenta como identidade propia e a raíz que usa para aceptar os certificados dos pares. Escoller en que emisor confía non di nada sobre que certificado folla presenta o servidor.

A identidade dunha interface de sitio a sitio individual establécese mediante Set-VpnS2SInterface. Non é automaticamente o certificado SSTP, aínda cando ambos estean no mesmo almacén na mesma máquina.

Inspecciona primeiro o candidato

Unha vista centrada no almacén da máquina local mostra metadatos públicos sen exportar nada privado:

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

Esa listaxe é un punto de partida e non unha proba de idoneidade. Inspeccione as entradas SAN, os usos estendidos da clave, a cadea e o acceso da conta de servizo á clave privada para o protocolo que está a configurar.

Un certificado instalado para unha identidade de cliente na nube sen relación non é axeitado só porque aparece no mesmo almacén. A visibilidade non é idoneidade, e unha impresión dixital nunha captura de pantalla non proba nada sobre se a conta de servizo pode ler a clave. Comprobe ese acceso explicitamente, porque un permiso de clave ausente só falla cando o servizo se reinicia e tenta usar o certificado.

Rexistre a vinculación actual e confirme que aínda pode chegar ao host doutro xeito antes de cambiala. A ruta de recuperación forma parte do cambio, non do incidente que vén despois.

Renovar non é activar

Reemitir un certificado é unha acción distinta de seleccionalo para o servizo en execución. O novo certificado folla pode conservar a identidade DNS prevista e aínda así levar unha impresión dixital diferente, polo que nada apunta a el ata que se actualice a vinculación. A renovación cambia o obxecto; a activación cambia a referencia a el. Confundir as dúas é a razón pola que un certificado renovado correctamente pode quedar sen usar durante semanas.

Aplique o cambio compatible nunha ventá axeitada, incluído calquera reinicio documentado, e despois inspeccione o certificado desde unha conexión nova do protocolo previsto. Unha sesión de cliente na caché pode seguir mostrando o certificado folla antigo e facer que un cambio correcto pareza roto.

Retire o certificado anterior mediante o proceso normal só despois de que esa comprobación pase. A referencia de Set-RemoteAccess documenta o ámbito do parámetro SSL, incluído o seu efecto nas implementacións con balanceo de carga, e esa é a parte que paga a pena ler antes dun cambio de vinculación.