Que ocorre cando substitúe unha autoridade de certificación VPN

Substituír unha autoridade de certificación VPN non é cambiar un ficheiro. No momento en que a nova CA asina o seu primeiro certificado, cada validador que aínda só confía na antiga ten que decidir, e os hosts que nunca reciben a nova áncora seguen rexeitando pares bos. Vino fallar en ambos os sentidos: a pasarela aprendeu a nova CA e os clientes non, así que as conexións novas fallaban, mentres que os túneles xa levantados seguían en pé e facían que a avaría parecese un problema de encamiñamento. Velaquí que cambia, na orde en que aparecen os fallos.

Unha substitución, dous cambios separados

Unha autoridade de certificación é un nome, unha chave pública e a chave privada que asina. Os validadores nunca confían en «a CA» en abstracto. Confían nun certificado concreto que xa está nun almacén de confianza, e aceptan un emisor só se unha cadea de sinaturas chega ata esa copia gardada. Por iso substituír a CA cambia dúas cousas que fallan de forma independente: que áncoras se aceptan e que identidades de par se emitiron baixo elas.

A maioría dos despregamentos VPN validan en ambos os sentidos. O cliente autentica o certificado da pasarela, e a pasarela o do cliente. Unha rotación que só refresca o paquete do cliente deixa o servidor rexeitando todo cliente que aínda presente unha identidade da CA antiga, e o contrario é igual de habitual. Inventarie primeiro os puntos de aplicación: almacéns de confianza dos clientes, o ficheiro ca da pasarela, calquera proxy que remate TLS diante e a sonda que comproba o extremo desde fóra.

Que comproba un validador, por orde

A validación de ruta sobe desde o certificado do par polos intermedios ata alcanzar unha áncora de confianza. En cada paso verifica a sinatura, comproba que cada certificado está dentro da súa xanela de validez e confirma que as restricións básicas e o uso de chave permiten ao emisor asinar. Só entón a aplicación mira o certificado folla: os nomes alternativos do suxeito deben cubrir o nome marcado, e o uso estendido de chave debe permitir a autenticación de servidor ou de cliente.

Para repetir ese percorrido sen rede, apunte -CAfile ao paquete exacto que vai despregar e non ao almacén do sistema. Se non, está a probar o host, non o cambio:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

Ese comando só funciona contra un oínte TLS simple como a páxina de administración HTTPS da pasarela; a canle de control de OpenVPN precede TLS, así que s_client non pode inspeccionar o salto de mans do túnel.

As regras de construción de ruta que hai detrás deses erros están en RFC 5280 sección 6. Explícanos os fallos que doutro xeito parecen arbitrarios: un intermedio caducado que ninguén lembraba, un certificado cuxo uso de chave prohibe asinar ou unha restrición de nome que exclúe o host que proba.

Por que o túnel antigo segue funcionando

TLS e OpenVPN manteñen viva unha sesión establecida despois de que remate o salto de mans. Nada revalida o certificado do par por paquete, así que un cliente que se conectou antes do cambio segue pasando tráfico ata que renegocia, se reconecta ou o túnel cae. Ese oco é a razón de que unha substitución de CA pareza correcta durante unha hora e despois falle no peor momento: un portátil esperta, unha asignación NAT caduca, unha pasarela reiníciase.

A reanudación de sesión estira a ilusión aínda máis. Un ticket de sesión TLS permite ao cliente volver sen reenviar certificados, e a reanudación salta a validación de ruta porque o primeiro salto de mans xa a fixo. Así que a proba honesta é un salto de mans completo nun proceso novo. Reinicie o cliente en lugar de reconectar o túnel, e nun perfil de proba considere desactivar os tickets para que a ruta de reanudación non poida ocultar unha cadea rota.

Manteña a capa de chave estática separada disto. tls-auth engade un HMAC á canle de control, tls-crypt cífraa e autentícaa, e ningún dos dous transporta material de certificado, así que rotar calquera deles é un cambio aparte co seu propio modo de fallo. Os despregamentos que confunden ambos acaban cun cliente cuxa chave estática está ben, cuxo certificado está obsoleto e cuxa mensaxe de erro non menciona ningún dos dous.

A trampa de reutilizar o nome do suxeito

É tentador reutilizar o nome distinguido do predecesor para que nada augas abaixo teña que cambiar. Iso mantén estable a liña do emisor na interface e destrúe o único sinal que necesita. Dous certificados con suxeitos idénticos e chaves distintas non se poden distinguir polo nome, así que un paquete con ambas as áncoras dá ao validador dous candidatos e ningunha regra para escoller.

A construción de ruta pode entón escoller o equivocado, informar «non se pode obter o certificado do emisor local» mentres a áncora correcta está presente, ou ter éxito nun host e fallar noutro co mesmo paquete, porque a orde dos candidatos era distinta. Se o nome debe reutilizarse, manteña ambas as áncoras en ficheiros separados durante a transición e cárgueas explicitamente, e fusiónaas só cando cada par presente o novo emisor. Doutro xeito, dea á substitución un nome común distinto — un sufixo de xeración ou de data abonda — para que os rexistros e os textos de erro digan baixo que autoridade se emitiu o par que falla.

Unha rotación que non bota a rede abaixo

Para unha substitución planificada, acepte ambas as áncoras durante unha xanela limitada en lugar de cambiar nun só paso. Emita a nova CA e os seus intermedios, poña a nova áncora no paquete de cada validador xunto á antiga e só entón comece a emitir certificados de par desde ela. Os pares con identidades antigas validan contra a áncora antiga; os novos funcionan contra a nova.

Feito nesa orde, cada paso é reversible. O fallo que evita é o cambio simultáneo, onde un cliente que perdeu a actualización do paquete atopa unha pasarela que xa retirou a áncora antiga, o salto de mans morre e ningún rexistro di que lado está desfasado.

Retírese na dirección oposta. Volve emitir cada identidade que deba sobrevivir, confirme que cada unha presenta a cadea nova e logo quite a áncora antiga dos paquetes. Retire a chave privada da CA antiga de servizo, porque un emisor que aínda pode asinar significa que a rotación non rematou. Garde os certificados e os rexistros de emisión para auditoría. Un emisor perdido restáurase á mesma confianza; unha exposición esixe identidades novas e ningún retorno á áncora antiga.

Verifique o resultado, non a lista de ficheiros

Un ficheiro de confianza no directorio esperado demostra pouco. A aplicación pode ler outra ruta, outro formato ou unha copia dentro dun paquete que unha actualización substitúe. Comprobe o comportamento nos dous extremos, non que exista un ficheiro.

Confirme que unha conexión nova cunha identidade nova ten éxito e logo confirme que se rexeita unha identidade emitida pola CA retirada. Esa segunda proba é a que a xente salta, e a única que demostra que a autoridade antiga xa non concede acceso. Onde o despregamento dependa de CRL ou OCSP, comprobe que os puntos de distribución dos certificados novos se resolven e que os pares que consultan alcanzan o respondedor.

Remate cun cliente que nunca se conectou: borre o estado do seu perfil, conécteo e lea a cadea negociada. Un par que reanuda unha sesión en caché informará ledo de que a migración funcionou cando non validou nada de nada.