IKEv2 ten dúas sinaturas: o certificado e IKE_AUTH
A CA asina o certificado e o par asina o seu intercambio IKE_AUTH cun esquema propio. Lea cada unha no seu campo e anote as dúas.
O seu ticket di que o certificado é SHA-256 mentres o rexistro da pasarela nomea outro algoritmo de sinatura, e alguén xa redactou unha solicitude para reemitir a CA. Antes de que esa solicitude vaia a ningures, separe as dúas sinaturas: unha é o selo do emisor sobre unha clave pública, a outra é a proba do par de que posúe a clave privada correspondente durante IKE_AUTH. Compoñentes distintos as elixen, e permítese que difiran. Ler cada unha desde o lugar onde vive require dous comandos e unha táboa.
Lea a sinatura do emisor no certificado
A CA pon a súa sinatura sobre un vínculo entre unha identidade e unha clave. Ese sinatura rexistra o que fixo a CA na emisión, non o que fará o suxeito ao conectarse, así que o seu algoritmo describe a escolla propia de hash e clave da CA. Unha clave de suxeito dun tipo pode estar baixo unha clave de CA doutro tipo sen ningunha inconsistencia, e a rotación da clave da CA é rutina e non unha falla. Lea os dous campos e terá a metade do inventario:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Anote as dúas etiquetas como entradas separadas. A primeira describe a CA, a segunda describe a clave do suxeito, e ningunha predí a sinatura en liña.
Lea a sinatura en liña do intercambio IKE
Durante a autenticación cada par asina os datos do intercambio coa súa propia clave privada, e o outro lado comproba esa proba contra a identidade, a cadea de confianza e a política do certificado. En RSA o recheo e o hash pertencen a este esquema en liña, así que unha clave máis longa ou un certificado SHA-256 novo non poden por si sós escoller RSA-PSS para a sinatura de autenticación. O método negociado aparece no rexistro do daemon ou na súa lista de conexións, nunca no certificado. Pregunte a cada lado que negociou, porque as dúas direccións poden diferir.
ipsec statusall | grep -i "auth\|proposal"Cando un lado nomea un esquema que o outro non pode producir, atopou a discrepancia da que trataba o ticket. Reemitir a CA é a reparación equivocada, porque o certificado nunca foi o que fallou.
Que cambia RFC 7427 e que non
Os métodos orixinais están numerados por combinación de algoritmos en RFC 7296. A posterior extensión de sinatura RFC 7427 engade un método Digital Signature xeral con sinalización de soporte de hash de sinatura, de xeito que un hash novo xa non necesita un número de método propio. Negóciase, non se supón: un par non gaña a extensión porque a súa biblioteca poida analizar os mesmos certificados, e un par que só implementa os métodos orixinais obriga a pasarela a conservar un deles. É un intercambio de política cun custo de compatibilidade, non un defecto.
O soporte é por dirección e por conexión, así que probe a compilación que ten diante en lugar de confiar nunha afirmación a nivel de familia. Unha matriz de capacidades escrita hai tres anos describe compilacións de hai tres anos.
Pon catro filas no inventario
O rexistro que remata a discusión ten catro liñas, cada unha lida nun lugar distinto e cada unha cambiada por unha persoa distinta. Enchéao antes de decidir nada, porque a fila que está mal é a que selecciona a corrección.
| Obxecto | De onde se le | Quen o cambia |
|---|---|---|
| sinatura do emisor do certificado | o campo Signature Algorithm do certificado | o operador da CA, na emisión |
| clave pública do suxeito | o campo Public Key Algorithm do certificado | quen xera a clave do suxeito |
| esquema de autenticación IKE | rexistro do daemon ou lista de conexións, aviso de auth e signature-hash | o perfil IKE nos dous pares |
| algoritmos de protección IKE e ESP | a lista de propostas da conexión | o perfil IPsec, por dirección |
Cada fila leva a súa propia consecuencia de compatibilidade. Un cambio de cifra ESP non escolle a sinatura do emisor, e relaxar a validación da CA non engade un método en liña que os pares nunca negociaron. Cando un ticket afirma unha discrepancia de sinatura, a fila que de verdade está mal case nunca é a primeira.
Resolva o caso antigo sen debilitar a PKI
Un par máis antigo pode ofrecer só un esquema que a súa política xa non permite. As opcións son unha excepción de compatibilidade con prazo, unha actualización do cliente ou un arranxo de autenticación distinto só para ese par. Reconstruír a PKI arredor dunha sinatura de certificado máis feble non corrixe unha limitación do intercambio en liña e debilita calquera outro servizo que confíe na mesma CA. Anote que fila cambiou e cando caduca a excepción.
Despois volva executar as dúas lecturas desde arriba, porque un cambio nunha fila pode mover o que se negocia noutra. Todo o inventario son dous comandos e unha táboa, e é o mesmo traballo tanto se o par é un router, un portátil ou un aparello.