IKEv2 comporte deux signatures : le certificat et IKE_AUTH
La CA signe le certificat, et le pair signe son échange IKE_AUTH avec un schéma qui lui est propre. Lisez chacune dans son propre champ, puis consignez les deux.
Votre ticket indique que le certificat est en SHA-256 alors que le journal de la passerelle nomme un autre algorithme de signature, et quelqu'un a déjà rédigé une demande de réémission de la CA. Avant que cette demande n'aille où que ce soit, séparez les deux signatures : l'une est le sceau de l'émetteur sur une clé publique, l'autre est la preuve par le pair qu'il détient la clé privée correspondante pendant IKE_AUTH. Des composants différents les choisissent, et elles ont le droit de différer. Lire chacune à l'endroit où elle vit demande deux commandes et un tableau.
Lisez la signature de l'émetteur dans le certificat
La CA apporte sa signature à une liaison entre une identité et une clé. Cette signature consigne ce que la CA a fait à l'émission, non ce que le sujet fera lorsqu'il se connectera, si bien que son algorithme décrit le choix de hachage et de clé propre à la CA. Une clé de sujet d'un type peut se trouver sous une clé de CA d'un autre type sans aucune incohérence, et la rotation de la clé de la CA relève de la routine et non d'une panne. Lisez les deux champs et vous avez la moitié de l'inventaire :
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Notez les deux étiquettes comme des entrées distinctes. La première décrit la CA, la seconde décrit la clé du sujet, et aucune des deux ne prédit la signature en ligne.
Lisez la signature en ligne dans l'échange IKE
Pendant l'authentification, chaque pair signe les données d'échange avec sa propre clé privée, et l'autre côté vérifie cette preuve au regard de l'identité, de la chaîne de confiance et de la politique du certificat. Pour RSA, le remplissage et le hachage appartiennent à ce schéma en ligne, donc une clé plus longue ou un certificat SHA-256 neuf ne peut pas à lui seul choisir RSA-PSS pour la signature d'authentification. La méthode négociée apparaît dans le journal du démon ou dans sa liste de connexions, jamais dans le certificat. Demandez à chaque côté ce qu'il a négocié, car les deux directions peuvent différer.
ipsec statusall | grep -i "auth\|proposal"Quand un côté nomme un schéma que l'autre ne peut pas produire, vous avez trouvé l'écart dont parlait le ticket. Réémettre la CA est la mauvaise réparation, car le certificat n'a jamais été ce qui a échoué.
Ce que RFC 7427 change, et ce qu'il ne change pas
Les méthodes d'origine sont numérotées par combinaison d'algorithmes dans RFC 7296. La extension de signature RFC 7427 ultérieure ajoute une méthode Digital Signature générale avec une signalisation du support du hachage de signature, si bien qu'un nouveau hachage n'a plus besoin de son propre numéro de méthode. Elle se négocie, elle ne se suppose pas : un pair ne gagne pas l'extension parce que sa bibliothèque sait analyser les mêmes certificats, et un pair qui n'implémente que les méthodes d'origine oblige la passerelle à en conserver une. C'est un arbitrage de politique avec un coût de compatibilité, pas un défaut.
Le support est par direction et par connexion, alors testez la version qui est devant vous plutôt que de vous fier à une affirmation au niveau d'une famille. Une matrice de capacités écrite il y a trois ans décrit des versions de trois ans.
Inscrivez quatre lignes dans l'inventaire
L'enregistrement qui met fin au débat comporte quatre lignes, chacune lue à un endroit différent et chacune modifiée par une personne différente. Remplissez-le avant de décider quoi que ce soit, car c'est la ligne fausse qui choisit la correction.
| Objet | Où le lire | Qui le modifie |
|---|---|---|
| signature de l'émetteur du certificat | le champ Signature Algorithm du certificat | l'exploitant de la CA, à l'émission |
| clé publique du sujet | le champ Public Key Algorithm du certificat | celui qui génère la clé du sujet |
| schéma d'authentification IKE | journal du démon ou liste de connexions, notification auth et signature-hash | le profil IKE sur les deux pairs |
| algorithmes de protection IKE et ESP | la liste de propositions de la connexion | le profil IPsec, par direction |
Chaque ligne porte sa propre conséquence de compatibilité. Un changement de chiffrement ESP ne choisit pas la signature de l'émetteur, et assouplir la validation de la CA n'ajoute pas une méthode en ligne que les pairs n'ont jamais négociée. Quand un ticket allègue un écart de signature, la ligne réellement fausse n'est presque jamais la première.
Réglez le cas ancien sans affaiblir la PKI
Un pair plus ancien peut n'offrir qu'un schéma que votre politique n'autorise plus. Les options sont une exception de compatibilité limitée dans le temps, une mise à jour du client, ou un autre agencement d'authentification pour ce seul pair. Reconstruire la PKI autour d'une signature de certificat plus faible ne corrige pas une limite de l'échange en ligne et affaiblit tous les autres services qui font confiance à la même CA. Notez quelle ligne vous avez changée et quand l'exception expire.
Relancez ensuite les deux lectures depuis le début, car un changement dans une ligne peut déplacer ce qui se négocie dans une autre. Tout l'inventaire tient en deux commandes et un tableau, et c'est le même travail que le pair soit un routeur, un ordinateur portable ou un appareil.