O IKEv2 tem duas assinaturas: o certificado e o IKE_AUTH
A CA assina o certificado e o par assina o seu intercâmbio IKE_AUTH com um esquema próprio. Leia cada uma no seu campo e registe as duas.
O seu ticket diz que o certificado é SHA-256, mas o log da gateway nomeia outro algoritmo de assinatura, e alguém já preparou um pedido para reemitir a CA. Antes de esse pedido ir a algum lado, separe as duas assinaturas: uma é o selo do emissor sobre uma chave pública, a outra é a prova de que o par possui a chave privada correspondente durante o IKE_AUTH. Componentes diferentes escolhem-nas, e é permitido que difiram. Ler cada uma do lugar onde vive exige dois comandos e uma tabela.
Leia a assinatura do emissor no certificado
A CA coloca a sua assinatura numa ligação entre uma identidade e uma chave. Essa assinatura regista o que a CA fez na emissão, não o que o sujeito fará ao ligar-se, por isso o algoritmo descreve a escolha própria de hash e chave da CA. Uma chave de sujeito de um tipo pode estar sob uma chave de CA de outro tipo sem qualquer inconsistência, e a rotação da chave da CA é rotina e não uma falha. Leia os dois campos e tem metade do inventário:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Registe ambos os rótulos como entradas separadas. O primeiro descreve a CA, o segundo descreve a chave do sujeito, e nenhum deles prevê a assinatura em linha.
Leia a assinatura em linha no intercâmbio IKE
Durante a autenticação cada par assina os dados do intercâmbio com a sua própria chave privada, e o outro lado verifica essa prova contra a identidade, a cadeia de confiança e a política do certificado. No RSA o preenchimento e o hash pertencem a este esquema em linha, pelo que uma chave mais longa ou um certificado SHA-256 novo não podem, por si, escolher RSA-PSS para a assinatura de autenticação. O método negociado aparece no log do daemon ou na sua lista de ligações, nunca no certificado. Pergunte a cada lado o que negociou, porque as duas direções podem diferir.
ipsec statusall | grep -i "auth\|proposal"Quando um lado nomeia um esquema que o outro não consegue produzir, encontrou a discrepância de que o ticket tratava. Reemitir a CA é a reparação errada, porque o certificado nunca foi o que falhou.
O que o RFC 7427 muda, e o que não muda
Os métodos originais são numerados por combinação de algoritmos no RFC 7296. A posterior extensão de assinatura RFC 7427 acrescenta um método Digital Signature geral com sinalização de suporte de hash de assinatura, de modo que um novo hash já não precisa de um número de método próprio. Isto negocia-se, não se assume: um par não ganha a extensão por a sua biblioteca conseguir analisar os mesmos certificados, e um par que implemente apenas os métodos originais obriga a gateway a manter um deles. É uma troca de política com um custo de compatibilidade, não um defeito.
O suporte é por direção e por ligação, por isso teste a compilação que tem à frente em vez de confiar numa afirmação ao nível da família. Uma matriz de capacidades escrita há três anos descreve compilações com três anos.
Coloque quatro linhas no inventário
O registo que termina a discussão tem quatro linhas, cada uma lida num lugar diferente e cada uma alterada por uma pessoa diferente. Preencha-o antes de decidir seja o que for, porque é a linha errada que escolhe a correção.
| Objeto | Onde se lê | Quem altera |
|---|---|---|
| assinatura do emissor do certificado | o campo Signature Algorithm do certificado | o operador da CA, na emissão |
| chave pública do sujeito | o campo Public Key Algorithm do certificado | quem gera a chave do sujeito |
| esquema de autenticação IKE | log do daemon ou lista de ligações, aviso de auth e signature-hash | o perfil IKE nos dois pares |
| algoritmos de proteção IKE e ESP | a lista de propostas da ligação | o perfil IPsec, por direção |
Cada linha traz a sua própria consequência de compatibilidade. Uma mudança de cifra ESP não escolhe a assinatura do emissor, e afrouxar a validação da CA não acrescenta um método em linha que os pares nunca negociaram. Quando um ticket alega uma discrepância de assinatura, a linha realmente errada quase nunca é a primeira.
Resolva o caso antigo sem enfraquecer a PKI
Um par mais antigo pode oferecer apenas um esquema que a sua política já não permite. As opções são uma exceção de compatibilidade com prazo, uma atualização do cliente ou um arranjo de autenticação diferente só para esse par. Reconstruir a PKI em torno de uma assinatura de certificado mais fraca não corrige uma limitação no intercâmbio em linha e enfraquece todos os outros serviços que confiam na mesma CA. Registe qual linha alterou e quando expira a exceção.
Depois volte a executar as duas leituras de cima, porque uma mudança numa linha pode deslocar o que se negoceia noutra. Todo o inventário são dois comandos e uma tabela, e é o mesmo trabalho quer o par seja um router, um portátil ou um equipamento.