Openssl ca [-verbose][-config filename][-name section][-gencr][-revoke file][-subj arg][-crldays days][-crlhours hours][-crlext section][-startdate date][-enddate date][-days arg][-md arg][-policy arg][-keyfile arg][-passin arg][-cert file][-in file][-out file][-notext][-outdir dir][-spack file][-ss_cert file][-preserveDN][-batch][-msie_hack][-extensions section][-extfile section]
Il comando ca è un’applicazione minimale CA. Esso può essere usato per firmare
richieste di certificati in una varietà di formati e generare CRLs; esso mantiene
anche un database dei certificati pubblicati e il loro stato.
Le opzioni descritte saranno divise in base al loro scopo.
Le opzioni per ca sono contenute nella sezione ca del file di configurazione. Molte di
queste sono identiche alle opzioni delle linee di comando. Se l’opzione è presente sia nel file di
configurazione che nella linea di comando, allora viene usato il valore della linea di comando.
Quando un’opzione è descritta come obbligatoria allora essa deve essere presente nel file di
configurazione o nella linea di comando equivalente usata.
La sezione policy consiste di un insieme di variabili corrispondenti al campo DN del certificato. Se un valore viene rilevato, allora il valore del campo deve corrispondere allo stesso campo nel certificato CA. Se un valore è “supplied” allora esso deve essere presente. Se il valore è “optional” allora esso può essere presente. Alcuni campi non menzionati nella sezione policy vengono cancellati silenziosamente, a meno che l’opzione –preserveDN è settata.
L’input dell’opzione del comando di linea –spkac è una chiave pubblica e un challenge firmati da Netscape. Questo, di solito, deriverà
dall’etichetta KEYGEN in un formato HTML per creare una nuova chiave privata.
E’ comunque possibile creare SPKACs usando l’utility spkac.
Il file conterrebbe la variabile SPKAC settata al valore SPKAC e anche la componente DN richiesta come
coppia nome-valore. Se si ha bisogno di includere la stessa componente due
volte allora essa può essere preceduta da un numero e da un ‘.’.
NOTA: questi esempi assumono che la struttura della directory ca è
già settata e il file pertinente già esiste. Ciò di solito, implica la
creazione di un certificato CA e di una chiave privata con req, di un file del numero seriale e di un file indice vuoto e
porre loro nelle directories pertinenti.
Per usare il semplice file di configurazione seguente le directories demoCA, demoCA/private e demoCA/newcerts
dovrebbero essere create. IL certificato CA dovrebbe essere copiato nel file
demoCA/cacert.pem e la sua chiave privata nel file demoCA/private/cakey.pem. Un file
demoCA/serial dovrebbe essere creato contenente per esempio “01” oltre ad un file indice vuoto
demoCA/index.txt.
1) Firmare un certificato
openssl ca –in req.pem –out newcert.pem2) Firmare un certificato, usando l’estensione CA
openssl ca –in req.pem – extensions v3 _ca–out newcert.pem3) Generare una CRL
openssl ca –gencrl –out crl.pem4) Firmare varie richieste
openssl ca –infiles req1.pem req2.pem req3.pem5) Certificare un Netscape SPKAC
openssl ca –spkac spkac.txt6) Un semplice file SPKAC (la linea SPKAC potrebbe essere troncata per chiarezza)
SPKAC=MIG0MGAwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAn7PdhCeV/xIxUg8V70YRxL2A5
7) Un semplice file di configurazione con la relativa sezione per ca
[ca] |
||
default_ca | =CA_default | #La sezione di default ca |
[CA_default] |
||
dir | =demoCA | #Top dir |
database | =$dir/index.txt | #File indice |
new_certs_dir | =$dir/newcerts | #Directory dei nuovi certificati |
certificate | =$dir/cacert.pem | #Il certificato CA |
serial | =$dir/serial | #File del numero seriale |
private_key | =$dir/private/cakey.pem | #La chiave privata CA |
RANDFILE | =$dir/private/rand | #File di dati casuali |
default_days | =365 | #Quanto dura il certificato |
default_crl_days | =30 | #Tempo fino al prossimo CRL |
default_md | =md5 | #Message digest da usare |
policy | =policy_any | #La sezione di default di policy |
nameopt | =default_ca | #Opzione per mostrare il nome del soggetto |
certopt | =default_ca | #Opzione per mostrare il certificato |
copy_extensions | =none | #Non copia l'estensione del certificato |
[policy any] |
||
CountryName | =supplied |
|
StateOrProvinceName | =optional |
|
organizationName | =optional |
|
organizationalUnitName | =optional |
|
commonName | =supplied |
|
emailAddress | =optional |
Il comando ca è alquanto stravagante e allo stesso tempo assolutamente non amichevole. L’utility CA fu in origine pensato come un
esempio per spiegare come le cose sarebbero dovute essere fatte in una CA. Non
è stato pensato per essere usato come un CA pienamente funzionante esso stesso:
alcune persone lo stanno usando per questo scopo.
Il comando ca è in effetti un comando per singolo utente: nessun controllo viene fatto su vari files, per
cui tentare di eseguire più di un comando ca sullo stesso database può avere risultati imprevedibili.
La seguente Tabella 8.1 mostra i file per la gestione della CA.
NOTA: la locazione di tutti i files può cambiare sia con
le opzioni a tempo di compilazione, sia tramite entrate nel file di configurazione, sia tramite variabili d’ambiente o opzioni di linea di comando.
I valori seguenti riflettono i valori di default.
/usr/local/ssl/lib/openssl.cnf |
master file di configurazione |
./demoCA |
directory principale CA |
./demoCA/cacert.pem |
certificato CA |
./demoCA/private/cakey.pem |
chiave privata CA |
./demoCA/serial |
file del numero seriale |
./demoCA/serial.old |
backup del file del numero seriale |
./demoCA/index.txt |
file indice in formato testo |
./demoCA/certs |
file di output del certificato |
./demoCA/.md |
informazioni casuali CA |
OPENSS_CONF riflette la locazione del file di configurazione principale; esso può essere sovrascritta dall’opzione da linea di comando –config.
Il file indice del database è una parte critica del processo e se corrotto può essere difficile
aggiustarlo. E’ teoricamente possibile ricostruire il file indice da tutti i
certificati emessi e dal CRL corrente: comunque non c’è l’opzione per fare questo.
L’entrata dell’estensione del CRL non può correntemente essere creata: solo l’estensione del CRL può
essere aggiunta.
Caratteristiche di V2 CRL come un supporto al delta-CRL e ai numeri CRL non sono correntemente
supportati.
Sebbene molte richieste possono essere introdotte e trattate in una sola volta, è possibile solo
includere uno SPKAC o un certificato firmato da se stesso.
L’uso si un database nella memoria può causare problemi quando un grande numero di certificati sono
presenti poiché, come il nome implica, il database deve essere tenuto in memoria.
Non è possibile certificare 2 certificati con lo stesso DN: questa è una conseguenza di come il database è
indicizzato e non è possibile sistemarlo facilmente senza l’introduzione di altri problemi.
Alcuni S/MIME clients possono usare 2 certificati con lo stesso DN per separare le firme e le chiavi
di cifratura.
Il comando ca necessita di riscrivere o la funzionalità richiesta
esposta ad entrambi un comando oppure il livello di interfaccia così molte
utility amiche (script Perl o GUI) possono trattare cose propriamente.
Gli script CA.sh e CA.pl aiutano un po’ ma non molto.
Alcuni campi in una richiesta che non sono presenti in una policy sono silenziosamente cancellati.
Questo non accade se l’opzione –preserveDN è usata.
Il comportamento dovrebbe essere più amichevole e configurabile.
Cancellando alcuni comandi e rifiutando di voler certificare un certificato si potrebbe creare
un file vuoto.
L’opzione copy_extensions dovrebbe essere usata con cautela. Se non si fa attenzione
allora esso potrebbe essere un rischio per la sicurezza.
Per esempio se la richiesta di un certificato contiene una estensione basicConstraints con CA:TRUE e il
valore copy_extensions è settato a copiare tutto e l’utente non tiene presente
ciò quando il certificato è visualizzato allora esso tratterà il richiedente
come un certificato valido CA.
Questa situazione potrebbe essere evitata fissando copy_extensionsper copiare e includendo
basicConstraints con CA:FALSE nel file di configurazione. Allora se la richiesta contiene un’estensione
basicConstrains essa sarà ignorata.
E’ consigliabile includere anche valori per altre estensioni come keyUsage per evitare una
richiesta fornendo proprio il suo valore.
Restrizioni aggiuntive possono essere poste sul certificato CA stesso.
Per esempio, se il certificato CA contiene:
basicConstrains = CA:TRUE,pathlen:0allora anche se un certificato è emesso con CA:TRUE non sarà valido.
req(1), spkac(1), x509(1), CA.pl(1), config(5)
crl – utility CRL
openssl crl [-inform PEM|DER] [-outform PEM|DER] [-text] [-in filename] [-out filename] [-noout] [-hash] [-issuer] [-lastupdate] [-nextupdate] [-CAfile file] [-CApath dir]
Il comando crl processa il file CRL nel formato DER o PEM.
Il formato PEM CRL usa le seguenti linee di intestazione e chiusura:
----------BEGIN X509 CRL-------
----------END X509 CRL----------
1) Converte un file CRL da PEM a DER
openssl crl –in crl.pem –outform DER –out crl.der2) L’output del formato testo del certificato codificato DER:
>openssl crl –in crl.der –text –nooutIdealmente dovrebbe essere possibile creare un CLR usando opzioni appropriate e vari file.
crl2pkcs7(1), ca(1), x509(1)
crl2pkcs7 – crea una struttura PKCS#7 da un CRL e certificati.
openssl pkcs7 [-inform PEM | DER] [-outform PEM | DER] [-in filename] [-out filename] [-print_certs]
Il comando crl2pkcs7 prende un CRL opzionale e uno o più certificati e li converte in una struttura “certificate only” PKCS#7.
1) Crea una struttura PCKS#7 da un certificato e CRL:
openssl crl2pcks7 –in crl.pem –certfile cert.pem –out p7.pem2) Crea una struttura PCKS#7 nel formato DER senza alcun CRL da vari differenti certificati:
openssl crl2pcks7 –nocrl –certfile newcert.pem
-certfile demoCA/cacert.pem –outform DER –out p7.der
Il file di output è una strtuttura dati firmata PKCS#7 contenente nessuna firma, solo certificati e CRL opzionali.
Questa utility può essere utilizzata per inviare certificati e CAs per Netscape come parte del
processo di iscrizione del certificato. Questo include l’invio dell’output codificato DER come
MIME type application/x-x509-user-cert.
Il formato codificato PEM con le linee di intestazione e di chiusura rimosse può essere usato per installare i
certificati degli utenti e Cas in MSIE che usa il controllo Xenroll.
ocsp – Online Certificate Status Protocol utility
openssl ocsp [-out file] [-issuer file] [-cert file] [-serial n] [-req_text] [-resp_text] [-text] [-reqout file] [-respout file] [-reqin file] [-respin file] [-nonce] [no_nonce] [-url responder_url] [-host host:n] [-path] [-CApath file] [-CAfile file] [-VAfile file] [-verify_certs file] [-noverify] [-trust_other] [-no_intern] [-no_sig_verify] [-no_cert_verify] [-no_chain] [-no_cert_checks] [-validity_period nsec] [-status_age nsec]
ATTENZIONE: questa è una documentazione preliminare e soggetta a cambiamenti.
L’OCSP (Online Certificate Status Protocol) abilita le applicazioni a determinare lo stato
(revoca) di un certificato identificato (RFC 2560).
Il comando ocsp esegue molti compiti comuni di OCSP. Esso può essere usato per stampare richieste e risposte, creare
richieste ed inviare domande ad un OCSP che risponde.
La risposta OCSP segue le regole specificate in RFC2560.
Inizialmente viene individuato il certificato di chi da la risposta OCSP e viene controllata la firma sulla richiesta OCSP usando la chiave pubblica del certificato di chi risponde.
Poi viene effettuata una normale verifica del certificato sul certificato del rispondente costruendo una catena di certificati nel processo. Le locazioni dei certificati fidati usati per costruire la catena possono essere specificati con le opzioni CAfile e CApath oppure possono essere cercati nella directory standard dei certificati OpenSSL.
Se la verifica iniziale fallisce, allora il processo di verifica OCSP si ferma con un errore.
Altrimenti il certificato CA emesso nella risposta viene confrontato con il certificato del rispondente OCSP: se c’è una corrispondenza allora la verifica OCSP ha successo.
Altrimenti la CA del certificato di chi ha risposto viene controllata tramite il certificato della CA emesso nella richiesta. Se esiste una corrispondenza e nel certificato del rispondente è presente l’uso della chiave estesa OCSPSigning allora la verifica OCSP ha successo.
Altrimenti la root CA del CA rispondente OCSP viene verificata per controllare se è fidata per la firma OCSP. Se ciò è vero, la verifica OCSP ha successo.
Se nessuno di questi controlli ha successo, allora la verifica OCSP fallisce.
Ciò che questo significa effettivamente è che se il certificato del rispondente OCSP è autorizzato direttamente dal CA, se esso sta rilasciando informazioni di revoca (e se è correttamente configurato), allora la verifica avrà successo.
Se il rispondente OCSP è un rispondente globale che può dare dettagli su diverse CA ed ha una sua propria catena di certificati separata, allora la sua root CA può essere fidata per la firma OCSP. Per esempio:
openssl x509 –in ocspCA.pem –addtrust OCSPSigning –out trustedCA.pemIn alternativa, il certificato del rispondente stesso può essere reso esplicitamente fidato con l’opzione VAfile.
Come notato, molte delle opzioni di verifica servono solo a scopi di testing e debug. Normalmente solo le opzioni CApath, CAfile e (se il rispondente è un global VA) VAfile sono necessarie.
1) Creare una richiesta OCSP e scriverla in un file:
openssl ocsp –issuer issuer.pem –cert c1.pem
–cert c2.pem –reqout req.der2) Inviare una richiesta ad un rispondente OCSP con URL http://ocsp.myhost.com/, salvare la risposta in un file e stamparla in formato testo:
openssl ocsp –issuer issuer.pem –cert cert1.pem –cert cert2.pem
–url http://ocsp.myhost.com/ -resp_text –respout resp.der3) Leggere una risposta OCSP e stamparla in formato testo:
openssl ocsp –respin resp.der –textreq – utility di richiesta e generazione di certificati PKCS#10.
openssl req [-inform PEM | DER] [-outform PEM | DER] [-in filename] [-passin arg] [-out filenam] [-passout arg] [-text] [-noout] [-verify] [-modulus] [-new] [-rand file(s)] [-newkey rsa:bits] [-newkey dsa:file] [-nodes] [-key filename] [-keyform PEM | DER] [-keyout filename] [-[mda5 | sha1 | md2 | mdc2]] [-config filename] [-subj arg] [-x509] [-days n] [-set_serial n] [-asn1 –kludge] [-newhdr] [-extensions section] [-reqexts section] [-batch] [-verbose].
Il comando req principalmente crea e processa richieste di certificati in formato PKCS#10. Esso può, addizionalmente, creare certificati firmati da se stesso da usare, per esempio, come root CA.
Le opzioni di configurazione sono specificate nella sezione req del file di configurazione. Come con tutti i file di
configurazione, se nessun valore viene specificato nella sezione specifica
(cioè, req) allora viene ricercata anche una sezione iniziale senza nome o una sezione di default.
Le opzioni disponibili sono descritte in dettaglio di seguito.
Ci sono due formati separati per le sezioni distinguished name e attributes. Se l’opzione prompt è settata a no, allora questa sezioni consistono solo di nomi e valori di campi. Ad esempio:
CN= My Name
OU = My Organization
EmailAddress = someone@somewhere.org
Ciò consente a programmi esterni (come quelli basati su GUI) di generare un file template con tutti i nomi ed i valori dei campi e
di passarlo a req. Un esempio di questo tipo di file di configurazione è
contenuto nella sezione ESEMPI.
In alternativa, se l’opzione prompt è assente o non è settata a no, allora il file contiene informazioni sui campi da
mostrare. Esso consiste di linee della forma:
fieldName = “prompt”
fieldName_default = “default field value”
fieldName_min = 2
fieldName_max = 4
fieldName è il nome del campo che bisogna usare, come ad esempio commonName (o CN). La stringa prompt è usata per
chiedere all’utente di inserire dettagli rilevanti. Se l’utente non inserisce
niente, allora viene usato il valore di default. Se nessun valore di default è
presente, allora il campo viene omesso. Un campo può inoltre essere omesso
anche se è presente un valore di default semplicemente inserendo il carattere ‘.’.
Il numero di caratteri inseriti deve essere compreso tra i limiti fieldName_min e fieldName_max: ci potrebbero anche
essere delle ulteriori restrizioni basate sul particolare campo da usare (per
esempio, countryName potrebbe dover essere sempre di due caratteri e
dovrebbe essere dato solo in formato PrintableString).
Alcuni campi (come organizationName) possono essere usati più di una volta in un DN. Ciò può presentare problemi dato che i file di
configurazione non riconoscono lo stesso nome presente due volte. Per evitare
questo problema, se il fieldName contiene qualche carattere seguito da un full
stop, essi saranno ignorati. Così, quindi, un secondo organizationName può
essere inserito chiamandolo “1.organizationName”.
I nomi di campi attualmente permessi sono tutti i nomi lunghi o corti degli identificatori di oggetti. Questi sono compilati in
OpenSSL e includono i soliti valori come commonName, countryName,
localityName, organizationName, organizationUnitName, stateOrProvinceName.
In aggiunta, sono presenti anche emailAddress, name, surname,
givenName, initials e dnQualifier.
Identificatori di oggetti addizionali possono essere definiti con le opzioni oid_file e oid_section nel file di
configurazione. Ogni campo addizionale sarà trattato come una DirectoryString.
1) Esamina e verifica la richiesta di certificato:
openssl req –in req.pem –text –verify –noout2) Crea una chiave privata e poi genera una richiesta di certificato da essa:
openssl genrsa –out key.pem 1024
openssl req –new –key key.pem –out req.pem3) Lo stesso dell’esempio 2 ma usando solo req:
openssl req –newkey rsa :1024 –keyout key.pem –out req.pem4) Genera un certificato di root firmato da se stesso:
openssl req –x509 –newkey rsa:1024 –keyout key.pem –out req.pem5) Esempio di un file puntato da una opzione oid_file:
1.2.3.4 |
nome breve |
un nome lungo |
1.2.3.6 |
altro nome |
altro nome lungo |
6) Esempio di una sezione puntata da oid_section usando la variabile di espansione:
testoid1 = 1.2.3.5
testoid2 = ${testoid1}.6
7) Semplice file di configurazione che richiede i valori dei campi:
[req] | |
default_bits | =1024 |
default_keyfile | =privkey.pem |
distinguished_name | =req_distinguished_name |
attributes | =req_attributes |
x509_extensions | =v3_ca |
dirstring_type | =nobmp |
| |
[req_distinguished_name] | |
countryName | =Country Name (2 letter code) |
countryName_default | =AU |
countryName_min | =2 |
countryName_max | =2 |
| |
localityName | =Locality Name (e.g. city) |
| |
organizationalUnitName | =Organizational Unit Name (e.g. section) |
| |
commonName | =Common Name (e.g. your name) |
commonName_max | =4 |
| |
emailAddress | =E-Mail Address |
emailAddress_max | =40 |
| |
[req_attributes] | |
challengePassword | =A Challenge Password |
challengePassword_min | =4 |
challengePassword_max | =20 |
| |
[v3_ca] | |
subjectKeyIdentifier | =hash |
authorityKeyIdentifier | =keyid:always,issuer:always |
basicConstraints | =CA:true |
8) Semplice configurazione contenete tutti i valori dei campi:
[req] | |
default_bits | =1024 |
default_keyfile | =privkey.pem |
distinguished_name | =req_distinguished_name |
attributes | =req_attributes |
prompt | =no |
output_password | =mypass |
| |
[req_distinguished_name] | |
C | =GB |
ST | =Test State or Province |
L | =Test Locality |
O | =Organization Name |
OU | =Organizational Unit Name |
CN | =Common Name |
emailAddress | =test@email.address |
| |
[req_attributes] | |
challengePassword | =A Challenge Password |
Le linee di intestazione e terminazione del formato PEM sono normalmente:
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----Alcuni software (alcune versioni di Netscape certificate server) invece richiedono:
-----BEGIN NEW CERTIFICATE REQUEST-----
-----END NEW CERTIFICATE REQUEST-----
che vengono prodotte con l’opzione –newhdr ma sono comunque compatibili.
Entrambe le forme sono accettate in maniera trasparente in input.
Le richieste di certificato generate da Xenroll con MSIE hanno estensioni aggiunte. Esse includono l’estensione keyUsage che
determina il tipo di chiave (solo firma o general purpose) ed ogni OID
addizionale inserito dallo script in una estensione extendedKeyUsage.
I seguenti messaggi vengono presentati frequentemente:
Using configuration from /some/path/openssl.cnf
Unable to load config infoCiò è seguito un po’ di tempo dopo da…
unable to find ‘distinguished name’ in config
problems making Certificate Request
Il primo messaggio di errore è il clue: non è possibile trovare il file di configurazione! Certe operazioni (come l’esame di
una richiesta di certificato) non hanno bisogno di un file di configurazione,
per cui il suo utilizzo non è obbligatorio. La generazione di certificati o richieste
non ha bisogno di un file di configurazione. Questo potrebbe essere visto come un bug.
Un altro messaggio oscuro è il seguente:
Attributes:
a0.00che viene mostrato quando non sono presenti attributi e la richiesta include il corretto insieme vuoto (la codifica DER del quale è 0xa0 0x00). Se, invece, appare solo
Attributes:allora l’insieme vuoto è mancante e la codifica è tecnicamente non valida (ma è tollerata). Per maggiori informazioni vedere la descrizione dell’opzione a linea di comando –asn1-kludge.
La variabile OPENSSL_CONF, se definita, consente di specificare una locazione di un file di configurazione alternativo. Essa può essere modificata con lo switch a linea di comando –config. Per ragioni di compatibilità, anche la variabile d’ambiente SSLEAY_CONF serve per lo stesso scopo, ma il suo uso è scoraggiato.
La gestione da parte di OpenSSL delle T61Strings (aka TeletexStrings) è sbagliata: esso, in effetti, le tratta come ISO-8859-1
(Latin 1) (Netscape e MSIE hanno un comportamento simile). Questo può causare
problemi se si ha bisogno di caratteri non disponibili in PrintableStrings e
non si vuole usare BMPStrings.
Come conseguenza della gestione di T61Strings, l’unico modo di rappresentare caratteri accentati è di usare le BMPStrings:
sfortunatamente, Netscape attualmente ha degli errori su tali stringhe. Se si
ha bisogno di usare caratteri accentati su Netscape e MSIE, allora bisogna per
forza usare la forma non valida di T61Strings.
La presentazione delle domande a video non è molto amichevole. Essa non consente di confermare ciò che si è appena digitato. Altre
cose, come le estensioni alle richieste di certificato possono essere definite
solo staticamente nel file di configurazione. Alcune di esse, invece, come
l’indirizzo e-mail nel subjectAltName potrebbero essere inserite dall’utente.
x509(1), ca(1), genrsa(1), gendsa(1), config(5).
verify - Utility per verificare i certificati
openssl verify [-CApath directory] [-CAfile file] [-purpose purpose] [-untrusted file] [-help] [-issuer_checks] [-verbose] [-] [certificates]
Il comando verify verifica catene di certificati.
Il programma di verifica usa le stesse funzioni del internal SSl e S/MIME
verification, quindi questa descrizione viene applicata anche a queste
operazioni di verifica
C’è una differenza cruciale tra le operazioni di verifica realizzate dal programma di verifica:
quando possibile viene fatto un tentativo per continuare dopo mentre le operazioni di
verifica si fermano sul primo errore. Questo permette di determinare tutti i
problemi che si hanno con una catena di certificati.
Le operazioni di verifica consistono di un numero di passi separati.
Per prima cosa una catena di certificati è costruita partendo dal certificato
fornito e finisce nella root CA. Un errore si ha se l’intera catena non può
essere costruita. La catena è costruita controllando il certificato
dell’emittente del certificato corrente. Se viene trovato un certificato che è
esso stesso distributore si assume essere la root CA.
Lo stesso processo di guardare i distributori dei certificati richiede un numero di passi. Nella versione prima
di opensssl 0.9.5 il primo certificato il cui subject name combaciava con il
distributore del certificato corrente era presunto essere il certificato dei distributori.
Da openssl 0.9.6 tutti i certificati il cui subject name combacia con il iusser name del corrente certificato sono soggetti
ad altri test. I relativi componenti dell’autorità per l’identificazione della
chiave del certificato corrente (se presente) deve combaciare con il subject
key identifier (se presente), l’emittente e il numero seriale del candidato
emittente, in più la keyUsage extension del candidato emittente (se presente)
deve permettere la firma del certificato.
Per prima cosa si vede nella lista dei certificati non fidati e se non vi è un
match si vanno a vedere i certificati fidati.
La root CA è sempre in alto nella lista dei certificati fidati: se il certificato
da verificare è un certificato root allora esattamente un match viene trovato
nella lista dei fidati.
La seconda operazione è di verificare tutte le estensioni dei certificati non fidati per coerenza con gli scopi forniti. Se
l’opzione –purpose non è inclusa allora nessun controllo viene effettuato. Il
certificato fornito deve avere una estensione compatibile con gli scopi
forniti e tutti gli altri certificati devono anche essere certificati CA
validi. Le estensioni precise richieste sono descritte con più dettaglio nella
sezione CERTIFICATE EXTENTION dell’utility x509.
La terza operazione è di verificare i trust setting sulla root CA. La root CA
dovrebbe essere validata per gli scopi forniti. Per la compatibilità con le
versioni precedenti di ssleay e openssl un certificato senza trust setting è
considerato essere valido per tutti gli scopi.
L’operazione finale è quella di verificare la validità della catena di certificati. Il
periodo di validità è verificato con il tempo corrente di sistema e i dati
notBefore e notAfter del certificato.
Le firme del certificato sono anche verificate in questo punto.
Se tutte le operazioni sono completate con successo allora il certificato è
considerato valido. Se qualche operazione fallisce il certificato non è valido.
Quando un operazione di verifica fallisce il messaggio di output potrebbe essere
qualcosa di cifrato.
La forma generale del messaggio di errore è:
server.pem:/C=AU/ST=Queensland/O=CryptSoft Pty Ltd/CN=Test CA (1024 bit)
error 24 at 1 depth lookup:invalid CA certificate
la prima linea contiene il nome del certificato che deve essere verificato seguito
dal subject name del certificato. La seconda linea contiene il numero
dell’errore e la profondità. La profondità è il numero di certificati già verificati quando il
problema è stato trovato partendo con zero per il certificato già verificato
poi 1 per il CA che ha firmato il certificato e così via. Infine viene
presentata una versione testuale dei numeri degli errori.
Una lista esaustiva di messaggi e codici di errore è mostrata di seguito, questa
include il nome del codice di errore così come è definito nel file header x509.vfy.h. Alcuni codici di errore sono
definiti ma mai restituiti: questi sono descritti come “unused”.
0 X509_V_OK2 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT3 X509_V_ERR_UNABLE_TO_GET_CRL4 X509_V_ERR_UNABLE_TO_DECRYPT_CERT_SIGNATURE5 X509_V_ERR_UNABLE_TO_DECRYPT_CRL_SIGNATURE6 X509_V_ERR_UNABLE_TO_DECODE_ISSUER_PUBLIC_KEY7 X509_V_ERR_CERT_SIGNATURE_FAILURE8 X509_V_ERR_CRL_SIGNATURE_FAILURE9 X509_V_ERR_CERT_NOT_YET_VALID10 X509_V_ERR_CRL_NOT_YET_VALID11 X509_V_ERR_CERT_HAS_EXPIRED12 X509_V_ERR_CRL_HAS_EXPIRED13 X509_V_ERR_ERROR_IN_CERT_NOT_BEFORE_FIELD14 X509_V_ERR_ERROR_IN_CERT_NOT_AFTER_FIELD15 X509_V_ERR_ERROR_IN_CRL_LAST_UPDATE_FIELD16 X509_V_ERR_ERROR_IN_CRL_NEXT_UPDATE_FIELD17 X509_V_ERR_OUT_OF_MEM18 X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT19 X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN20 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY21 X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE22 X509_V_ERR_CERT_CHAIN_TOO_LONG23 X509_V_ERR_CERT_REVOKED24 X509_V_ERR_INVALID_CA25 X509_V_ERR_PATH_LENGTH_EXCEEDED26 X509_V_ERR_INVALID_PURPOSE27 X509_V_ERR_CERT_UNTRUSTED28 X509_V_ERR_CERT_REJECTED29 X509_V_ERR_SUBJECT_ISSUER_MISMATCH30 X509_V_ERR_AKID_SKID_MISMATCH31 X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH32 X509_V_ERR_KEYUSAGE_NO_CERTSIGN50 X509_V_ERR_APPLICATION_VERIFICATION
Benché i controlli sull’emittente sono notevolmente migliorati dalla vecchia tecnica,
soffrono ancora di limitazioni nel fondamentale X509_LOOKUP API. Una conseguenza di ciò è che i certificati fidati
che hanno una corrispondenza col subject name devono comparire in un file (
come specificato dalla opzione –CAfile) o in una directory (come specificato
dalla opzione –CApath). Se occorrono in entrambe allora solo i certificati nel
file verranno considerati.
Versioni precedenti di openssl assumono che i certificati il cui subject name combaciano
sono identici e li gestiscono male.
x509(1)