Sisteme care utilizează certificate și PKI
Eforturile tehnologilor de a îmbunătăți securitatea pe Internet au avut ca rezultat dezvoltarea unui grup de protocoale de securitate precum S/MIME, TLS și IPsec. Toate aceste protocoale folosesc criptografia cu cheie publică pentru a asigura confidențialitatea, integritatea datelor, autentificarea sursei de dateși nerepudierea.
Scopul PKI este de a oferi un management sigur și eficient al cheilor și certificate de cheie publică. Utilizatorii sistemelor bazate pe PKI trebuie să aibă încredere că, în orice moment, atunci când comunică cu o anumită entitate, se bazează pe o cheie publică asociată cu o cheie privată deținută de acea entitate. Această încredere vine din folosire certificate de cheie publică, legând valorile cheii publice de proprietarii lor. Conectarea are loc ca urmare a verificării de către un CA de încredere identitatea subiectuluiși asigurări semnătură digitală fiecare certificat de cheie publică.
| termenii PKIX | Termen în engleză | Abreviere |
|---|---|---|
| Termen în rusă | Autoritate de atribut | A.A. |
| Centru de atribute | Certificat de atribut | A.C. |
| Certificat de atribut | Certificat | |
| Certificat | Autoritatea de Certificare | C.A. |
| Autoritatea de certificare (CA) | Politica certificatelor | C.P. Politica de aplicare a certificatelor |
| (PPS) | Declarație de practică de certificare | C.P.S. |
| Regulamente CA | Entitate finală | E.E. |
| Sfârșitul subiectului | Certificat de cheie publică | Certificat de cheie publică |
| PKC | Infrastructură cu cheie publică | PKI |
| Infrastructură cu cheie publică | Infrastructura de gestionare a privilegiilor | PMI |
| Infrastructura de gestionare a privilegiilor | Autoritatea de înregistrare | R.A. Centrul de înregistrare |
| (RC) | Partidul de baza | |
| Partidul de baza | Rădăcină CA | |
| Rădăcină CA | Subordonat CA | |
| Subordonat CA | Subiect | |
| Subiect | Top CA |
Conform standardelor PKIX, PKI este un set de software, hardware, personal și politici și proceduri necesare pentru a crea, gestiona, stoca, distribui și revoca certificate de cheie publică. Componentele PKI sunt prezentate în tabel. 15.6. Certificat de cheie publică are o perioadă de valabilitate limitată, care este stabilită în cuprinsul certificatului. Deoarece clientul trebuie să poată verifica în mod independent semnătura certificatului de cheie publică și perioada de valabilitate a acestuia, certificatele trebuie să fie publicate și distribuite în mod deschis chiar și prin intermediul sistemelor de comunicații și servere nesigure.
| Componentele PKI | Componentă |
|---|---|
| Descriere Autoritățile de certificare | (UC) |
| Eliberarea și revocarea certificatelor | Centre de înregistrare (RC) |
| Validați asocierea cheilor publice și identitățile deținătorilor de certificate și alte atribute | Deținătorii de certificate |
| Semnează și criptează documentele electronice | Clienții |
| Verifică autenticitatea semnăturilor digitale și a lanțurilor de certificate corespunzătoare utilizând cheia publică a unei CA de încredere | Depozitele |
Stocați și furnizați informații despre certificate și liste CAC
Crearea certificatelor
Primul lucru pe care îl vom face este să creăm certificate de server și client. Ai nevoie de programul openssl.exe (am instalat xampp, are tot ce ai nevoie - ti-l recomand si tie). Deci, în folderul /server/apache/bin găsim openssl.exe și creăm fișierele ca.config și openssl.cnf. De asemenea, creați un folder db și în el folderele certs, newcerts, fișiere text goale index.txt și serial (în interiorul acestui fișier scrieți „01” fără ghilimele.)
| Conținutul fișierului ca.config [ca] default_ca = CA_CLIENT # La semnarea certificatelor # utilizați secțiunea CA_CLIENT private_key = ./ca.key # Fișierul cheii private CA default_md = md5 # Algoritm de semnătură # politici de date |
Conținutul fișierului openssl.cnf
| # ================================================= # Fișier de configurare OpenSSL # ================================================= RANDFILE = .rnd [ca] default_ca = CA_default [CA_default] dir = . certs = $dir new_certs_dir = $dir crl_dir = $dir baza de date = $dir/db/index.txt cheie_privată = $dir/ca.key certificat = $dir/ca.crt serial = $dir/db/serial crl = $dir/crl.pem RANDFILE = $dir/db/private/.rand default_days = 365 default_crl_days = 30 default_md = sha1 conserva = nu policy = policy_anything name_opt = ca_default cert_opt = ca_default [policy_orice] countryName = opțional stateOrProvinceName = opțional localityName = opțional organizationName = opțional organizationalUnitName = opțional commonName = furnizat emailAddress = opțional [req] default_bits = 1024 default_md = sha1 default_keyfile = privkey.pem nume_distins = req_distinguished_name x509_extensions = v3_ca string_mask = nombstr [nume_distins_req] countryName = Numele țării (cod cu două litere) countryName_min = 2 countryName_max = 2 stateOrProvinceName = Numele statului sau al provinciei (nume complet) localityName = Numele localității (de exemplu, oraș) 0.organizationName = Numele organizației (de exemplu, companie) organizationalUnitName = Numele unității organizaționale (de exemplu, secțiunea) commonName = Nume comun (de exemplu, numele TĂU) commonName_max = 64 emailAddress = Adresa de e-mail emailAddress_max = 64 [usr_cert] basicConstraints = CA:FALSE # nsCaRevocationUrl = https://url-to-exposed-clr-list/crl.pem [server_ssl] basicConstraints = CA:FALSE nsCertType = server extendedKeyUsage = serverAuth, nsSGC, msSGC nsComment = „Certificat OpenSSL pentru server web SSL” [ssl_client] basicConstraints = CA:FALSE nsCertType = client keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = clientAuth nsComment = „Certificat OpenSSL pentru client SSL” [v3_req] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment [v3_ca] basicConstraints = critic, CA:true, pathlen:0 nsCertType = sslCA keyUsage = cRLSign, keyCertSign extendedKeyUsage = serverAuth, clientAuth nsComment = „Certificat CA OpenSSL” [crl_ext] basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment nsComment = „CRL generat OpenSSL” |
deschide cmd.exe (Start -> Run -> cmd -> enter), apoi rulează programul openssl.exe prin cmd și procedează direct la crearea certificatelor noastre.
1) creați o cheie de server și un certificat
req -new -x509 -days 365 -sha1 -newkey rsa:1024 -nodes -keyout server.key -out server.crt -subj ‘/O=CompanyName/OU=Unit/CN=localhost’
Introduceți aici numele companiei, divizia și numele de domeniu.
req -config openssl.cnf -new -x509 -days 3652 -sha1 -newkey rsa:1024 -keyout ca.key -out ca.crt -subj ‘/O=Organization/OU=Unit’
Introduceți aici numele companiei sau al diviziei dvs.
3) creați certificate de utilizator
- req -new -sha1 -newkey rsa:1024 -nodes -keyout server.key -out request.pem -subj ‘/O=Skif Grid/OU=PSI RAS/CN=localhost’
- ca -config openssl.cnf -policy policy_anything -extensions ssl_server -out signed.pem -infiles request.pem
- x509 -in signed.pem -out server.crt
- openssl pkcs12 -export –in signed.pem –inkey server.key -certfile ca.crt -name „Nume\Patronimic” -out user.p12
Importăm ca.crt și user.p12 rezultate în browser. Am terminat cu certificatele, acum e timpul pentru Apach.
Configurare Apache
Deschideți fișierul /server/apache/conf/extra/httpd-ssl.conf, ștergeți tot ce este acolo și copiați următoarele:
| ErrorLog D:/www/apache/logs/ssl_error.log Avertisment LogLevel Aplicație AddType/x-x509-ca-cert .crt .pem SSLPassPhraseDialog încorporat NameVirtualHost *:443 AddDefaultCharset utf-8 DocumentRoot „D:/www/htdocs” SSLEngine activat SSLCertificateFile conf/ssl/server.crt SSLVerifyClient necesită SSLProxyEngine dezactivat
|
Dacă vrem să facem autorizarea opțională (să zicem, astfel încât dacă utilizatorul nu are un certificat, atunci arătați-i o pagină frumoasă cu inscripția, să spunem, obțineți mai întâi un certificat), atunci setați SSLVerifyClient ca opțional.
Standardul PGP (Pretty Good Privacy).
Un certificat PGP conține în primul rând o cheie publică și un identificator (sau mai mulți identificatori alternativi) al proprietarului. Identificatorul proprietarului poate fi text sau grafic.
Un certificat poate fi autentificat prin mai multe semnături digitale; Mai mult, fiecare semnătură certifică conectarea cheii publice cu unul sau mai mulți dintre identificatorii de proprietar indicați în certificat (acest lucru permite implementarea conceptului de încredere cumulativă). Se presupune că abonații pot fi utilizatori obișnuiți.
În cele din urmă (cel puțin din versiunea 7.0), pentru fiecare dintre abonați, certificatul poate conține o notă că semnatarul are încredere deplină în subiectul (proprietarul) certificatului ca emitent de certificate pentru alți utilizatori (și indică, de asemenea, domeniul adrese de e-mail, la care se extinde această încredere). Acest lucru face posibilă extinderea „rețelei de încredere” a utilizatorilor dincolo de granițele cercului cunoștințelor lor personale (deși nu apropiate) și crearea IUOC corporativă cu o politică specifică pentru eliberarea de certificate de aproape orice complexitate.
Standardul PGP este utilizat în sistemul de securitate a corespondenței electronice cu același nume. Prima versiune a acestui sistem a fost dezvoltată în 1991 de F. Zimmerman (SUA). Versiunea 7.0 a fost lansată în 2000 (ca o dezvoltare de către Network Associates, Inc.).
Standardul ISO ITU-T X.509v1, 2.
X.509v1 este din punct de vedere istoric primul standard de certificat digital (a apărut în 1988). Diferența dintre versiunile 1 și 2 este nesemnificativă.
Certificatul X.509v1, 2 este un certificat de identitate obișnuit cu un format rigid.
Conține, în primul rând, cheia publică și identificatorul (unul) al proprietarului. ID-ul proprietarului este text.
Este indicată și perioada de valabilitate a certificatului (cheie publică).
Certificat de un editor.
Standardul ISO ITU-T X.509v3.
Principala diferență dintre certificatul X.509v3 și certificatul X.509v1, 2 este prezența așa-numitelor aplicații (extensii). Standardul X.509v3 (a apărut în 1997) definește mai multe standarde, de ex. definite nu numai în formă, ci și în conținut, aplicații. În plus, permite includerea așa-numitelor aplicații definite de utilizator în certificat, care sunt determinate doar de formular.
Aplicațiile personalizate sunt utilizate de IUOC în principal pentru a include informații despre autoritatea subiecților în certificat.
Unele dintre cele mai importante aplicații standard includ:
- ID-ul politicii de ediție;
- identificatori alternativi de subiect;
- ID-ul acreditărilor emitentului certificatului subiectului (utilizatorii pot folosi această aplicație atunci când autorizează acreditările emitentului);
- Adresa serverului de publicare SOS (pot exista mai multe astfel de aplicații, inclusiv, de exemplu, adrese de server de publicare delta-SOS).
Certificatele în format X.509 sunt folosite de marea majoritate a IUK-urilor moderne. De exemplu, sunt utilizate în sistemele Visa și MasterCard pe baza lor, ICD-ul VeriSign la nivel mondial (aceasta companie, în special, emite certificate pentru servere web și, de regulă, sisteme concepute pentru crearea de ICD corporative); de exemplu, de la companiile Entrust și TimeStamp), aplicarea lor este asigurată de proiectul global IUIK pentru Internet PKIX.
Ca parte a sponsorizării:
O vacanță de neuitat, excursii turistice în locuri celebre, mare azurie, nisip fierbinte, prețuri rezonabile, Antalya (vezi www.tourskidki.ru) vă așteaptă!...
OS: Linux Debian/Ubuntu.
Aplicație: OpenSSL, Nginx, Apache2.
Iată o simplă cheat sheet a procedurii de pregătire pentru achiziționarea unui certificat SSL/TLS, verificarea corectitudinii acestuia și utilizarea lui într-un serviciu web, extinsă cu câteva explicații.
Noi generăm chei private și publice.
Este foarte recomandabil să efectuați lucrări cu componentele certificatului într-un loc închis de accesul persoanelor neautorizate:
$ mkdir -p ./make-cert
În primul rând, trebuie să creați chei de criptare RSA „închise” (alias „private”) și „deschise” (alias „publice”), care vor fi folosite ulterior pentru a crea toate celelalte componente ale certificatului și pentru a confirma autenticitatea acestuia pe partea serverului web:
$ cd ./make-cert
$ openssl genrsa -des3 -out ./example.net.key 2048
Mizerie de caractere pe care o vedem în fișierul cheie text este de fapt un container al unui set ofuscat de blocuri de cifruri unice generate în conformitate cu algoritmul RSA, iar unul dintre aceste blocuri - „modulul” - este cheia „publică” a pachetul de criptare asimetric utilizat în toate componentele certificatului. Toate celelalte conținuturi sunt o cheie „privată”.
Pentru a vă familiariza cu conținutul blocurilor de containere cheie, codul acestuia poate fi extins într-o formă mai structurată:
$ openssl rsa -noout -text -in ./example.net.key
Cheia de criptare (privată) este prin definiție cel mai secret lucru din componentele unui certificat SSL - prin urmare, implicit este protejată cu o parolă. Asigurați-vă că vă amintiți parola introdusă la solicitarea utilitarului de generare, vom avea nevoie de ea.
Trebuie remarcat faptul că, în practică, atunci când un certificat SSL este folosit doar pentru a transfera un număr de site-uri pe HTTPS, majoritatea oamenilor preferă să nu se deranjeze cu un container de chei protejate prin parolă, ci să-l elibereze imediat de această protecție, creând altul în apropiere. - „fără parolă”:
$ cd ./make-cert
$ openssl rsa -in ./example.net.key -out ./example.net.key.decrypt
Creați o solicitare de emitere a unui certificat X.509 (CSR).
Subsistemul de protecție a fluxului de trafic însuși prin SSL/TLS este implementat de obicei pe cheile simetrice de sesiune generate de serverul web și browserul client în timpul negocierii inițiale a conexiunii și nu sunt necesare chei de criptare speciale preinstalate pentru aceasta (deși facilitează procedura de negociere). - Tasta DH, de exemplu). Certificatul (al standardului X.509), al cărui set de componente îl formăm treptat aici, este destinat unui fel de confirmare a autenticității unei resurse web în infrastructura Internet, unde o autoritate de certificare de încredere condiționată garantează conexiunea între cheia „publică” și descrierea resursei specificate în certificat prin semnături electronice ale conținutului acestuia.
Un container special CSR (Certificate Signing Request) este conceput pentru a transfera către autoritatea de certificare cheia noastră „publică” (nu întregul conținut al cheii „private”, ci doar blocul „modulus” al acesteia!) și informații despre resursă, autenticitatea căreia o confirmăm. Îl creăm, specificând următorul container ca sursă a cheii „publice”:
$ cd ./make-cert
$ openssl req -new -key ./example.net.key -out ./example.net.csr
În timpul procesului, va trebui să furnizați informații despre proprietarul resursei pentru care este solicitat certificatul, cum ar fi:
„Numele țării” - cod de țară din două caractere conform ISO-3166 (RU - pentru Rusia);
„Numele statului sau al provinciei” - numele statului sau al regiunii;
„Numele localității” - denumirea orașului sau localității;
„Numele organizației” - denumirea organizației;
„Numele unității organizaționale” - denumirea unității (câmp opțional);
„Nume comun” - numele de domeniu complet calificat al resursei (FQDN) pentru care se solicită certificatul;
„Adresă de e-mail” - adresa de e-mail de contact a administratorului numelui de domeniu (câmp opțional);
„O parolă de provocare” - (câmp opțional, necompletat);
„Un nume de companie opțional” - nume alternativ de companie (câmp opțional, necompletat).
Vă rugăm să rețineți că, dacă valabilitatea certificatului ar trebui să se extindă la subdomeniile resursei care se certifică, atunci FQDN-ul din câmpul „Nume comun” va trebui completat cu masca „*”. (“*.example.net” - de exemplu).
Cei curioși pot vedea ce este ascuns în codul containerului CSR:
$ openssl req -noout -text -in ./example.net.csr
Trimitem fișierul CSR „example.net.csr” autorității de certificare de la care achiziționăm certificatul.
Achiziționarea unui certificat SSL/TLS (X.509).
Nuanțele alegerii unui furnizor de certificate, procedurile de comandă și plată nu sunt discutate aici, aceasta nu este o problemă tehnică. Unul dintre punctele importante este să nu ratați alegerea între un certificat destinat unui domeniu și un „wildcard”, care acoperă toate subdomeniile de nivelul următor cu garanțiile sale.
Generarea unui certificat X.509 autosemnat (opțional).
Alternativ, pentru utilizare exclusiv în retea locala, puteți crea singur certificatul necesar, semnându-l cu cheia dvs. „privată”. centru de încredere certificare - așa-numitul „autosemnat” (autosemnat):
$ cd ./make-cert
$ openssl x509 -req -days 1095 -in ./example.net.csr -signkey ./example.net.key -out ./example.net.crt
Ca urmare a comenzii de mai sus, pe lângă componentele existente, vom primi un fișier „example.net.crt” al unui certificat de casă, a cărui autenticitate nu poate fi verificată în infrastructura de internet a autorităților de certificare, deși funcțional acesta este normal și aplicabil.
Verificarea corectitudinii certificatelor si cheilor.
Certificatul SSL/TLS primit conține cel puțin următoarele informații:
Versiunea certificatului;
Numărul de serie al certificatului;
Algoritm de semnătură;
Numele complet (unic) al proprietarului certificatului;
Cheia publică a proprietarului certificatului;
Data emiterii certificatului;
Data expirării certificatului;
Numele complet (unic) al autorității de certificare;
Semnătura digitală a editorului.
Personal, verific întotdeauna valabilitatea datelor specificate în certificat prin decodarea și vizualizarea conținutului acestuia folosind următoarea comandă:
$ cd ./make-cert
$ openssl x509 -noout -text -in ./example.net.crt
În practică, se întâmplă adesea ca clienții sau colegii incompetenți să furnizeze certificate și chei amestecate care nu au legătură între ele pentru a fi utilizate direct în serviciile web. O încercare de a le utiliza pe un server web va provoca o eroare precum „nepotrivirea valorii cheii x509”.
Cel mai simplu mod de a verifica corectitudinea combinației dintre cheia „privată”, cererea CSR și certificatul final X.509 este verificarea sumei de control a cheii „publice” (blocul „modulus”) conținută în toate aceste containere. :
$ openssl rsa -noout -modulus -in ./example.net.key | openssl md5
$ openssl req -noout -modulus -in ./example.net.csr | openssl md5
$ openssl x509 -noout -modulus -in ./example.net.crt | openssl md5
Șirul hash MD5 este scurt, iar identificarea diferențelor dintre ele nu este dificilă.
Creăm un set standard de fișiere de certificat și cheie.
De obicei, autoritățile de certificare furnizează nu numai certificatul solicitat, ci și un set suplimentar de certificate intermediare (autoritatea însăși, nodul său părinte și așa mai departe până la nodul rădăcină).
În general, în timpul procesului putem acumula mai multe fișiere, pe care le numesc în funcție de funcționalitatea lor, cam așa:
„example.net.key” - container cu chei „private” și „publice” (protejat cu parolă);
„example.net.key.decrypt” - un container protejat fără parolă, cu chei „private” și „publice”;
„example.net.csr” - cerere CSR utilizată la comandarea certificatului;
„example.net.crt” - direct certificatul nostru X.509;
"intermediate.crt" - certificat (sau lanț de astfel de asemenea) al autorității de certificare;
„root.crt” este certificatul de autoritate rădăcină de la care începe lanțul de încredere.
Certificatele intermediare ne sunt furnizate nu numai pentru familiarizare - este recomandabil să le completăm cu un container cu certificatul nostru destinat utilizării într-un serviciu web, formând acolo un lanț până la un nod de încredere binecunoscut. Acest lucru se face prin simpla adăugare a codurilor text la sfârșitul fișierului:
$ cd ./make-cert
$ cat ./example.net.crt >> ./example.net-chain.crt
$ cat ./intermediate.crt >> ./example.net-chain.crt
$ cat ./root.crt >> ./example.net-chain.crt
Vă rugăm să rețineți că certificatul nostru trebuie să fie la începutul lanțului plasat în container - de obicei, serverul web verifică cheia „privată” atașată cu cea „publică” în primul certificat care apare în timp ce citește conținutul containerului.
În Linux, există deja locuri în sistemul de fișiere pentru certificate și chei de criptare. Distribuim fișiere și le protejăm împotriva accesului neautorizat:
# mkdir -p /etc/ssl/certs
# mkdir -p /etc/ssl/private
# cp ./example.net-chain.crt /etc/ssl/certs/
# cp ./example.net.key.decrypt /etc/ssl/private/
# chown -R root:root /etc/ssl
# chmod -R o-rwx /etc/ssl
Certificat SSL pe serverul web Nginx.
În cel mai simplu caz, utilizarea unui certificat SSL în serverul web Nginx este implementată aproximativ după cum urmează:
# vi /etc/nginx/sites-enabled/example.net.conf
....
server (
asculta 443 ssl;
nume_server example.net;
....
ssl activat;
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers AES256-SHA:RC4:HIGH:!aNULL:!MD5:!kEDH;
ssl_prefer_server_ciphers activat;
ssl_session_cache shared:SSL:30m;
ssl_session_timeout 1h;
ssl_certificate /etc/ssl/certs/example.net-chain.crt;
ssl_certificate_key /etc/ssl/private/example.net.key.decrypt;
....
}
....
Certificat SSL pe serverul web Apache.
În serverul web Apache, certificatul SSL este folosit cam așa:
# vi /etc/apache2/sites-enabled/example.net.conf
....
# Descrierea mediului de lucru al unui site web accesibil prin HTTPS
ServerName example.net
....
# Setări generale recomandate pentru protocol
SSLEngine activat
SSLProtocol all -SSLv2
SSLHonorCipherComanda activat
SSLCipherSuite HIGH:MEDIUM:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!aECDH:+SHA1:+MD5:+HIGH:+MEDIUM
SSLOptions +StrictRequire
SSLCompression dezactivat
# Certificat și fișiere cheie
SSLCertificateFile /etc/ssl/certs/example.net-chain.crt
SSLCertificateKeyFile /etc/ssl/certs/example.net.key.decrypt
....
format certificat X.509
X.509 este un alt format foarte comun. Toate certificatele X.509 sunt conforme standard international ITU-T X.509; astfel (teoretic), un certificat X.509 creat pentru o aplicație poate fi utilizat în oricare alta care acceptă acest standard. În practică, însă, a apărut situația că diferite companii își creează propriile extensii pentru X.509, care nu sunt toate compatibile între ele.
Fiecare certificat necesită ca cineva să verifice relația dintre cheia publică și informațiile care identifică proprietarul cheii. Atunci când se ocupă de un certificat PGP, oricine poate acționa ca martor la informațiile conținute în acesta (cu excepția cazurilor în care această capacitate este limitată în mod deliberat de politica de securitate). Dar în cazul certificatelor X.509, martorul poate fi doar o Autoritate de Certificare sau cineva autorizat în mod special de aceasta pentru acest rol. (Rețineți că certificatele PGP acceptă pe deplin structuri de încredere ierarhice care utilizează un CA pentru a autentifica certificatele.)
Un certificat X.509 este un set de câmpuri standard care conțin informații despre un utilizator sau dispozitiv și cheia publică corespunzătoare. Standardul X.509 definește ce informații sunt incluse în certificat și cum sunt codificate (formatul de date).
Certificatul X.509 conține următoarele informații:
Versiunea X.509 - indică pe ce versiune a standardului X.509 se bazează acest certificat, care determină ce informații poate conține.
Cheia publică a proprietarului certificatului este cheia publică împreună cu identificatorul algoritmului utilizat (indicând criptosistemul căruia îi aparține cheia) și alte informații despre parametrii cheii.
Numărul de serie al certificatului - organizația care eliberează certificatul este obligată să îi atribuie un număr de serie unic (ordinal) pentru identificarea acestuia printre alte certificate emise de această organizație. Aceste informații se aplică într-un număr de cazuri; de exemplu, atunci când un certificat este revocat, numărul său de serie este introdus lista certificatelor revocate(Lista de revocare a certificatelor, CRL).
Identificatorul unic al proprietarului cheii (sau DN, nume distinctiv- nume unic) - acest nume trebuie să fie unic și unic pe întregul Internet. DN constă din mai multe subclauze și poate arăta cam așa:
CN=Bob Davis [email protected],OU=PGP Engineering,
O=PGP Corporation, C=US
(Care înseamnă Nume prietenos pentru subiect, E-mail, Unitate organizațională, Organizație și, respectiv, Țară.)
Perioada de valabilitate a certificatului - data de începere a certificatului și data de expirare a valabilității acestuia; indică momentul în care certificatul va deveni invalid.
Nume unic al emitentului - Numele unic al organizației care a semnat certificatul. De obicei, acesta este numele autorității de certificare. Utilizarea unui certificat implică încredere în organizația care l-a semnat. (În cazurile cu certificate rădăcină, organizația emitentă - aceeași CA - o semnează singură.)
Semnătura digitală a editorului - semnătură electronică, generat de cheia privată a organizației care a emis certificatul. Identificator algoritm de semnare - Indică algoritmul utilizat de CA pentru a semna certificatul.
Există o serie de diferențe fundamentale între formatele de certificat X.509 și PGP:
vă puteți crea personal propriul certificat PGP;
trebuie să solicitați și să primiți un certificat X.509 de la o autoritate de certificare; Certificatele X.509 conțin un singur nume al proprietarului certificatului;
Certificatele X.509 conțin o singură semnătură digitală care confirmă autenticitatea certificatului.
Pentru a obține un certificat X.509, trebuie să solicitați unei CA să vi-l elibereze. Furnizați sistemului cheia dumneavoastră publică, dovedind astfel că aveți cheia privată corespunzătoare, precum și unele informații care vă identifică. Apoi semnați electronic aceste informații și trimiteți întregul pachet - cererea de certificat - către Autoritatea de Certificare. CA trece printr-un proces de verificare a autenticității informațiilor furnizate și, dacă totul se potrivește, creează un certificat, îl semnează și vi-l returnează.
