Mac IKEv2 ECDSA: quale tipo di certificato spetta al client?

Su macOS, la scelta di ECDSA in un'impostazione client IKEv2 risponde a una domanda ristretta: quale certificato dimostra l'identità del Mac. Non descrive il certificato del gateway, la firma che ha emesso il certificato del client, né la proposta di cifratura del tunnel. Trattare questi quattro ruoli come un'unica questione di compatibilità è il modo in cui un'impostazione locale corretta finisce incolpata di un disallineamento lato server. La decisione è piccola, ma le prove usate per prenderla devono essere precise.

Il campo nomina un certificato: l'identità locale

L'API Network Extension di Apple espone un tipo di certificato per la credenziale del client, incluso NEVPNIKEv2CertificateType.ECDSA256, documentato come il tipo di certificato ECDSA p-256. La proprietà si applica al certificato fornito tramite identityReference o identityData.

Ciò significa che la decisione riguarda il certificato che il Mac presenta, più la chiave privata che lo accompagna. Scegli il tipo che corrisponde alla chiave pubblica di quel certificato foglia e fornisci l'identità tramite il meccanismo supportato. Se il Mac non ha una chiave privata utilizzabile per l'identità, la scelta del tipo non può salvare la connessione.

I profili gestiti prendono la stessa decisione tramite CertificateType del payload IKEv2, abbinato a un riferimento al certificato come PayloadCertificateUUID. Questi campi hanno prerequisiti e uno schema per la versione del sistema operativo di destinazione; un valore di tipo nudo copiato in un profilo non è installabile, e una finestra di impostazioni potrebbe non esporre ogni opzione dell'API. Controlla i prerequisiti del payload per quella versione prima della distribuzione.

Decidi per ruolo, non per l'etichetta del certificato

Leggi il campo che stai per modificare e chiedi a quale certificato punta. Le etichette in un visualizzatore di certificati mescolano soggetto, emittente e algoritmo di firma, e solo una di esse appartiene alla scelta dell'identità del client.

Se il visualizzatore di certificati mostra una firma ECDSA della CA, ciò descrive la chiave di firma dell'emittente. La chiave del client stesso può essere ancora RSA, e il campo del tipo deve seguire la chiave del client, non la riga della firma. Questa singola confusione spiega molte segnalazioni del tipo "ECDSA è configurato ma la connessione fallisce". Confronta il tipo di chiave nella foglia con il tipo selezionato nel profilo prima di cambiare qualsiasi cosa.

La decisione diventa più semplice una volta identificata la foglia: ECDSA256 per una chiave client p-256, un altro tipo supportato per una chiave diversa. Se il certificato del client e la sua chiave non corrispondono, correggi quella coppia prima di modificare il profilo VPN.

Il certificato del gateway è una decisione separata

Il gateway presenta il proprio certificato e il Mac lo convalida rispetto a un'ancora di fiducia e a un nome atteso. Che quel certificato usi ECDSA, RSA o un altro tipo di chiave è una proprietà del server, non dell'impostazione di identità del client.

Il supporto locale per un certificato client ECDSA non dimostra che ogni certificato di gateway, curva o configurazione di autenticazione del server interagirà. Controlla l'identità del server, la sua catena e il suo metodo di autenticazione IKE come input separati, e prova con il profilo che sarà realmente distribuito.

Se il certificato del gateway è il problema, il sintomo di solito compare durante la convalida del peer, non nella scelta dell'identità. Leggi la fase di errore prima di cambiare il tipo di client, perché un errore di fiducia e un disallineamento della chiave del client non condividono la stessa correzione.

La firma dell'emittente e il gruppo di accordo delle chiavi non sono il tipo del client

X.509 tiene la chiave pubblica del soggetto e la firma dell'emittente in campi diversi. Le informazioni sulla chiave pubblica del soggetto descrivono la chiave nel certificato; l'algoritmo di firma descrive la chiave della CA e l'operazione di firma. Solo la prima corrisponde all'impostazione del tipo di certificato.

Le proposte IKE e Child SA sono un altro asse. Un tipo di certificato ECDSA non è una scelta di cifratura ESP, e cambiare il gruppo di accordo delle chiavi non seleziona un tipo di certificato. Un profilo può avere proposte valide e il tipo di identità sbagliato, oppure il tipo di identità giusto e una proposta che il peer rifiuta.

Tieni separate le tre righe nel registro delle modifiche: certificato e chiave di identità, input di fiducia del gateway e algoritmi delle proposte. Fonderle in un'unica nota "impostazioni crypto" rende l'errore successivo impossibile da attribuire.

Verifica la decisione con i campi che hai configurato

Controlla l'identità a cui il profilo fa realmente riferimento, poi conferma che il certificato a quel riferimento abbia la chiave pubblica attesa e una chiave privata utilizzabile. Il tipo mostrato nell'interfaccia, il certificato referenziato e la chiave sul dispositivo devono coincidere.

Poi conferma gli input del gateway: il nome del server atteso, l'ancora di fiducia e il metodo di autenticazione IKE. Infine connettiti e leggi dove si ferma l'handshake. Un errore prima dello scambio di identità allontana da questa impostazione; un errore nella convalida del peer punta al lato gateway.

Annota il tipo scelto, il riferimento all'identità e il soggetto del certificato del gateway nelle note di distribuzione. Il prossimo aggiornamento del profilo può cambiare uno qualsiasi di questi valori, e tre valori nominati si confrontano più in fretta di uno screenshot di un pannello di impostazioni.