strongSwan send_cert: kiedy wysyłany jest certyfikat IKE

Bramy rejestrują błędy uwierzytelniania związane z certyfikatami, a pierwszym odruchem jest dodanie odbiorcy kolejnego CA. To zakłada, że certyfikat dotarł i został odrzucony. Druga możliwość jest taka, że nigdy nie został wysłany, a decyduje o tym polityka połączenia nadawcy. Ustal, który z tych dwóch przypadków miał miejsce, zanim zmienisz zaufanie.

Czym send_cert faktycznie steruje

Uwierzytelnianie certyfikatami wymaga, aby certyfikat końcowego podmiotu peera dotarł na drugą stronę przez wymianę IKE lub wcześniejsze przygotowanie. W swanctl ustawienie połączenia send_cert określa, czy ten punkt końcowy dołącza ładunek swojego certyfikatu: nigdy, zawsze lub ifasked. Domyślne ifasked wysyła go w odpowiedzi na żądanie certyfikatu od peera. Żądanie certyfikatu to osobne ustawienie, ponieważ proszenie drugiej strony o jej certyfikat nie jest tym samym co oferowanie własnego.

Starsze wdrożenia ipsec.conf używały leftsendcert i rightsendcert, a te nazwy odnoszą się do ról lokalnych i zdalnych, a nie bezpośrednio do swanctl.

Przeczytaj jedną próbę przed zmianą połączenia

Diagnozuj na podstawie jednej kontrolowanej próby, a nie ogólnego wrażenia, że w grę wchodzą certyfikaty. Można sprawdzić zarówno politykę, jak i aktywne skojarzenie.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

Lista połączeń pokazuje skonfigurowaną wartość send_cert, a lista SA pokazuje, które połączenia faktycznie zostały nawiązane. Dziennik dodaje szczegóły negocjacji: czy odebrano żądanie certyfikatu i czy wyszedł ładunek certyfikatu. Ogólny błąd uwierzytelniania nie wskazuje problemu z dostarczaniem, więc znajdź konkretną wymianę, zanim cokolwiek wywnioskujesz. Zapisz znacznik czasu próby, aby okno dziennika objęło całe uzgadnianie.

Zaufanie odbiorcy to osobna decyzja

Dostarczanie i zaufanie to różne właściwości, a naprawienie jednego nie naprawia drugiego. Odbiorca musi mieć zamierzony punkt zakotwiczenia zaufania, otrzymać użyteczny łańcuch i pasować do oczekiwanej tożsamości peera. Certyfikat końcowego podmiotu, który przychodzi bez swojego certyfikatu pośredniego, nadal nie przechodzi ścisłej kontroli łańcucha. Odwrotnie, zainstalowanie CA wcale nie zmusza peera do wysłania jego certyfikatu.

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

Sprawdzenie pokazuje, który wystawca podpisał certyfikat i kiedy wygasa, i temu musi odpowiadać punkt zakotwiczenia odbiorcy. Ufaj wystawiającemu CA, którego posiada wdrożenie, a nie każdemu certyfikatowi pośredniemu w łańcuchu, ponieważ podniesienie każdego pośredniego do poziomu głównego rozszerza zaufanie znacznie dalej niż jeden peer. Utrzymuj weryfikację tożsamości aktywną, ponieważ połączenie, które udaje się tylko przy wyłączonej walidacji, nie jest rozwiązaniem. Tam, gdzie łańcuch jest niekompletny, napraw przygotowanie, a nie politykę nadawcy.

Zmieniaj nadawcę tylko z dowodami

Gdy dziennik pokazuje, że certyfikat nigdy nie został wysłany, a odbiorca jednak o niego prosił, ustawienie send_cert na always jest uzasadnioną zmianą dla tego połączenia. Zastosuj je w konfiguracji swanctl, przeładuj połączenia i ustanów nową sesję, zamiast ponownie używać istniejącego SA. Potwierdź, że ładunek certyfikatu teraz się pojawia i że odbiorca akceptuje go wobec zamierzonego punktu zakotwiczenia. Jeśli nic się nie zmienia, błąd leżał jednak po stronie zaufania, a ustawienie nadawcy nie było przyczyną.

Zapisz zaobserwowaną wymianę, punkt zakotwiczenia i wynikającą z tego weryfikację w rejestrze zmian. Poprawka certyfikatu, której nie da się opisać tymi pojęciami, jest przypadkiem.