Renovar un certificat VPN sense canviar-ne la identitat

Una renovació de certificat que canvia la identitat no és una renovació, és una migració amb un tiquet de manteniment. El client verifica un nom, una cadena i de vegades una clau concreta, i els tres poden canviar sense que canviï la data de caducitat. Abans de demanar un substitut, anoteu què comprova realment el client: el nom d’amfitrió o la identitat de l’igual, la finalitat del certificat, la política de claus i la cadena emissora. La renovació és rutinària o coordinada segons quin d’aquests elements alteri el substitut.

Tres condicions decideixen la forma de la renovació

Les tres condicions són si alguna cosa fixa el certificat final, si canvia la cadena i qui més valida el nom. Responeu-ho des del costat del client, no des de la comoditat de la CA, perquè el client és el que falla a les tres de la matinada.

Comenceu inspeccionant el certificat que teniu. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName imprimeix el subjecte, l’emissor, la finestra de validesa i els noms per als quals el certificat és realment vàlid. L’últim camp és el més important i el que més se suposa: una sol·licitud de renovació que omet un SAN en què el client confia produeix un certificat tècnicament vàlid i funcionalment incorrecte. Copieu la llista de SAN del certificat antic a la sol·licitud en lloc de reescriure-la de memòria.

Condició u: hi ha alguna cosa que fixi el certificat final

Si els clients confien en una CA mantinguda i validen el nom, una renovació del certificat final amb una clau nova els és invisible. Si algun client fixa el certificat final, la seva empremta o la seva clau pública, el substitut és un canvi coordinat amb una transició dura, perquè la fixació antiga no pot validar el certificat nou.

Esbrineu en quin cas esteu abans de demanar res. Una fixació que ningú no ha documentat continua sent una fixació quan es trenca.

Condició dos: compareu les fixacions i la cadena

Les empremtes fan que la fixació sigui comprovable: openssl x509 -noout -fingerprint -sha256 -in server.crt al certificat antic i al nou, i openssl x509 -noout -pubkey per comparar les claus públiques. Si la configuració del client, un perfil mòbil o un magatzem de confiança d’un aparell conté qualsevol dels dos valors, teniu una fixació. Els perfils VPN mòbils són un amagatall habitual, perquè el perfil es distribueix un cop i no es torna a inspeccionar mai.

Si el substitut prové del mateix intermediari i el client ja el té o el pot obtenir, no canvia res al costat de la confiança. Un intermediari nou, un emissor diferent o una cadena lliurada en l’ordre incorrecte converteixen una renovació en un canvi de confiança, i la fallada sembla un emissor desconegut en lloc d’un certificat caducat.

Comproveu la cadena que el servidor envia realment amb openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, i verifiqueu-la localment amb openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Fer-ho abans del canvi us dona una línia base per comparar-hi després.

Condició tres: qui més valida el nom

Un concentrador VPN, un balancejador de càrrega, una sonda de monitoratge, una integració RADIUS o SAML i un perfil mòbil poden tenir cadascun la seva pròpia còpia del nom esperat o de l’àncora de confiança. La renovació és el moment en què aquestes còpies divergeixen, perquè el certificat canvia i les còpies no.

Llisteu cada consumidor abans del canvi i decidiu, per a cadascun, si necessita una actualització. El que oblideu és el que us fa sonar el cercapersones.

També hi ha un parany de temps. Inspeccioneu l’inici de validesa igual que la caducitat, perquè un certificat preparat per a una activació posterior es rebutja si s’instal·la massa d’hora, i l’error sembla un problema de rellotge en lloc d’un problema de preparació. openssl x509 -noout -dates al fitxer nou abans de desplegar-lo és una comprovació de dos segons. Manteniu també un camí de recuperació suportat i la configuració que se sap bona, perquè una renovació que va malament sigui reversible restaurant el certificat i la clau anteriors.

Desplegueu, verifiqueu amb una autenticació nova i després retireu

Un túnel establert reflecteix la validació que va tenir lloc quan es va construir, així que pot semblar sa mentre cada connexió nova falla. Proveu amb una autenticació nova fent servir el nom de servei real que utilitzen els clients.

Completeu la comprovació a nivell d’aplicació que importa a l’usuari i confirmeu el lliurament de la cadena des de la perspectiva del client, no la del servidor. No suprimiu les comprovacions de nom o de certificat perquè la transició passi en silenci; això converteix un problema temporal de compatibilitat en un de permanent.

Retireu el material obsolet només després que el desplegament estigui verificat, i tracteu una clau compromesa com un cas completament diferent: una renovació per si sola no revoca res, així que la identitat afectada necessita el procés de revocació i de gestió de sessions del desplegament. RFC 5280 defineix les regles de certificat i de validació de camí que hi ha sota tot això. Manteniu una renovació rutinària del certificat final separada d’una substitució de CA, perquè no es demani als clients que confiïn en un emissor nou sense cap motiu.