Mac IKEv2 ECDSA: który typ certyfikatu należy do klienta?
Na Macu ECDSA256 w ustawieniach IKEv2 opisuje lokalny certyfikat tożsamości, a nie bramę ani podpis wystawcy. Przeczytaj każdą rolę przed wyborem.
Na macOS wybór ECDSA w ustawieniu klienta IKEv2 odpowiada na wąskie pytanie: który certyfikat dowodzi tożsamości Maca. Nie opisuje certyfikatu bramy, podpisu, którym wystawiono certyfikat klienta, ani propozycji szyfrowania tunelu. Traktowanie tych czterech ról jako jednego pytania o zgodność sprawia, że poprawna lokalna konfiguracja bywa obwiniana o niezgodność po stronie serwera. Decyzja jest mała, ale dowody, na których się opiera, muszą być precyzyjne.
Pole nazywa jeden certyfikat: lokalną tożsamość
Network Extension API firmy Apple udostępnia typ certyfikatu dla poświadczenia klienta, w tym NEVPNIKEv2CertificateType.ECDSA256, udokumentowany jako typ certyfikatu ECDSA p-256. Właściwość dotyczy certyfikatu dostarczonego przez identityReference lub identityData.
Oznacza to, że decyzja dotyczy certyfikatu przedstawianego przez Maca oraz towarzyszącego mu klucza prywatnego. Wybierz typ zgodny z kluczem publicznym tego certyfikatu liścia i dostarcz tożsamość obsługiwanym mechanizmem. Jeśli Mac nie ma użytecznego klucza prywatnego dla tożsamości, wybór typu nie uratuje połączenia.
Profile zarządzane podejmują tę samą decyzję przez CertificateType ładunku IKEv2, w parze z odniesieniem do certyfikatu, takim jak PayloadCertificateUUID. Te pola mają wymagania wstępne i schemat dla docelowej wersji systemu; goła wartość typu skopiowana do profilu nie jest instalowalna, a okno ustawień może nie pokazywać każdej opcji API. Sprawdź wymagania wstępne ładunku dla tej wersji przed wdrożeniem.
Decyduj według roli, nie według etykiety certyfikatu
Przeczytaj pole, które zamierzasz zmienić, i zapytaj, na który certyfikat wskazuje. Etykiety w przeglądarce certyfikatów mieszają podmiot, wystawcę i algorytm podpisu, a tylko jedna z nich należy do wyboru tożsamości klienta.
| What you inspected | What it controls | Does it choose the Mac certificate type? |
|---|---|---|
| Client leaf public key | The identity the Mac presents | Yes, this is the field's subject |
| Issuer signature algorithm | How the client certificate was signed | No |
| Gateway certificate | What the Mac validates as the peer | No, check it separately |
| IKE and ESP proposals | Algorithms for the tunnel | No, separate proposal settings |
Jeśli przeglądarka certyfikatów pokazuje podpis ECDSA od CA, opisuje to klucz podpisujący wystawcy. Klucz samego klienta może nadal być RSA, a pole typu powinno podążać za kluczem klienta, a nie za wierszem podpisu. To jedno nieporozumienie wyjaśnia wiele zgłoszeń typu "ECDSA jest skonfigurowany, ale połączenie zawodzi". Porównaj typ klucza w liściu z typem wybranym w profilu, zanim cokolwiek zmienisz.
Decyzja staje się prostsza, gdy liść jest zidentyfikowany: ECDSA256 dla klucza klienta p-256, inny obsługiwany typ dla innego klucza. Jeśli certyfikat klienta i jego klucz nie pasują, popraw tę parę przed zmianą profilu VPN.
Certyfikat bramy to osobna decyzja
Brama przedstawia własny certyfikat, a Mac weryfikuje go względem kotwicy zaufania i oczekiwanej nazwy. To, czy ten certyfikat używa ECDSA, RSA czy innego typu klucza, jest właściwością serwera, a nie ustawienia tożsamości klienta.
Lokalne wsparcie dla certyfikatu klienta ECDSA nie dowodzi, że każdy certyfikat bramy, krzywa czy konfiguracja uwierzytelniania serwera będzie współdziałać. Sprawdź tożsamość serwera, jego łańcuch i metodę uwierzytelniania IKE jako osobne dane wejściowe i testuj z profilem, który naprawdę zostanie wdrożony.
Jeśli problemem jest certyfikat bramy, objaw zwykle pojawia się podczas weryfikacji drugiej strony, a nie przy wyborze tożsamości. Przeczytaj etap błędu, zanim zmienisz typ klienta, ponieważ błąd zaufania i niezgodność klucza klienta nie mają wspólnego rozwiązania.
Podpis wystawcy i grupa uzgadniania kluczy to nie typ klienta
X.509 trzyma klucz publiczny podmiotu i podpis wystawcy w różnych polach. Informacja o kluczu publicznym podmiotu opisuje klucz w certyfikacie; algorytm podpisu opisuje klucz CA i operację podpisywania. Tylko pierwsze odpowiada ustawieniu typu certyfikatu.
Propozycje IKE i Child SA to inna oś. Typ certyfikatu ECDSA nie jest wyborem szyfrowania ESP, a zmiana grupy uzgadniania kluczy nie wybiera typu certyfikatu. Profil może mieć poprawne propozycje i zły typ tożsamości albo właściwy typ tożsamości i propozycję odrzucaną przez drugą stronę.
W rejestrze zmian trzymaj trzy wiersze osobno: certyfikat i klucz tożsamości, dane wejściowe zaufania bramy oraz algorytmy propozycji. Połączenie ich w jedną notatkę "ustawienia kryptograficzne" sprawia, że następnego błędu nie da się przypisać.
Sprawdź decyzję polami, które skonfigurowałeś
Sprawdź tożsamość, do której profil faktycznie się odwołuje, a następnie potwierdź, że certyfikat pod tym odniesieniem ma oczekiwany klucz publiczny i użyteczny klucz prywatny. Wyświetlany typ w interfejsie, certyfikat, do którego prowadzi odniesienie, oraz klucz na urządzeniu muszą się zgadzać.
Następnie potwierdź dane wejściowe bramy: oczekiwaną nazwę serwera, kotwicę zaufania i metodę uwierzytelniania IKE. Na koniec połącz się i odczytaj, gdzie zatrzymuje się uzgadnianie. Błąd przed wymianą tożsamości wskazuje poza to ustawienie; błąd podczas weryfikacji drugiej strony wskazuje na stronę bramy.
Zapisz wybrany typ, odniesienie do tożsamości i podmiot certyfikatu bramy w notatkach wdrożeniowych. Następna aktualizacja profilu może zmienić każdy z nich, a trzy nazwane wartości porównuje się szybciej niż zrzut ekranu panelu ustawień.