IKEv2 are două semnături: certificatul și IKE_AUTH
CA semnează certificatul, iar partenerul își semnează schimbul IKE_AUTH cu o schemă proprie. Citiți fiecare din propriul câmp, apoi înregistrați-le pe amândouă.
Tichetul dumneavoastră spune că certificatul este SHA-256, însă jurnalul gateway-ului numește un alt algoritm de semnătură, iar cineva a pregătit deja o cerere de reemitere a CA. Înainte ca cererea să plece undeva, separați cele două semnături: una este ștampila emitentului pe o cheie publică, cealaltă este dovada partenerului că deține cheia privată corespunzătoare în timpul IKE_AUTH. Componente diferite le aleg, și li se permite să difere. Citirea fiecăreia din locul unde trăiește cere două comenzi și un tabel.
Citiți semnătura emitentului din certificat
CA își pune semnătura pe o legătură între o identitate și o cheie. Acea semnătură consemnează ce a făcut CA la emitere, nu ce va face subiectul când se conectează, așa că algoritmul ei descrie alegerea proprie de hash și cheie a CA. O cheie de subiect de un tip poate sta sub o cheie CA de alt tip fără nicio inconsistență, iar rotația cheii CA este rutină, nu defect. Citiți cele două câmpuri și aveți jumătate din inventar:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Notați ambele etichete ca intrări separate. Prima descrie CA, a doua descrie cheia subiectului, și niciuna nu prezice semnătura online.
Citiți semnătura online din schimbul IKE
În timpul autentificării fiecare partener semnează datele schimbului cu propria cheie privată, iar cealaltă parte verifică acea dovadă față de identitatea, lanțul de încredere și politica certificatului. La RSA umplutura și hash-ul aparțin acestei scheme online, deci o cheie mai lungă sau un certificat SHA-256 nou nu pot singure alege RSA-PSS pentru semnătura de autentificare. Metoda negociată apare în jurnalul demonului sau în lista lui de conexiuni, niciodată în certificat. Întrebați fiecare parte ce a negociat, fiindcă cele două direcții pot diferi.
ipsec statusall | grep -i "auth\|proposal"Când o parte numește o schemă pe care cealaltă nu o poate produce, ați găsit nepotrivirea despre care era tichetul. Reemiterea CA este reparația greșită, fiindcă certificatul nu a fost niciodată ceea ce a eșuat.
Ce schimbă RFC 7427 și ce nu
Metodele originale sunt numerotate pe combinație de algoritmi în RFC 7296. Extinderea ulterioară de semnătură RFC 7427 adaugă o metodă Digital Signature generală cu semnalizarea suportului pentru hash de semnătură, astfel încât un hash nou nu mai are nevoie de un număr propriu de metodă. Se negociază, nu se presupune: un partener nu câștigă extinderea pentru că biblioteca lui poate analiza aceleași certificate, iar un partener care implementează doar metodele originale obligă gateway-ul să păstreze una dintre ele. Este un schimb de politică cu un cost de compatibilitate, nu un defect.
Suportul este pe direcție și pe conexiune, așa că testați versiunea din fața dumneavoastră în loc să vă bazați pe o afirmație la nivel de familie. O matrice de capabilități scrisă acum trei ani descrie versiuni de acum trei ani.
Puneți patru rânduri în inventar
Înregistrarea care încheie disputa are patru linii, fiecare citită într-un loc diferit și fiecare schimbată de o persoană diferită. Completați-o înainte de a decide ceva, fiindcă rândul greșit este cel care selectează reparația.
| Obiect | De unde se citește | Cine îl schimbă |
|---|---|---|
| semnătura emitentului certificatului | câmpul Signature Algorithm al certificatului | operatorul CA, la emitere |
| cheia publică a subiectului | câmpul Public Key Algorithm al certificatului | cine generează cheia subiectului |
| schema de autentificare IKE | jurnalul demonului sau lista conexiunilor, notificarea auth și signature-hash | profilul IKE pe ambii parteneri |
| algoritmii de protecție IKE și ESP | lista de propuneri a conexiunii | profilul IPsec, pe direcție |
Fiecare rând poartă propria consecință de compatibilitate. O schimbare a cifrului ESP nu alege semnătura emitentului, iar relaxarea validării CA nu adaugă o metodă online pe care partenerii nu au negociat-o niciodată. Când un tichet susține o nepotrivire de semnătură, rândul cu adevărat greșit aproape niciodată nu este primul.
Rezolvați cazul vechi fără a slăbi PKI
Un partener mai vechi poate oferi doar o schemă pe care politica dumneavoastră nu o mai permite. Opțiunile sunt o excepție de compatibilitate limitată în timp, o actualizare a clientului sau o altă aranjare a autentificării doar pentru acel partener. Reconstruirea PKI în jurul unei semnături de certificat mai slabe nu remediază o limitare a schimbului online și slăbește orice alt serviciu care are încredere în aceeași CA. Notați ce rând ați schimbat și când expiră excepția.
Apoi rulați din nou ambele citiri de la început, fiindcă o schimbare într-un rând poate muta ce se negociază în altul. Tot inventarul este două comenzi și un tabel, și este aceeași muncă fie că partenerul este un router, un laptop sau un aparat.