Accesso VPN con certificato sul Mac: identità, uso della chiave o fiducia nel gateway?

Gli accessi VPN basati su certificato chiedono al Mac qualcosa di più stretto di una password: usare questa specifica chiave privata, in questo contesto di esecuzione, per dimostrare un’identità a quel gateway. Quando fallisce, il messaggio di solito descrive solo l’ultima cosa andata storta, che raramente è la causa. Ripercorrere le tre decisioni nell’ordine in cui il sistema le prende mantiene onesta la diagnosi ed evita che un problema di permessi locale venga trattato come un errore di validazione della catena.

Segui l’accesso nell’ordine in cui lo fa il Mac

Prima il client sceglie un’identità: un certificato abbinato a una chiave privata utilizzabile, disponibile tramite l’archivio o il provider di credenziali supportato. Poi il componente VPN chiede di eseguire un’operazione crittografica con quella chiave, e il modello di autorizzazione locale risponde. Solo dopo che entrambe riescono avviene la stretta di mano remota, dove il Mac valuta il gateway e il gateway valuta la prova del client.

Leggi la tabella dall’alto verso il basso e fermati alla prima riga che fallisce. Tutto ciò che sta sotto un errore non è dimostrato, ed è per questo che «il certificato non è attendibile» è una conclusione tanto comune quanto poco affidabile.

Che cosa copre davvero il permesso locale

Nel modello del portachiavi di macOS, gli elementi protetti portano regole di accesso specifiche per operazione e un elenco di applicazioni fidate. La firma con una chiave privata è una di queste operazioni, e le regole valgono per l’eseguibile che la esegue, non per il certificato in quanto documento. Il riferimento sul controllo degli accessi di Apple traccia inoltre una linea tra questo modello e il portachiavi iCloud e le disposizioni dei gruppi di accesso, perciò un consiglio scritto per uno non si trasferisce all’altro.

Ne seguono due conseguenze. Un certificato pubblico visibile in un elenco non dimostra che il componente in background della VPN possa raggiungere quella chiave. E un permesso concesso a un’applicazione frontale non dice nulla su un helper o un’estensione di rete separati, perché sono codice diverso con identità diverse.

Individua l’implementazione reale e il suo meccanismo supportato di condivisione delle credenziali invece di copiare un percorso di eseguibile da un client vecchio. Verifica prima quale identità il sistema offrirà:

security find-identity -v -p ssl-client

Leggere errSecInteractionNotAllowed

Quello stato segnala un’interazione non consentita con il Security Server e non dice nulla sulle catene di certificati. Leggilo insieme all’operazione che lo ha prodotto: una richiesta di firma emessa da un contesto che non può mostrare una richiesta all’utente fallisce così anche quando la chiave e il certificato sono entrambi perfettamente validi. L’operazione che lo ha registrato, non l’archivio dei certificati, è il punto da cui partire. Qualunque modifica alle ancore di fiducia lascerà l’errore esattamente dov’era.

Tratta quindi il codice come un motivo per esaminare contesto di esecuzione e autorizzazione. Trattarlo come prova che la CA del gateway non è attendibile ti manda nella metà sbagliata del problema, e la modifica che fai lì non influenzerà affatto l’errore.

Ripara in modo stretto, non ampio

Parti dalle istruzioni di registrazione o importazione del proprietario della connessione. Registra la versione del client, l’ambito del profilo, l’identità scelta e il primo errore locale rilevante, perché sono questi quattro fatti a servire a un passaggio al supporto e da cui dipende un confronto successivo. Un profilo gestito o un’identità supportata da hardware può richiedere che l’amministratore o il fornitore ripari il passaggio, e nessuna quantità di clic locali lo sostituisce.

Dove il prodotto si aspetta un’approvazione dell’utente, verifica quale componente la chiede e approva solo quell’accesso tramite il flusso supportato. Dove il componente non ha modo di sollevare una richiesta nel contesto in cui gira, il provisioning deve seguire il percorso documentato dal fornitore, non una finestra di dialogo strappata a un altro terminale.

Due modifiche vengono raggruppate nei consigli più vecchi, ed entrambe sono troppo ampie. Concedere a ogni applicazione l’accesso alla chiave privata allarga l’uso locale della chiave ben oltre il requisito, e impostare il certificato su Always Trust cambia la valutazione dei certificati per tutto ciò che sta sulla macchina. Nessuna delle due esprime «questa implementazione VPN approvata, con questa identità prevista».

Verifica localmente prima di leggere il gateway

Dopo una riparazione, conferma che l’operazione locale riesca prima di interpretare qualsiasi risposta dall’altro lato. Se la firma ora funziona, un successivo rifiuto di nome, catena o ammissione del client è un esito nuovo e non una ricaduta, e appartiene a un’altra decisione con un altro responsabile.

Un passaggio utile nomina quale delle tre decisioni è fallita e si ferma lì. Non include mai la chiave privata e non reimposta mai elementi del portachiavi non correlati nella speranza che un foglio pulito aiuti. Stabilisci queste due abitudini prima dell’incidente e non durante, quando la tentazione di provare tutto insieme è più forte. Un ticket che dice «portachiavi ricostruito» non dice quasi nulla al lettore successivo sul guasto originale.