Verificarea certificatelor de bază Verificarea certificatelor de bază se efectuează asupra tuturor certificatelor într-o secvență și constă într-o serie de verificări. Verificări folosind fiecare dintre cele patru grupuri de variabile de stare sunt efectuate pentru a determina dacă

Verificarea valabilității certificatului Această verificare reușește dacă data și ora curente la momentul validării se află în perioada de valabilitate.

Verificarea stării certificatului Această verificare reușește dacă emitentul nu a revocat certificatul. Listele CAC sunt mijloacele principale de verificare a stării unui certificat, dar pot fi utilizate alte mijloace alternative.

Verificarea semnăturii certificatului Semnătura certificatului poate fi verificată pe baza primului grup de variabile de stat utilizând cheia publică a emitentului certificatului, utilizând parametrii corecți și utilizând algoritmul de semnătură digitală.

Pregătirea următorului certificat Mai întâi, se efectuează o simplă validare a certificatului CA. Variabilele de stare sunt apoi actualizate pentru a reflecta valorile câmpurilor suplimentare ale certificatului. Există mai multe completări care se găsesc

Finalizarea procesării certificatelor Când procesarea certificatului de entitate finală este finalizată, valorile de ieșire sunt setate pe baza valorilor variabilelor de stare. semnatura digitala. În câmpul de informații

3.3.1. Format RSS Puteți citi știrile site-ului în diferite moduri. Cel mai simplu mod este să vizitezi site-ul din când în când și să vezi mesaje noi. Puteți pune un program care se conectează la un canal de știri și primește el însuși titluri sau adnotări de știri, conform

Formatul certificatului X.509 X.509 este un alt format foarte comun. Toate certificatele X.509 sunt conforme cu standardul internațional ITU-T X.509; astfel (teoretic) un certificat X.509 creat pentru o aplicație poate fi folosit în oricare alta,

Revocarea certificatului Un certificat poate fi utilizat doar atâta timp cât este valabil. Este periculos să te bazezi pe un certificat pentru a fi sigur și de încredere pentru totdeauna. În majoritatea organizațiilor și în toate PKI-urile, un certificat are o durată de viață limitată. Aceasta restrânge perioada în care

Notificare de revocare a certificatului Odată ce un certificat a fost revocat, este extrem de important să anunțați toți potențialii corespondenți că acesta nu mai este valabil. Cel mai simplu mod de a notifica într-un mediu PGP este să plasați un certificat revocat

Formatul ELF Formatul ELF are mai multe tipuri de fișiere pe care le-am numit diferit până acum, cum ar fi un fișier executabil sau un fișier obiect. Cu toate acestea, standardul ELF distinge între următoarele tipuri:1. Un fișier relocabil care conține instrucțiuni și date care pot fi

Există două tipuri de sisteme criptografice: sisteme de chei secrete (simetrice) și sisteme de chei publice (asimetrice). Aproximativ, dar de înțeles, sistemele simetrice folosesc aceeași cheie pentru operațiunile de criptare și decriptare, în timp ce sistemele asimetrice folosesc altele diferite.

În sistemele simetrice, există o problemă de distribuire a cheii secrete într-un mod sigur: ambele părți care fac schimb de informații trebuie să cunoască această cheie, dar nimeni altcineva nu ar trebui să aibă această cheie.

Sistemele asimetrice sunt aranjate astfel încât să existe două numere în ele:

• „cheia publică a utilizatorului A”, care este utilizată pentru a cripta un mesaj destinat utilizatorului A,
• „cheia privată a utilizatorului A”, care este folosită de acest utilizator pentru a decripta mesajele trimise către acesta.

Ultima împrejurare este foarte importantă: utilizatorul își poate publica cheia publică în locuri publice, astfel încât oricine să o poată folosi și cripta un mesaj pentru A. Prin urmare, problema distribuirii cheii secrete dispare.

Utilizatorul trebuie să-și păstreze cheia privată secretă față de persoane din afară: doriți ca numai utilizatorul să poată decripta mesajele care i-au fost trimise. Mai mult, cerința ca cheia privată să fie păstrată secretă este foarte importantă în legătură cu conceptul de semnătură digitală, despre care se discută puțin mai departe. Privind în perspectivă, să spunem că secretul cheii private este de asemenea important, deoarece numai utilizatorul ar trebui să-și poată crea propria semnătură digitală, care depinde de valoarea cheii private.

Destul de des, cheia privată este stocată pe media în formă criptată și decriptată doar pe durata unor acțiuni care necesită cunoașterea cheii private. Acest lucru crește ușor securitatea stocării cheii private, dar creează un inconvenient dacă cheia privată este nevoie de un fel de serviciu automat: (cel puțin) de fiecare dată când pornește acest serviciu, trebuie să introduceți o parolă pentru a decripta cheia.

Există, de asemenea, carduri inteligente care pot efectua operațiuni criptografice în interiorul lor, dând doar rezultatul rezultatului, dar fără a dezvălui conținutul cheii private. Furtul unei chei private de pe un smart card implementat corect ar trebui să fie foarte dificil. Cheia privată, chiar și stocată pe un smart card, poate fi protejată prin parolă. Dacă nu există o parolă, atunci oricine are un smart card în mână poate efectua acțiuni care necesită cunoașterea cheii private: valoarea cheii private în sine va rămâne secretă, dar va fi posibilă efectuarea oricăror acțiuni intenționate cu aceasta. .

Semnatura digitala

Sistemele cu cheie publică au o altă caracteristică plăcută: utilizatorul poate crea o semnătură digitală, care, atunci când este pusă document digital, poate servi drept garanție că utilizatorul, și nu altcineva, a semnat efectiv acest document.

Schema este simplă din punct de vedere conceptual: utilizatorul A, folosind cheia sa privată, efectuează o operațiune asupra datelor pe care dorește să le semneze și transmite rezultatul împreună cu datele originale oricărui alt obiect. Și chiar acest obiect, folosind doar cheia publică a utilizatorului A, poate verifica cu ușurință dacă semnătura digitală este corectă.

Subliniem încă o dată că condiția de accesibilitate a acestei chei private numai pentru proprietarul ei joacă un rol foarte important: dacă este îndeplinită, atunci utilizatorul nu poate refuza semnătura sa digitală. Aceasta se numește non-repudiere.

Una dintre utilizările unei semnături digitale este autentificarea obiectelor. Autentificarea este procesul de stabilire a „identității” unui obiect. Este clar că dacă un obiect poate semna digital, atunci această semnătură poate fi verificată, iar obiectul este asociat cu cheia sa publică. Ultimul ingredient care lipsește din această schemă de autentificare este punctul în care cheia publică și obiectul în sine sunt legate: trebuie să știm exact cine deține această cheie publică.

Autoritatea de Certificare

Problema conectării unei chei publice și a unui obiect poate fi rezolvată în moduri diferite. Una dintre cele mai simple abordări este de a face o listă de chei publice și „nume” de obiecte care se potrivesc. Numele poate fi orice identificator, cum ar fi numele de domeniu al unei mașini, Numele complet, numele de familie și patronimul unei persoane etc.; problema unicității numelor, care trebuie să apară în mod necesar, este o dificultate separată, care este de obicei rezolvată prin mijloace administrative, cum ar fi un sistem ierarhic de spațiu de nume și un fel de sistem de rezolvare a conflictelor de nume în cadrul aceluiași subspațiu de nume. Această problemă nu va fi discutată în continuare aici.

Dar abordarea listei de potriviri are o scalare foarte slabă, deoarece aceleași liste trebuie sincronizate peste tot în lume (sau mai degrabă, în partea lumii în care sunt utilizate aceste liste).

Prin urmare, au fost introduse conceptele de certificat X.509 și de autoritate de certificare. Un certificat X.509 (denumit în continuare certificat) este un conglomerat al cheii publice a utilizatorului, informații despre utilizator, un nume de certificat numit Distungiushed Name (DN) și o semnătură digitală a unei autorități de certificare care leagă toate aceste date împreună. Adică, devine posibilă asocierea cheii publice și a DN-ului utilizatorului, care poate servi ca ingredient dorit în procesul de autentificare dacă numele distinctiv al certificatului său este folosit ca identificator de utilizator. De altfel, un certificat are o dată de expirare, care limitează perioada de valabilitate a meciului creat de CA.

Desigur, problema este pur și simplu mutată în alt loc - în loc să menținem o listă mare de potriviri, acum trebuie să menținem o listă semnificativ mai mică de chei publice ale autorităților de certificare. În acest caz, cheia autorității de certificare este suficient de de încredere: autoritatea de certificare confirmă asocierea a mii de nume de utilizator cu cheile publice corespunzătoare.

De ce este necesară autentificarea? Criptarea singură nu este suficientă?

Ei bine, în primul rând, autentificarea este valoroasă în sine: sistemele informatice trebuie să-și autentifice utilizatorii pentru a decide apoi dacă să le autorizeze accesul la diverse resurse.

Dar dacă luați cheia publică a unui utilizator și doriți să îi trimiteți un mesaj criptat, atunci probabil că veți dori să vă asigurați că criptați mesajul cu cheia publică corectă, mai ales dacă primiți acea cheie de la public surse. La urma urmei, un atacator își poate plasa cheia publică, dar, în același timp, poate indica faptul că cheia aparține destinatarului tău. Și dacă nu autentificați cheia publică, atunci atacatorul, după ce a interceptat mesajul dvs. criptat, îl va putea decripta fără probleme.

Adică, introducerea unei autorități de certificare ne permite să autentificăm obiectul care deține acest certificat. Desigur, înainte de asta, trebuie să avem încredere în cheia publică a autorității de certificare. Aceasta implică două lucruri:

1. încredere într-o autoritate de certificare în general, adică încredere în reputația acesteia,
2. încredere că cheia publică pe care o obțineți este într-adevăr cheia publică a acestei autorități de certificare.

• sunați la centrul de certificare și verificați conținutul cheii publice prin telefon,
• veniți la centrul de certificare însuși și luați cheia publică pe un mediu,
• aveți încredere în acele chei publice ale autorităților de certificare care sunt deja prezente într-un pachet software
• și multe alte moduri care sunt și mai incomode decât cele deja menționate;))

Certificate de proxy

Grozav: acum avem CA de încredere, cheile lor publice, certificatele de utilizator și cheile lor private. Putem cripta mesajele și putem crea semnături digitale care sunt greu de respins.

Ce altceva? În sistemele cu mai multe componente, ceea ce se numește Single Sign-On este foarte convenabil - capacitatea de a se autentifica manual o singură dată, iar toate celelalte operațiuni de autentificare vor fi efectuate automat. Acest lucru este valabil de obicei în sistemele care vă autentifică inițial, iar apoi sistemul începe să efectueze acțiuni în numele dvs., de exemplu, să primească date, să ruleze sarcini, să le publice rezultatele etc. Aceasta se numește delegare.

Delegarea pe baza certificatelor proxy funcționează după cum urmează: după autentificarea reciprocă a utilizatorului și a serviciului care va funcționa ulterior în numele utilizatorului, serviciul creează o nouă pereche de chei și trimite cheia publică utilizatorului pentru semnare. Utilizatorul semnează această cheie publică în același mod ca o CA, dar folosește cheia privată a utilizatorului. Certificatul rezultat se numește certificat proxy.

Serviciul, care acționează în numele utilizatorului, se poate autentifica apoi folosind cheia privată (nou generată) și un certificat semnat de utilizator. Procesul de autentificare merge cam așa.

1. Semnătura generată de serviciu este verificată. Aceasta folosește cheia publică care a fost trimisă împreună cu semnătura.
2. Cheia publică cu care a fost verificată semnătura este autentificată. În primul rând, este verificată semnătura de pe certificatul proxy, care a fost creat folosind cheia privată a utilizatorului. Acest lucru se face folosind cheia publică a utilizatorului.
3. În același mod, cheia publică a utilizatorului însuși este autentificată, dar datele despre autoritatea de certificare sunt deja folosite aici.

Folosind același mecanism, serviciul căruia i-a fost emis inițial certificatul proxy poate semna un alt certificat proxy, delegând autoritatea utilizatorului utilizatorului de-a lungul lanțului unui alt serviciu. Acesta este modul în care este implementată Single Sign-On.

• Ghid de stil X.509, scris de Peter Gutmann. Sunt o mulțime de detalii tehnice, dar pentru unii merită citite.

Formatul și structura certificatului cheie de semnare

O descriere detaliată a structurii certificatului, inclusiv o listă a restricțiilor privind utilizarea UPC și procedura de utilizare a câmpurilor unui certificat ES calificat emis de CA FC (denumită în continuare Descrierea UPC) este aprobată de către CA FC sub forma unui document separat care face parte integrantă din prezentul Regulament.

Certificat cheie de validare semnatura electronicaîn formă electronică este un document electronic care are o structură corespunzătoare standardului ITU-T X.509 versiunea 3 a Uniunii Internaționale de Telecomunicații și recomandărilor IETF (Internet Engineering Task Force) RFC 3280 și 5280 și prezentat în codificare Base64.

Structura certificatelor cheie de semnătură produse de CA este determinată de următorul tabel:

Numele comun sau CN este utilizat în general în certificatele SSL. CN este folosit pentru a defini numele serverului care va fi folosit pentru conexiunea SSL securizată. În general, acest certificat SSL este folosit pentru a securiza conexiunea între un server HTTP/S și un browser client precum Chrome, Explorer, Firefox.

Numele comun este folosit pentru a specifica identitatea gazdei sau a serverului. Când un client încearcă să se conecteze la un server la distanță, cum ar fi serverul HTTP, va primi mai întâi certificatul SSL al acestui server. Apoi comparați numele gazdă sau numele domeniului pe care dorește să se conecteze cu numele comun furnizat în certificatul SSL. Dacă sunt aceleași, va folosi certificatul SSL pentru a cripta conexiunea.

Nume comun reprezentat tehnic ca câmp commonName în specificația certificatului X.509. Specificația X.509 este utilizată în certificatele SSL, care este aceeași.

Putem formula numele comenzii ca mai jos.

Nume comun = Nume domeniu + Nume gazdă

Putem folosi următoarele nume de domeniu și gazdă ca nume comun.

site www.site *.site

Nume de domeniu complet calificat (FQDN)

Nume de domeniu complet calificat sau FQDN este utilizat cu numele de comandă interschimbabil. Numele complet calificat este folosit pentru a defini numele gazdei într-un mod strict. Mai multe detalii despre FQDN-ul pot fi găsite în următorul tutorial.

Numele Organizatiei

Numele organizației poate fi interpretat greșit cu numele comun. Numele organizației este numele organizației de care aparține infrastructura IT. Numele organizației nu trebuie folosit pentru numele comun, ceea ce va crea probleme de securitate.

OS: Linux Debian/Ubuntu.
Aplicație: OpenSSL, Nginx, Apache2.

Iată cea mai simplă cheat sheet a procedurii de pregătire pentru achiziția 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 de dorit să efectuați lucrări cu componente certificate într-un loc închis de la accesul exterior:

$ mkdir -p ./make-cert

$ cd ./make-cert
$ openssl genrsa -des3 -out ./example.net.key 2048

Amestecul de caractere pe care îl vedem într-un fișier cheie text este de fapt un container al unui set ofuscat de blocuri generate în conformitate cu algoritmul RSA al cifrurilor unice, 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ă”.

$ openssl rsa -noout -text -in ./example.net.key

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 încurce cu un container de chei protejate prin parolă, ci îl eliberează imediat de această protecție, creând altul. alături - „fără parolă”:

$ cd ./make-cert
$ openssl rsa -in ./example.net.key -out ./example.net.key.decrypt

Subsistemul însuși pentru protejarea fluxului de trafic prin SSL / TLS este implementat de obicei pe chei simetrice de sesiune generate de serverul web și browserul client în timpul negocierii inițiale a conexiunii, iar unele chei speciale de criptare prestabilite nu sunt necesare pentru aceasta (deși acestea facilitează procedura de negociere - DH -key, de exemplu). Certificatul (al standardului X.509), al cărui set de componente îl formăm treptat aici, este destinat unui fel de autentificare a unei resurse web în infrastructura Internet, unde o autoritate de certificare de încredere condiționată garantează conectarea cheia „publică” specificată în certificat și descrierea resursei prin semnarea electronică a conținutului acesteia.

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ă, a cărei autenticitate confirmăm, un container special CSR ( Cererea de semnare a certificatului) este destinată. Îl creăm, specificând un container din acestea ca sursă a cheii „publice”:

$ cd ./make-cert
$ openssl req -new -key ./example.net.key -out ./example.net.csr

„Numele țării” - cod de țară din două caractere conform ISO-3166 (RU - pentru Rusia);
„Numele statului sau al provinciei” - numele regiunii sau regiunii;
„Numele localității” - numele 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” - un nume alternativ de companie (câmp opțional, necompletat).

Curioșii pot vedea ce se ascunde în codul containerului CSR:

$ openssl req -noout -text -in ./example.net.csr

Achiziția unui certificat SSL/TLS (X.509).

Nuanțele alegerii unui furnizor de certificate, procedurile de comandă și plată nu sunt luate în considerare aici, aceasta nu este o problemă tehnică. Unul dintre punctele importante este să nu ratați alegerea între un certificat destinat unui singur domeniu și un „wildcard” care acoperă toate subdomeniile de nivelul următor cu garanțiile sale.

Generarea unui certificat X.509 autosemnat (opțional).

Ca alternativă, pentru a fi utilizat exclusiv într-o rețea locală, puteți crea singur certificatul necesar, semnându-l cu cheia dvs. „privată” în loc de 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

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.

$ cd ./make-cert
$ openssl x509 -noout -text -in ./example.net.crt

Cea mai simplă modalitate de a verifica corectitudinea cheii „private”, 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

Formăm un set tipic 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 acest proces 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” - container protejat fără parolă cu chei „private” și „publice”;
„example.net.csr” - cererea CSR utilizată la comandarea certificatului;
„example.net.crt” - direct certificatul nostru X.509;
"intermediate.crt" - certificat (sau un lanț al acestuia) al autorității de certificare;
"root.crt" - certificat centrul rădăcinii de la care începe lanţul de încredere.

$ 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

În Linux, certificatele și cheile de criptare au deja locuri în sistemul de fișiere. Distribuim fișiere și le protejăm de accesul străinilor:

# 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

Î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;
....
}
....

În serverul web „Apache”, certificatul SSL este utilizat astfel:

# vi /etc/apache2/sites-enabled/example.net.conf

....
# Descrierea mediului de lucru al site-ului web accesibil prin HTTPS

ServerName example.net
....

# Setări de protocol generice recomandate
Motorul SSL pornit
SSLProtocol all -SSLv2
SSLHonorCipherComanda activat
SSLCipherSuite HIGH:MEDIUM:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!aECDH:+SHA1:+MD5:+HIGH:+MEDIUM
SSLOptions +StrictRequire
Compresia SSL dezactivată

# Certificat și fișiere cheie
SSLCertificateFile /etc/ssl/certs/example.net-chain.crt
SSLCertificateKeyFile /etc/ssl/certs/example.net.key.decrypt

....