Renovar un certificado VPN sen cambiar a súa identidade

Unha renovación de certificado que cambia a identidade non é unha renovación, é unha migración cunha etiqueta de mantemento. O cliente verifica un nome, unha cadea e ás veces unha clave específica, e os tres poden cambiar sen que cambie a data de caducidade. Antes de solicitar unha substitución, anota o que o cliente comproba realmente: o nome de host ou a identidade do par, o propósito do certificado, a política de claves e a cadea emisora. A renovación é rutineira ou coordinada segundo cal deses elementos altere a substitución.

Tres condicións deciden a forma da renovación

As tres condicións son se algo fixa a folla, se cambia a cadea e quen máis valida o nome. Respóndeas desde o lado do cliente e non desde a comodidade da CA, porque o cliente é o que falla ás tres da mañá.

Comeza inspeccionando o certificado que tes. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName imprime o suxeito, o emisor, a xanela de validez e os nomes para os que o certificado é realmente válido. Ese último campo é o máis importante e o que máis se dá por suposto: unha solicitude de renovación que omite un SAN no que o cliente confía produce un certificado tecnicamente válido e funcionalmente incorrecto. Copia a lista de SAN do certificado antigo na solicitude en vez de escribila de novo de memoria.

Condición unha: hai algo que fixe a folla

Se os clientes confían nunha CA mantida e validan o nome, unha renovación de folla cunha clave nova é invisible para eles. Se algún cliente fixa o certificado de folla, a súa impresión dixital ou a súa clave pública, a substitución é un cambio coordinado cunha transición dura, porque a fixación antiga non pode validar o certificado novo.

Averigua en que caso estás antes de encargar nada. Unha fixación que ninguén documentou segue sendo unha fixación cando falla.

Condición dous: compara as fixacións e a cadea

As impresións dixitais fan que a fixación sexa comprobable: openssl x509 -noout -fingerprint -sha256 -in server.crt no certificado antigo e no novo, e openssl x509 -noout -pubkey para comparar as claves públicas. Se a configuración do cliente, un perfil móbil ou un almacén de confianza dun aparello contén calquera dos dous valores, tes unha fixación. Os perfís VPN móbiles son un escondedoiro habitual, porque o perfil distribúese unha vez e nunca máis se inspecciona.

Se a substitución procede do mesmo intermedio e o cliente xa ten ese intermedio ou pode obtelo, nada cambia no lado da confianza. Un intermedio novo, un emisor diferente ou unha cadea entregada na orde incorrecta converten unha renovación nun cambio de confianza, e o fallo parece un emisor descoñecido en vez dun certificado caducado.

Comproba a cadea que o servidor envía realmente con openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, e verifícaa localmente con openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Facelo antes do cambio dache unha liña base coa que comparar despois.

Condición tres: quen máis valida o nome

Un concentrador VPN, un balanceador de carga, unha sonda de monitorización, unha integración RADIUS ou SAML e un perfil móbil poden ter cada un a súa propia copia do nome esperado ou da áncora de confianza. A renovación é o momento en que esas copias diverxen, porque o certificado cambia e as copias non.

Enumera todos os consumidores antes do cambio e decide, para cada un, se precisa unha actualización. O que esquezas é o que che avisará pola noite.

Tamén hai unha trampa de tempos. Inspecciona o inicio da validez ademais da caducidade, porque un certificado preparado para unha activación posterior é rexeitado se se instala demasiado pronto, e o erro parece un problema de reloxo en vez dun problema de preparación. openssl x509 -noout -dates no ficheiro novo antes de despregalo é unha comprobación de dous segundos. Mantén tamén unha vía de recuperación soportada e a configuración boa coñecida, para que unha renovación que saia mal sexa reversible restaurando o certificado e a clave anteriores.

Despregar, verificar cunha autenticación nova e despois retirar

Un túnel establecido reflicte a validación que ocorreu cando se construíu, así que pode parecer san mentres todas as conexións novas fallan. Proba cunha autenticación nova usando o nome de servizo real que usan os clientes.

Completa a comprobación de nivel de aplicación que lle importa ao usuario, e confirma a entrega da cadea desde a perspectiva do cliente en vez de desde a do servidor. Non suprimas as comprobacións de nome ou de certificado para manter a transición en silencio; iso converte un problema de compatibilidade temporal nun problema permanente.

Retira o material obsoleto só despois de verificar o despregamento, e trata unha clave comprometida como un caso totalmente distinto: a renovación por si soa non revoga nada, así que a identidade afectada necesita o proceso de revogación e de xestión de sesións do despregamento. RFC 5280 define as regras de certificado e de validación de camiño que subxacen a todo isto. Mantén unha renovación de folla rutineira separada dunha substitución de CA, para que non se lle pida ao cliente confiar nun emisor novo sen motivo.