Inventario dei certificati VPN: cosa può dimostrare il registro della CA
Una cartella sul server, un registro della CA, un elenco di revoca e una tabella delle sessioni rispondono a domande diverse. Teneteli separati quando inventariate le identità VPN.
Il vostro gateway accetta un certificato client che non ha mai visto, perché ciò con cui è configurato è un emittente fidato, e il certificato arriva durante l’handshake. È così che il protocollo deve funzionare, ed è anche per questo che un elenco di directory sul server è un cattivo inventario. L’emittente sa cosa ha creato, il server sa cosa si è connesso, e lo stato di revoca sa cosa è stato ritirato. Un inventario che mescola questi tre registri finisce per affermare qualcosa che nessuno di essi ha detto.
Il gateway si fida di un emittente, non di un elenco di file
La validazione confronta un certificato presentato con un’ancora di fiducia, così un’identità creata ieri dallo stesso emittente si connette senza essere mai esistita sul disco del server. Non serve copiare nulla perché ciò accada, e nessuno deve approvarlo a mano. I registri del server descrivono quindi arrivi, non la popolazione di identità che potrebbero arrivare.
Il divario inverso è altrettanto scomodo. Una directory può contenere certificati scaduti, revocati e identità emesse per dispositivi mai distribuiti. Contare i file risponde a quanti file ci sono, che è una domanda che nessuno ha posto. Partite invece dai registri che hanno significato.
Quattro domande, quattro registri diversi
Ogni tipo di registro risponde bene a una domanda e male alle altre, perciò un rapporto che li fonde sembra completo mentre è sbagliato in un modo preciso. La tabella seguente li ordina in base alla domanda che risolvono e non al sistema che li produce.
| Question you are answering | Where the answer lives | How quickly it changes | What it will never show |
|---|---|---|---|
| Was this identity ever created? | The issuer's issuance database | Only when something is issued | Whether the device still exists |
| Is a copy sitting on this host? | The paths you actually inspected | Whenever anyone copies files | Certificates that were never copied here |
| Has the issuer withdrawn it? | Published revocation state | When the issuer next publishes | Withdrawals that are not published yet |
| Is it connected right now? | The live session table | Continuously | Anything about past or future sessions |
Un archivio di certificati pubblici non è un segreto, poiché non contiene chiavi private, ma non è nemmeno condivisibile. I soggetti e i nomi dei dispositivi rivelano dettagli operativi, e il rapporto deve restare presso il pubblico che ne ha bisogno. Le chiavi private restano del tutto fuori dall’inventario, perché l’inventario ha bisogno di metadati e non di credenziali.
Emittente e numero di serie sono l’unica chiave stabile
I soggetti vengono riciclati e i nomi dei file riutilizzati, quindi un nome che l’anno scorso identificava un dispositivo oggi può identificarne un altro. Nessuno dei due è una chiave, e un rapporto costruito su uno di essi finirà per fondere due identità in una sola riga.
La coppia emittente e numero di serie identifica un certificato in modo univoco, e entrambi i campi provengono dal certificato stesso. Registrateli con il soggetto, le date di validità, la fonte da cui è arrivata la copia e la persona o il dispositivo responsabile. Aggiungete lo stato di revoca e di distribuzione come campi separati con i propri istanti di osservazione, perché un certificato dentro la sua finestra di validità non è automaticamente autorizzato. Questi due fatti vivono in sistemi diversi, e fonderli nasconde il caso in cui un’identità è stata ritirata mentre il suo file sembra ancora aggiornato.
Leggete un certificato alla volta
Un carattere jolly che si espande su una directory non è un’interfaccia batch, e nasconde quale file ha prodotto quale output. Leggete i metadati certificato per certificato, e leggete il lato revoca dal suo stesso artefatto. Il riferimento di OpenSSL x509 elenca i campi che queste opzioni stampano.
openssl x509 -in <cert>.pem -noout -issuer -serial -subject -dates -fingerprint -sha256
openssl crl -in <issuer>.crl -noout -text | head -n 40Per una PKI Easy-RSA gestita, interrogate il database di emissione tramite il flusso di lavoro supportato dallo strumento invece di supporre una disposizione di directory, e tenete gli originali in sola lettura mentre l’inventario viene composto. Il formato del registro è abbastanza regolare per contare le voci valide ed elencare quelle ritirate senza aprire il database a mano.
grep -c '^V' pki/index.txt
grep '^R' pki/index.txt | cut -f4,5Un inventario che sopravvive alla prossima emissione
Un’estrazione una tantum di una directory diventa obsoleta nel momento in cui viene emesso il certificato successivo, quindi costruite il rapporto dal flusso di emissione e lasciate che si aggiorni come parte del funzionamento normale. Ciò rende anche il rapporto riproducibile, il che conta quando due persone non sono d’accordo su cosa è stato emesso.
Usate il risultato per decisioni di rinnovo e dismissione e non come esercizio di foglio elettronico. Eliminare una copia locale non invalida le copie remote che esistono già. Ritirate l’identità tramite il flusso di revoca e autorizzazione configurato, poi registrate il ritiro con la sua data. Un’identità scomparsa dal server ma ancora fidata dall’emittente non è stata dismessa, e questa differenza separa un inventario accurato da uno che si limita a rassicurare.