IKEv2 tiene dos firmas: el certificado y IKE_AUTH
La CA firma el certificado y el par firma su intercambio IKE_AUTH con un esquema propio. Lea cada firma en su campo y anote las dos.
Su ticket dice que el certificado es SHA-256 mientras el registro de la puerta de enlace nombra otro algoritmo de firma, y alguien ya ha redactado una solicitud para reemitir la CA. Antes de que esa solicitud vaya a algún sitio, separe las dos firmas: una es el sello del emisor sobre una clave pública, la otra es la prueba del par de que posee la clave privada correspondiente durante IKE_AUTH. Componentes distintos las eligen, y se les permite diferir. Leer cada una desde el lugar donde vive requiere dos comandos y una tabla.
Lea la firma del emisor en el certificado
La CA pone su firma sobre un vínculo entre una identidad y una clave. Esa firma registra lo que hizo la CA en la emisión, no lo que hará el sujeto al conectarse, así que su algoritmo describe la elección propia de hash y clave de la CA. Una clave de sujeto de un tipo puede estar bajo una clave de CA de otro tipo sin ninguna inconsistencia, y la rotación de la clave de la CA es rutina y no una falla. Lea los dos campos y tendrá la mitad del inventario:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Anote ambas etiquetas como entradas separadas. La primera describe a la CA, la segunda describe la clave del sujeto, y ninguna predice la firma en línea.
Lea la firma en línea del intercambio IKE
Durante la autenticación cada par firma los datos del intercambio con su propia clave privada, y el otro lado comprueba esa prueba contra la identidad, la cadena de confianza y la política del certificado. En RSA el relleno y el hash pertenecen a este esquema en línea, así que una clave más larga o un certificado SHA-256 nuevo no pueden por sí solos elegir RSA-PSS para la firma de autenticación. El método negociado aparece en el registro del demonio o en su lista de conexiones, nunca en el certificado. Pregunte a cada lado qué negoció, porque las dos direcciones pueden diferir.
ipsec statusall | grep -i "auth\|proposal"Cuando un lado nombra un esquema que el otro no puede producir, ha encontrado la discrepancia de la que trataba el ticket. Reemitir la CA es la reparación equivocada, porque el certificado nunca fue lo que falló.
Qué cambia RFC 7427 y qué no
Los métodos originales están numerados por combinación de algoritmos en RFC 7296. La posterior extensión de firma RFC 7427 añade un método Digital Signature general con señalización de soporte de hash de firma, de modo que un hash nuevo ya no necesita un número de método propio. Se negocia, no se supone: un par no gana la extensión porque su biblioteca pueda analizar los mismos certificados, y un par que solo implementa los métodos originales obliga a la puerta de enlace a conservar uno de ellos. Es un intercambio de política con un coste de compatibilidad, no un defecto.
El soporte es por dirección y por conexión, así que pruebe la compilación que tiene delante en lugar de confiar en una afirmación a nivel de familia. Una matriz de capacidades escrita hace tres años describe compilaciones de hace tres años.
Ponga cuatro filas en el inventario
El registro que zanja la discusión tiene cuatro líneas, cada una leída en un lugar distinto y cada una cambiada por una persona distinta. Rellénelo antes de decidir nada, porque la fila equivocada es la que selecciona la corrección.
| Objeto | De dónde se lee | Quién lo cambia |
|---|---|---|
| firma del emisor del certificado | el campo Signature Algorithm del certificado | el operador de la CA, en la emisión |
| clave pública del sujeto | el campo Public Key Algorithm del certificado | quien genera la clave del sujeto |
| esquema de autenticación IKE | registro del demonio o lista de conexiones, aviso de auth y signature-hash | el perfil IKE en ambos pares |
| algoritmos de protección IKE y ESP | la lista de propuestas de la conexión | el perfil IPsec, por dirección |
Cada fila lleva su propia consecuencia de compatibilidad. Un cambio de cifra ESP no elige la firma del emisor, y relajar la validación de la CA no añade un método en línea que los pares nunca negociaron. Cuando un ticket afirma una discrepancia de firma, la fila que de verdad está mal casi nunca es la primera.
Resuelva el caso antiguo sin debilitar la PKI
Un par más antiguo puede ofrecer solo un esquema que su política ya no permite. Las opciones son una excepción de compatibilidad con plazo, una actualización del cliente o un arreglo de autenticación distinto solo para ese par. Reconstruir la PKI en torno a una firma de certificado más débil no corrige una limitación del intercambio en línea y debilita cualquier otro servicio que confíe en la misma CA. Anote qué fila cambió y cuándo caduca la excepción.
Después vuelva a ejecutar las dos lecturas desde arriba, porque un cambio en una fila puede mover lo que se negocia en otra. Todo el inventario son dos comandos y una tabla, y es el mismo trabajo tanto si el par es un router, un portátil o un dispositivo.