SSTP e IKEv2 usan controles de certificado de RRAS distintos

Sustituya «el certificado VPN» y puede que cambie el servicio equivocado. RRAS mantiene al menos tres controles de certificado, cada uno perteneciente a un protocolo y a un rol de conexión diferentes. Nombrar primero el protocolo convierte una suposición arriesgada en un solo cambio de enlace reversible. Todo lo que sigue depende de esa única frase.

Nombra el protocolo antes que el certificado

Un agente de escucha SSTP presenta un certificado TLS a un cliente que se comporta como HTTPS. Una conexión IKEv2 de sitio a sitio entrante anuncia una identidad de servidor y valida los certificados de los pares contra una raíz de confianza. Una definición de sitio a sitio por interfaz lleva su propia identidad de máquina.

Son tres controles con tres ámbitos. Confundirlos produce un cambio que parece funcionar en un protocolo y no tiene efecto en el otro, lo que es peor que un fallo evidente. Anote qué protocolo falló, qué lado presentó el certificado y qué lado lo rechazó antes de tocar nada.

SSTP es un enlace HTTPS

Para las implementaciones de Remote Access compatibles, Set-RemoteAccess expone un parámetro SslCertificate que se utiliza para la conectividad SSTP y para el rol DirectAccess relacionado con HTTPS.

Su ámbito de validación y despliegue sigue la configuración de Remote Access, por lo que un cambio de enlace puede llegar a más de una conexión o nodo. En una implementación con equilibrio de carga, ese ámbito incluye todos los nodos que cubre la configuración. Cambiar un nodo y probar un cliente deja al resto presentando el certificado hoja antiguo, que es el tipo de cambio a medias que sobrevive a una ventana de mantenimiento.

Verifique el nombre de servicio esperado, la cadena, la validez, el uso previsto y la disponibilidad de la clave privada antes de la actualización. El certificado tiene que coincidir con el nombre que comprobará el cliente, y una etiqueta de adaptador no es ese nombre.

El IKEv2 entrante tiene su propio parámetro

Set-VpnAuthProtocol configura la autenticación IKEv2 de sitio a sitio entrante, y CertificateAdvertised suministra un certificado cuando el modo de autenticación del túnel los utiliza. No es un comando general para elegir cualquier certificado de servidor del host.

Mantenga separados dos objetos: el certificado hoja que el servidor presenta como identidad propia y la raíz que utiliza para aceptar certificados de los pares. Elegir qué emisor confía no dice nada sobre qué certificado hoja presenta el servidor.

La identidad de una interfaz de sitio a sitio individual se establece mediante Set-VpnS2SInterface. No es automáticamente el certificado SSTP, aunque ambos estén en el mismo almacén de la misma máquina.

Inspecciona primero el candidato

Una vista centrada del almacén de la máquina local muestra metadatos públicos sin exportar nada privado:

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

Ese listado es un punto de partida y no una prueba de idoneidad. Inspeccione las entradas SAN, los usos extendidos de clave, la cadena y el acceso de la cuenta de servicio a la clave privada para el protocolo que está configurando.

Un certificado instalado para una identidad de cliente en la nube sin relación no es adecuado solo porque aparezca en el mismo almacén. La visibilidad no es elegibilidad, y una huella en una captura de pantalla no demuestra nada sobre si la cuenta de servicio puede leer la clave. Compruebe ese acceso de forma explícita, porque un permiso de clave ausente solo falla cuando el servicio se reinicia e intenta usar el certificado.

Registre el enlace actual y confirme que aún puede llegar al host de otra manera antes de cambiarlo. La ruta de recuperación forma parte del cambio, no del incidente que viene después.

Renovar no es activar

Reemitir un certificado es una acción distinta de seleccionarlo para el servicio en ejecución. El nuevo certificado hoja puede conservar la identidad DNS prevista y aun así llevar una huella diferente, de modo que nada apunta a él hasta que se actualiza el enlace. La renovación cambia el objeto; la activación cambia la referencia a él. Confundir ambas es la razón por la que un certificado renovado correctamente puede quedar sin usar durante semanas.

Aplique el cambio compatible en una ventana adecuada, incluido cualquier reinicio documentado, y luego inspeccione el certificado desde una conexión nueva del protocolo previsto. Una sesión de cliente en caché puede seguir mostrando el certificado hoja antiguo y hacer que un cambio correcto parezca roto.

Retire el certificado anterior mediante el proceso normal solo después de que pase esa comprobación. La referencia de Set-RemoteAccess documenta el ámbito del parámetro SSL, incluido su efecto en implementaciones con equilibrio de carga, que es la parte que conviene leer antes de un cambio de enlace.