strongSwan: tipo di chiave, loader e il backend sbagliato

Le estensioni dei file non identificano gli algoritmi delle chiavi, e un involucro .pem può contenere materiale RSA o ECDSA. PEM descrive come vengono avvolti i byte, mentre RSA ed ECDSA indicano algoritmi diversi, e un file PKCS12 è una terza cosa. strongSwan carica le credenziali tramite plugin e un backend di configurazione, quindi un certificato può comparire in un elenco mentre la chiave privata non diventa mai utilizzabile. Separate questi livelli prima di modificare qualsiasi segreto.

Codifica, algoritmo e confezionamento sono tre livelli

Un file di chiave ha una codifica, un algoritmo e spesso un contenitore. PEM è il noto involucro base64; DER è la sua controparte binaria; PKCS12 raggruppa un certificato con la sua chiave e la sua catena. Un file di catena di certificati è un altro contenitore e di solito non contiene alcuna chiave privata. Nessuna di queste etichette dice se il materiale all'interno è RSA o ECDSA.

Leggete l'algoritmo dall'oggetto stesso. Il nome commerciale di un fornitore o un'estensione di file non sono prove, perché lo stesso emittente può rilasciare tipi di chiave diversi.

Confrontate le chiavi pubbliche prima di incolpare il loader

Un certificato che si carica dimostra che il certificato è stato analizzato, non che la sua chiave privata sia presente o utilizzabile. Derivate la chiave pubblica dal certificato e dalla chiave privata proposta, poi confrontate i due digest. Se una delle estrazioni fallisce, fermatevi lì, perché il digest di un output vuoto non dimostra nulla. Digest uguali dimostrano che la coppia va insieme, e nient'altro sull'idoneità del certificato al lavoro.

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

Il secondo comando tocca materiale privato sulla vostra macchina ma emette solo la metà pubblica. Mantenetelo così e non incollate mai una chiave privata in un ticket. Se la chiave è cifrata, lasciate che lo strumento supportato chieda la passphrase invece di metterla su una riga di comando dove l'elenco dei processi può esporla.

ipsec.secrets legacy o credenziali swanctl

strongSwan ha due percorsi di credenziali comunemente usati. Il vecchio stack starter legge le voci specifiche del tipo da ipsec.secrets, e ogni voce deve indicare il tipo corretto per il materiale. Lo stack swanctl e vici carica le chiavi dalla propria directory delle credenziali tramite la propria configurazione. Modificare il file che il backend in esecuzione non legge non cambia nulla.

: ECDSA "/etc/ipsec.d/private/server-key.pem"

Scoprite quale backend è realmente in esecuzione, poi mettete la chiave dove quel backend guarda. manuale legacy di strongSwan 5.9 definisce le voci dei segreti specifiche del tipo, e non è documentazione swanctl. Mescolare le due cose produce un daemon che ignora un file che l'amministratore ritiene autorevole. Un ricaricamento che non segnala errori significa solo che la configurazione è stata analizzata.

Leggete l'evento di caricamento e il risultato dell'autenticazione

Dopo un ricaricamento controllato, leggete l'output di caricamento del daemon stesso per la chiave specifica. Un certificato elencato in un dump di stato non mostra che la chiave privata vi sia stata abbinata.

Se un client continua a fallire, tenete separati l'evento del server e l'errore del client. La validazione della catena, la corrispondenza delle identità e la compatibilità dei metodi sono questioni successive con le loro prove. Annotate l'esito con il percorso esatto della chiave e il digest che avete confrontato, perché il turno successivo ripeterà altrimenti lo stesso ricaricamento. Sostituire la CA non è la prima risposta a una discrepanza del loader.