IKEv2 ma dwa podpisy: certyfikat i IKE_AUTH
CA podpisuje certyfikat, a peer podpisuje swoją wymianę IKE_AUTH własnym schematem. Odczytaj każdy z jego pola, a następnie zapisz oba.
Twój bilet mówi, że certyfikat to SHA-256, tymczasem log bramy wskazuje inny algorytm podpisu, a ktoś już przygotował wniosek o ponowne wydanie CA. Zanim ten wniosek gdziekolwiek pójdzie, rozdziel dwa podpisy: jeden to pieczęć wystawcy na kluczu publicznym, drugi to dowód peera, że podczas IKE_AUTH ma pasujący klucz prywatny. Różne komponenty je wybierają i wolno im się różnić. Odczytanie każdego z miejsca, w którym żyje, wymaga dwóch poleceń i jednej tabeli.
Odczytaj podpis wystawcy z certyfikatu
CA umieszcza swój podpis na powiązaniu tożsamości z kluczem. Ten podpis zapisuje, co CA zrobiła przy wydaniu, a nie co zrobi podmiot przy połączeniu, więc jego algorytm opisuje własny wybór skrótu i klucza przez CA. Klucz podmiotu jednego typu może leżeć pod kluczem CA innego typu bez żadnej niespójności, a rotacja klucza CA jest rutyną, nie usterką. Odczytaj oba pola i masz połowę inwentarza:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Zapisz obie etykiety jako osobne pozycje. Pierwsza opisuje CA, druga opisuje klucz podmiotu, i żadna nie przewiduje podpisu online.
Odczytaj podpis online z wymiany IKE
Podczas uwierzytelniania każdy peer podpisuje dane wymiany własnym kluczem prywatnym, a druga strona sprawdza ten dowód wobec tożsamości, łańcucha zaufania i polityki certyfikatu. W RSA dopełnienie i skrót należą do tego schematu online, więc dłuższy klucz albo świeży certyfikat SHA-256 nie może sam wybrać RSA-PSS dla podpisu uwierzytelniającego. Wynegocjowana metoda pojawia się w logu demona lub na jego liście połączeń, nigdy w certyfikacie. Zapytaj każdą stronę, co wynegocjowała, bo oba kierunki mogą się różnić.
ipsec statusall | grep -i "auth\|proposal"Gdy jedna strona wskazuje schemat, którego druga nie potrafi wytworzyć, znalazłeś niezgodność, o której był bilet. Ponowne wydanie CA to zła naprawa, bo certyfikat nigdy nie był tym, co zawiodło.
Co zmienia RFC 7427, a czego nie
Pierwotne metody są numerowane według kombinacji algorytmów w RFC 7296. Późniejsze rozszerzenie podpisu RFC 7427 dodaje ogólną metodę Digital Signature z sygnalizacją wsparcia skrótu podpisu, więc nowy skrót nie potrzebuje już własnego numeru metody. Negocjuje się to, nie zakłada: peer nie zyskuje rozszerzenia dlatego, że jego biblioteka potrafi parsować te same certyfikaty, a peer implementujący tylko pierwotne metody zmusza bramę do zachowania jednej z nich. To wymiana polityki z kosztem zgodności, nie defekt.
Wsparcie jest dla każdego kierunku i każdego połączenia, więc testuj build, który masz przed sobą, zamiast ufać twierdzeniu na poziomie rodziny. Macierz możliwości napisana trzy lata temu opisuje buildy trzyletnie.
Umieść cztery wiersze w inwentarzu
Zapis, który kończy spór, ma cztery wiersze, każdy odczytany z innego miejsca i każdy zmieniony przez inną osobę. Wypełnij go przed podjęciem decyzji, bo to błędny wiersz wybiera naprawę.
| Obiekt | Skąd odczytać | Kto zmienia |
|---|---|---|
| podpis wystawcy certyfikatu | pole Signature Algorithm certyfikatu | operator CA, przy wydaniu |
| klucz publiczny podmiotu | pole Public Key Algorithm certyfikatu | ten, kto generuje klucz podmiotu |
| schemat uwierzytelniania IKE | log demona lub lista połączeń, powiadomienie auth i signature-hash | profil IKE na obu peerach |
| algorytmy ochrony IKE i ESP | lista propozycji połączenia | profil IPsec, według kierunku |
Każdy wiersz niesie własną konsekwencję zgodności. Zmiana szyfru ESP nie wybiera podpisu wystawcy, a poluzowanie walidacji CA nie dodaje metody online, której peery nigdy nie wynegocjowały. Gdy bilet twierdzi, że podpisy się nie zgadzają, wiersz, który naprawdę jest błędny, prawie nigdy nie jest pierwszy.
Rozwiąż stary przypadek bez osłabiania PKI
Starszy peer może oferować tylko schemat, którego twoja polityka już nie dopuszcza. Opcje to ograniczony czasowo wyjątek zgodności, aktualizacja klienta albo inny układ uwierzytelniania tylko dla tego peera. Przebudowa PKI wokół słabszego podpisu certyfikatu nie naprawia ograniczenia w wymianie online i osłabia każdą inną usługę, która ufa tej samej CA. Zapisz, który wiersz zmieniłeś i kiedy wyjątek wygasa.
Następnie uruchom oba odczyty ponownie od góry, bo zmiana w jednym wierszu może przesunąć to, co jest negocjowane w innym. Cały inwentarz to dwa polecenia i jedna tabela, i to ta sama praca niezależnie od tego, czy peer jest routerem, laptopem czy urządzeniem.