Tls conexiune. Ce este TLS

Conform cerințelor Legislația rusă Este recunoscută doar utilizarea conexiunilor TLS stabilite conform algoritmilor criptografici ruși GOST 28147-89, GOST R 34.10-94, GOST R 34.11-94 și GOST R 34.10-2001. Prin urmare, dacă trebuie să utilizați site-uri care utilizează criptarea conform algoritmilor GOST, trebuie să instalați programul CryptoPro CSP.

ÎN sisteme de operare Windows folosește programul CryptoPro CSP - un set de utilități criptografice pentru generarea semnăturilor electronice și lucrul cu certificate

Pentru a instala CryptoPro CSP, utilizați materialele de pe site-ul oficial:

• Distribuție CSP CryptoPro
• Un pachet de instrucțiuni pentru instalarea și utilizarea CryptoPro CSP

După instalarea CryptoPro CSP, browserul verifică prezența și funcționalitatea acestui program.

Site-uri care solicită criptarea GOST TLS

Dacă un site solicită criptarea GOST TLS, browserul verifică dacă programul CryptoPro CSP este instalat. Dacă programul este instalat, controlul este transferat acestuia.

Exemple de site-uri care solicită criptare: www.gosuslugi.ru, site-uri de pe domeniul .gov.ru, .kamgov.ru, .nalog.ru.

Dacă site-ul nu este pe listă, se solicită confirmare suplimentară. Dacă aveți încredere în site și conexiunea trebuie făcută folosind criptarea GOST TLS, faceți clic pe butonul Continuare.

Nota. Site-urile pot necesita instalarea de certificate. Instrucțiunile de instalare a certificatelor se află de obicei pe site-urile care le solicită.

Activarea și dezactivarea suportului pentru browser CryptoPro CSP

În mod implicit, browserul acceptă CryptoPro CSP. Vă recomandăm să verificați acest lucru.

Protocolul SSL TLS

Utilizatorii organizațiilor bugetare, și nu numai bugetare, ale căror activități sunt direct legate de finanțe, în interacțiune cu organizațiile financiare, de exemplu, Ministerul Finanțelor, Trezoreria etc., își desfășoară toate operațiunile exclusiv folosind protocolul securizat SSL. Practic, în munca lor ei folosesc browserul Internet Explorer. În unele cazuri, Mozilla Firefox.

Știri despre computer, recenzii, rezolvarea problemelor computerului, jocuri pe calculator, drivere și dispozitive și altele programe de calculator." title="programe, drivere, probleme cu computerul, jocuri" target="_blank">!}

Eroare SSL

Atenția principală la efectuarea acestor operațiuni și a muncii în general este acordată sistemului de securitate: certificate, semnături electronice. Pentru operare este utilizată versiunea actuală a software-ului CryptoPro. Referitor la probleme cu protocoalele SSL și TLS, Dacă Eroare SSL a apărut, cel mai probabil nu există suport pentru acest protocol.

Eroare TLS

Eroare TLSîn multe cazuri, poate indica și lipsa suportului pentru protocol. Dar... să vedem ce se poate face în acest caz.

Suport protocol SSL și TLS

Deci, când folosind Microsoft Internet Explorer, pentru a vizita un site web prin SSL, se afișează bara de titlu Asigură-te că protocoale sslși tls activat. În primul rând, este necesar activați suportul Protocolul TLS 1.0 în Internet Explorer.

Știri despre computer, recenzii, soluții la probleme cu computerul, jocuri pe calculator, drivere și dispozitive și alte programe de calculator." title="programe, drivere, probleme cu computerul, jocuri)" target="_blank">Компьютерная помощь, драйверы, программы, игры!}

Dacă vizitați un site web care rulează Internet Information Services 4.0 sau o versiune ulterioară, Configurare Internet Suportul TLS 1.0 al Explorer vă ajută să vă securizați conexiunea. Desigur, cu condiția ca serverul web la distanță pe care încercați să îl utilizați să accepte acest protocol.

Pentru a face acest lucru în meniu Serviciu selectați echipa Opțiuni Internet.

Pe fila În plus in sectiune Siguranţă, asigurați-vă că sunt bifate următoarele casete de selectare:

Utilizați SSL 2.0
Utilizați SSL 3.0
Utilizați TLS 1.0

Faceți clic pe butonul Aplicați si apoi Bine . Reporniți browserul .

După activarea TLS 1.0, încercați să vizitați din nou site-ul web.

Politica de securitate a sistemului

Dacă tot apar erori cu SSL și TLS Dacă tot nu puteți utiliza SSL, serverul web la distanță probabil nu acceptă TLS 1.0. În acest caz, este necesar dezactivați politica de sistem, care necesită algoritmi conformi cu FIPS.

Știri despre computer, recenzii, soluții la probleme cu computerul, jocuri pe calculator, drivere și dispozitive și alte programe de calculator." title="programe, drivere, probleme cu computerul, jocuri)" target="_blank">Компьютерная помощь, драйверы, программы, игры!}

Pentru a face acest lucru, în Panouri de control selecta Administrare, apoi faceți dublu clic Politica locală de securitate.

ÎN parametri locali securitate, extindeți nodul Politicile locale, apoi faceți clic pe butonul Setări de securitate.

Conform politicii din partea dreaptă a ferestrei, faceți dublu clic Criptografia sistemului: utilizați algoritmi conformi cu FIPS pentru criptare, hashing și semnare, apoi faceți clic pe butonul Dezactivat .

Atenţie! Schimbarea intră în vigoare după politica locala securitatea este reaplicată. Adică porniți-lŞi reporniți browserul .

CryptoPro TLS SSL

Actualizați CryptoPro

În continuare, una dintre opțiunile pentru rezolvarea problemei este actualizarea CryptoPro, precum și configurarea resursei. În acest caz, se lucrează cu plăți electronice. Prin urmare, mergem la Centrul de Certificare pentru setări automate resursă. Selectăm platformele electronice de tranzacționare ca resursă.

După pornirea configurării automate la locul de muncă, tot ce rămâne este așteptați finalizarea procedurii, după care reîncărcați browserul. Dacă trebuie să introduceți sau să selectați o adresă de resursă, selectați-o pe cea de care aveți nevoie. De asemenea, poate fi necesar să reporniți computerul când configurarea este finalizată.

Știri despre computer, recenzii, soluții la probleme cu computerul, jocuri pe calculator, drivere și dispozitive și alte programe de calculator." title="programe, drivere, probleme cu computerul, jocuri)" target="_blank">Компьютерная помощь, драйверы, программы, игры!}

Configurarea SSL TLS

Configurarea rețelei

O altă variantă ar putea fi dezactivarea NetBIOS prin TCP/IP- situat în proprietățile de legătură.

înregistrare DLL

Lansa linie de comandă ca administrator și introduceți comanda regsvr32 cpcng. Pentru un sistem de operare pe 64 de biți, trebuie să utilizați același regsvr32 care este în syswow64.

TLS și SSL au fost menționate din ce în ce mai recent, utilizarea certificatelor digitale a devenit mai relevantă și au apărut chiar și companii care sunt gata să ofere certificate digitale gratuite tuturor pentru a se asigura că traficul dintre site-urile vizitate și browserul clientului este criptat. Desigur, acest lucru este necesar pentru securitate, astfel încât nimeni din rețea să nu poată primi datele care sunt transmise de la client la server și înapoi. Cum funcționează toate acestea și cum să le folosești? Pentru a înțelege acest lucru, trebuie, probabil, să începem cu teorie și apoi să o arătăm în practică. Deci, SSL și TLS.

Ce este SSL și ce este TLS?

SSL - Secure Socket Layer, un strat de prize securizate. TLS - Transport Layer Security, securitate la nivel de transport. SSL este un sistem anterior, TLS a venit mai târziu și se bazează pe specificația SSL 3.0 dezvoltată de Netscape Communications. Cu toate acestea, aceste protocoale au o singură sarcină - să asigure transferul securizat de date între două computere de pe Internet. Acest transfer este folosit pentru diverse site-uri web, pentru e-mail, pentru mesagerie și multe altele. În principiu, puteți transmite orice informație în acest fel mai multe despre cele de mai jos.

Transmiterea securizată este asigurată prin autentificarea și criptarea informațiilor transmise. În esență, aceste protocoale, TLS și SSL, funcționează la fel, nu există diferențe fundamentale. Se poate spune că TLS este succesorul SSL-ului, deși pot fi folosite simultan, chiar și pe același server. Un astfel de suport este necesar pentru a asigura funcționarea atât cu clienții noi (dispozitive și browsere), cât și cu cei vechi care nu acceptă TLS. Secvența de apariție a acestor protocoale arată astfel:

SSL 1.0 - niciodată publicat
SSL 2.0 - februarie 1995
SSL 3.0 - 1996
TLS 1.0 - ianuarie 1999
TLS 1.1 - aprilie 2006
TLS 1.2 - august 2008

Cum funcționează SSL și TLS

Principiul de funcționare a SSL și TLS, așa cum am spus, este același. Un canal criptat este stabilit peste protocolul TCP/IP, în cadrul căruia datele sunt transferate prin protocolul de aplicație - HTTP, FTP și așa mai departe. Iată cum poate fi reprezentat grafic:

Protocolul de aplicație este „împachetat” în TLS/SSL, care, la rândul său, este împachetat în TCP/IP. În esență, datele protocolului de aplicație sunt transmise prin TCP/IP, dar sunt criptate. Și numai mașina care a stabilit conexiunea poate decripta datele transmise. Pentru toți ceilalți care primesc pachetele transmise, aceste informații vor fi lipsite de sens dacă nu le pot decripta.

Conexiunea se stabilește în mai multe etape:

1) Clientul stabilește o conexiune la server și solicită o conexiune securizată. Acest lucru poate fi realizat fie prin stabilirea unei conexiuni la un port care este proiectat nativ pentru a funcționa cu SSL/TLS, de exemplu, 443, sau cerere suplimentară clientul stabilește o conexiune securizată după stabilirea uneia obișnuite.

2) Când stabilește o conexiune, clientul oferă o listă de algoritmi de criptare pe care îi „știe”. Serverul verifică lista primită cu lista de algoritmi pe care serverul însuși îi „știe” și selectează cei mai mulți algoritm de încredere, iar apoi îi spune clientului ce algoritm să folosească

3) Serverul trimite clientului certificatul său digital, semnat de autoritatea de certificare, și cheia publică a serverului.

4) Clientul poate contacta serverul autorității de certificare de încredere care a semnat certificatul de server și poate verifica dacă certificatul de server este valid. Dar poate că nu. Sistemul de operare este de obicei deja instalat certificate rădăcină autoritățile de certificare cu care sunt verificate semnăturile certificatelor de server, de exemplu, browserele.

5) O cheie de sesiune este generată pentru o conexiune sigură. Acest lucru se face după cum urmează:
— Clientul generează o secvență digitală aleatorie
— Clientul îl criptează cu cheia publică a serverului și trimite rezultatul către server
— Serverul decriptează secvența primită folosind cheia privată
Având în vedere că algoritmul de criptare este asimetric, doar serverul poate decripta secvența. Când utilizați a criptare simetrică sunt folosite două chei - privată și publică. Un mesaj trimis public este criptat, iar un mesaj trimis privat este decriptat. Este imposibil să decriptați un mesaj dacă aveți o cheie publică.

6) Aceasta stabilește o conexiune criptată. Datele transmise prin aceasta sunt criptate și decriptate până la terminarea conexiunii.

Certificat rădăcină

Chiar mai sus am menționat certificatul rădăcină. Acesta este un certificat de centru de autorizare, a cărui semnătură confirmă că certificatul care este semnat este cel care aparține serviciului corespunzător. Certificatul în sine conține de obicei un număr de câmpuri de informații care conțin informații despre numele serverului căruia i-a fost emis certificatul și perioada de valabilitate a acestui certificat. Dacă certificatul a expirat, acesta este invalidat.

Solicitare de semnătură (CSR, Cerere de semnare a certificatului)

Pentru a obține un certificat de server semnat, trebuie să generați o cerere de semnătură (CSR, Certificate Sign Request) și să trimiteți această solicitare la centrul de autorizare, care va returna un certificat semnat, instalat direct pe server, vom vedea mai jos cum se face acest lucru; în practică. Mai întâi, este generată o cheie de criptare, apoi, pe baza acestei chei, este generată o cerere de semnătură, un fișier CSR.

Certificat de client

Un certificat de client poate fi generat atât pentru utilizarea dispozitivului, cât și a utilizatorului. De obicei, astfel de certificate sunt utilizate în verificarea în două sensuri, în care clientul verifică dacă serverul este cine spune că este, iar serverul face același lucru în schimb. Această interacțiune se numește autentificare în două sensuri sau autentificare reciprocă. Autentificarea bidirecțională vă permite să creșteți nivelul de securitate în comparație cu autentificarea unidirecțională și poate servi și ca înlocuitor pentru autentificarea folosind un nume de utilizator și o parolă.

Lanț de acțiuni pentru generarea certificatelor

Să aruncăm o privire practică asupra modului în care acțiunile asociate cu generarea certificatelor apar de la bun început și în practică.

Primul lucru de făcut este să generați un certificat rădăcină. Certificatul rădăcină este autosemnat. Și apoi alte certificate vor fi semnate cu acest certificat.

$ openssl genrsa -out root.key 2048 Se generează cheia privată RSA, modul lung de 2048 biți .......+++ ....... ............... .........+++ e este 65537 (0x10001) $ openssl req -new -key root.key -out root.csr Vi se va cere să introduceți informații care vor fi încorporate în cererea dvs. de certificat . Ceea ce urmează să introduceți este ceea ce se numește un nume distinctiv sau un DN. Există destul de multe câmpuri, dar puteți lăsa unele necompletate. Pentru unele câmpuri va exista o valoare implicită, Dacă introduceți „.”, câmpul va fi lăsat necompletat. ----- Numele țării (cod cu 2 litere): RU Numele statului sau provinciei (numele complet) : N/A Numele localității (de exemplu, orașul) : Saint-Petersburg Numele organizației (de exemplu, compania) : Compania mea Numele unității organizaționale (de exemplu, secțiune) : Nume comun al serviciului IT (de exemplu, FQDN al serverului sau numele DVS.) : Adresa de e-mail a certificatului rădăcină al companiei mele : [email protected] Vă rugăm să intrați următoarele atribute „extra” care trebuie trimise împreună cu solicitarea certificatului O parolă de provocare: Un nume opțional de companie: Compania mea $ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem Semnătura ok subiect=/ C=RU/ST=N/A/L=Saint-Petersburg/O=Compania mea/OU=Serviciul IT/CN=Certificatul rădăcină al companiei mele/ [email protected] Obținerea cheii private

Așa că am generat mai întâi cheie privată, apoi o cerere de semnătură, iar apoi au semnat propria cerere cu cheia lor și au primit propriul certificat digital, eliberat pentru 10 ani. Nu trebuie să introduceți o parolă de provocare atunci când generați un certificat.

Cheia privată TREBUIE să fie stocată într-un loc sigur având-o, puteți semna orice certificat în numele dvs. Și certificatul rădăcină rezultat poate fi folosit pentru a identifica că certificatul, de exemplu, al serverului a fost semnat de noi și nu de altcineva. Acestea sunt acțiunile pe care centrele de autorizare le efectuează atunci când își generează propriile certificate. După crearea certificatului rădăcină, puteți începe generarea certificatului de server.

Vizualizați informații despre certificat

Conținutul certificatului poate fi vizualizat după cum urmează:

$ openssl x509 -noout -issuer -enddate -in root.pem emitent= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/ [email protected] notAfter=22 ianuarie 11:49:41 2025 GMT

Vedem cine a eliberat acest certificat și când expiră data de expirare a acestuia.

Certificat de server

Pentru a semna un certificat pentru server trebuie să facem următoarele:

1) Generați o cheie
2) Generați o cerere de semnătură
3) Trimiteți dosarul CSR la centrul de autorizare sau semnați-l singur

Certificatul de server poate include lanțul de certificate care au semnat certificatul de server, dar poate fi stocat și într-un fișier separat. În principiu, totul arată aproximativ la fel ca atunci când se generează un certificat rădăcină

$ openssl genrsa -out server.key 2048 Se generează cheia privată RSA, modul lung de 2048 biți ......................... ....... ................................................. . +++ .........................+++ e este 65537 (0x10001) $ openssl req -new -key server.key - out server .csr Vi se va cere să introduceți informații care vor fi încorporate în cererea dumneavoastră de certificat. Ceea ce urmează să introduceți este ceea ce se numește un nume distinctiv sau un DN. Există destul de multe câmpuri, dar puteți lăsa unele necompletate. Pentru unele câmpuri va exista o valoare implicită, Dacă introduceți „.”, câmpul va fi lăsat necompletat. ----- Numele țării (cod cu 2 litere): RU Numele statului sau provinciei (numele complet) : N/A Numele localității (de exemplu, orașul) : Saint-Petersburg Numele organizației (de exemplu, compania) : Compania mea Numele unității organizaționale (de exemplu, secțiune) : Nume comun al serviciului IT (de exemplu, FQDN al serverului sau numele DVS.) :www.compania mea.com Adresă de e-mail : [email protected] Vă rugăm să introduceți următoarele atribute „extra” care vor fi trimise împreună cu solicitarea dvs. de certificat. O parolă de provocare: Un nume de companie opțional: $ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out server. pem -days 365 Semnătura ok subiect=/C=RU/ST=N/A/L=Saint-Petersburg/O=Compania mea/OU=Serviciul IT/CN=www.mycompany.com/ [email protected] Obținerea cheii private CA $ openssl x509 -noout -issuer -subject -enddate -in server.pem emiter= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN =Certificatul rădăcină al companiei mele/ [email protected] subiect= /C=RU/ST=N/A/L=Saint-Petersburg/O=Compania mea/OU=Serviciul IT/CN=www.compania mea.com/ [email protected] notAfter=25 ianuarie 12:22:32 2016 GMT

În acest fel certificatul de server este semnat și vom ști care organizație a emis acest certificat. După semnare, certificatul terminat poate fi utilizat în scopul propus, de exemplu, instalat pe un server web.

Instalarea unui certificat SSL/TLS pe ​​un server cu nginx

Pentru a instala un certificat SSL/TLS pe ​​serverul web nginx, trebuie să urmați câțiva pași simpli:

1) Copiați fișierele .key și .pem pe server. Pe diferite sisteme de operare, certificatele și cheile pot fi stocate în directoare diferite. În Debian, de exemplu, acesta este directorul /etc/ssl/certs pentru certificate și /etc/ssl/private pentru chei. Pe CentOS, acestea sunt /etc/pki/tls/certs și /etc/pki/tls/private

2) Înregistrează-te setările necesare V fișier de configurare pentru gazda. Cam așa ar trebui să arate (doar un exemplu):

Server (ascultă 443; server_name www.mycompany.com; root html; index index.html index.htm; ssl activat; ssl_certificate server.pem; ssl_certificate_key server.key; ssl_session_timeout 5m; # SSLv3 nu este recomandat aici!!! de exemplu numai ssl_protocols SSLv3 TLSv1 ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP ssl_prefer_server_ciphers);

3) Reporniți nginx

4) Accesați portul server 443 cu un browser - https://www.mycompany.com și verificați funcționalitatea acestuia.

Instalarea unui certificat SSL/TLS pe ​​un server care rulează Apache

Instalarea unui certificat SSL/TLS pe ​​Apache arată similar.

1) Copiați fișierele cheie și certificate pe server în directoarele corespunzătoare

2) Activați modulul ssl pentru Apache cu comanda „a2enmod ssl” dacă nu este deja activat

3) Creați o gazdă virtuală care va asculta portul 443. Configurația va arăta cam așa:

ServerAdmin [email protected] DocumentRoot /var/www Opțiuni FollowSymLinks AllowOverride Nici unul Opțiuni Indexuri FollowSymLinks MultiViews AllowOverride Niciunul Comanda permite, interzice permite din toate ScriptAlias ​​​​/cgi-bin/ /usr/lib/cgi-bin/ AllowOverride Niciunul Opțiuni +ExecCGI -MultiViews +SymLinksIfOwnerMatch Ordinea permite, refuza Permite din toate ErrorLog $(APACHE_LOG_DIR)/error.log LogLevel warn CustomLog $(APACHE_LOG_DIR)/ssl_access.log combinat SSLEngine pe SSLCertificateFile /etc/ssl/certs/server.pem SSLCertificateKeyFile /etc/ssl/private/Această directivă/server. fișier , care conține o listă # cu toate certificatele care au semnat certificatul de server #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt SSLOptions +StdEnvVars SSLOptions +StdEnvVars BrowserMatch „MSIE” \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 BrowserMatch „MSIE ” ssl-unclean-shutdown

În același timp, mai este ceva de făcut. Găsiți în fișierul httpd.conf, sau apache2.conf, sau ports.conf, în funcție de sistem, următoarea secțiune a config:

Ascultă 443

Dacă nu există o astfel de condiție, trebuie adăugată la config. Și încă un lucru: trebuie să adăugați linia

NameVirtualHost *:443

Această linie poate fi în fișierul httpd.conf, apache2.conf sau ports.conf

4) Reporniți serverul web Apache

Crearea unui certificat de client

Un certificat de client este creat în aproape același mod ca un certificat de server.

$ openssl genrsa -out client.key 2048 Se generează cheia privată RSA, modul lung de 2048 biți ........................+++ ..... .............................................++ e este 65537 (0x10001) $ openssl req -new -key client.key -out client.csr Vi se va cere să introduceți informații care vor fi încorporate în cererea dumneavoastră de certificat. Ceea ce urmează să introduceți este ceea ce se numește un nume distinctiv sau un DN. Există destul de multe câmpuri, dar puteți lăsa unele necompletate. Pentru unele câmpuri va exista o valoare implicită, Dacă introduceți „.”, câmpul va fi lăsat necompletat. ----- Numele țării (cod cu 2 litere) :RU Numele statului sau provinciei (numele complet) :Sankt-Petersburg Numele localității (de exemplu, orașul) :^C mnorin@mnorin-work:~/Temp/certs/CA$ openssl req -new -key client.key -out client.csr Vi se va cere să introduceți informații care vor fi încorporate în cererea dumneavoastră de certificat. Ceea ce urmează să introduceți este ceea ce se numește un nume distinctiv sau un DN. Există destul de multe câmpuri, dar puteți lăsa unele necompletate. Pentru unele câmpuri va exista o valoare implicită, Dacă introduceți „.”, câmpul va fi lăsat necompletat. ----- Numele țării (cod cu 2 litere): RU Numele statului sau provinciei (numele complet) : N/A Numele localității (de exemplu, orașul) : Saint-Petrersburg Numele organizației (de exemplu, compania) : Compania mea Numele unității organizaționale (de exemplu, secțiunea) :Nume comun de inginerie (de exemplu, FQDN-ul serverului sau numele DVS.) :Ivan Ivanov Adresa de e-mail : [email protected] Vă rugăm să introduceți următoarele atribute „extra” care vor fi trimise împreună cu cererea dumneavoastră de certificat. O parolă de provocare: Un nume de companie opțional: $ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client. pem -zile 365 Semnătura ok subiect=/C=RU/ST=N/A/L=Saint-Petrersburg/O=Compania mea/OU=Inginerie/CN=Ivan Ivanov/ [email protected] Obținerea cheii private CA $ openssl x509 -noout -issuer -subject -enddate -in client.pem emiter= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN =Certificatul rădăcină al companiei mele/ [email protected] subiect= /C=RU/ST=N/A/L=Saint-Petrersburg/O=Compania mea/OU=Inginerie/CN=Ivan Ivanov/ [email protected] notAfter=25 ianuarie 13:17:15 2016 GMT

Dacă aveți nevoie de un certificat de client în format PKCS12, creați-l:

$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12 Introduceți parola de export: Verificare - Introduceți parola de export:

Acum puteți utiliza certificatul de client pentru a lucra cu serverul nostru.

Configurarea nginx pentru a utiliza certificate client

Cel mai adesea, așa cum am spus deja, se folosește autentificarea unidirecțională, de obicei se verifică doar certificatul serverului. Să vedem cum să forțezi serverul web nginx să verifice certificatul client. Este necesar să adăugați opțiuni la secțiunea de server pentru a lucra cu certificate de client:

# Certificat(e) rădăcină(e) cu care clientul este semnat ssl_client_certificate /etc/nginx/certs/clientroot.pem; # Opțiuni posibile: on | oprit | optional | optional_no_ca ssl_verify_client optional; # Profunzimea de verificare a lanțului de certificate cu care este semnat clientul ssl_verify_depth 2;

După aceasta, trebuie să reporniți setările sau întregul server și puteți verifica funcționarea.

Configurarea Apache pentru a utiliza certificate client

Apache poate fi configurat și prin adăugare opțiuni suplimentare la secțiunea gazdă virtuală:

# Director care conține certificate rădăcină pentru verificarea clientului SSLCARevocationPath /etc/apache2/ssl.crl/ # sau fișier care conține certificate SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Opțiune de verificare a clientului. Opțiuni posibile: # none, optional, require și optional_no_ca SSLVerifyClient require # View depth of the signature chain. Implicit 1 SSLVerifyDepth 2

După cum puteți vedea, opțiunile sunt aproximativ aceleași ca pentru nginx, deoarece procesul de verificare este organizat uniform.

Ascultarea informațiilor despre certificat folosind openssl

Pentru a testa modul în care serverul interacționează cu certificatele client, puteți verifica dacă conexiunea este stabilită folosind TLS/SSL.

Pe partea de server, începem să ascultăm pe port folosind openssl:

Openssl s_server -accept 443 -cert server.pem -key server.key -state

Pe partea de client, accesăm serverul, de exemplu, cu culr:

Curl -k https://127.0.0.1:443

În consola de pe partea serverului, puteți observa procesul de schimb de informații între server și client.

De asemenea, puteți utiliza opțiunile -verify [verification depth] și -Verify [verification depth]. Opțiunea pentru cazuri mici solicită clientului un certificat, dar nu este necesar să furnizeze unul. Cu majuscule - Dacă nu este furnizat un certificat, va apărea o eroare. Să începem să ascultăm din partea serverului astfel:

Openssl s_server -accept 443 -cert server.pem -key server.key -state -Verify 3

Din partea serverului, eroarea arată astfel:

140203927217808:error:140890C7:Rutine SSL:SSL3_GET_CLIENT_CERTIFICATE:peer nu a returnat un certificat:s3_srvr.c:3287:

Din partea clientului astfel:

Curl: (35) eroare:14094410:Rutine SSL:SSL3_READ_BYTES:sslv3 eșec strângere de mână alertă

Să adăugăm un certificat și un nume de domeniu pe partea client (puteți introduce numele gazdei pentru adresa 127.0.0.1 în fișierul /etc/hosts pentru a verifica):

Curl https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key client.key

Acum conexiunea va avea succes și puteți instala certificatul de server pe serverul web, puteți oferi clientului certificatul de client și puteți lucra cu ei.

Siguranţă

Când utilizați SSL/TLS, una dintre metodele principale este metoda MITM (Man In The Middle). Această metodă se bazează pe utilizarea unui certificat de server și a unei chei pe un nod care va asculta traficul și va decripta informațiile schimbate între server și client. Pentru a organiza ascultarea, puteți folosi, de exemplu, programul sslsniff. Prin urmare, este de obicei recomandabil să stocați certificatul rădăcină și cheia pe o mașină care nu este conectată la rețea pentru semnare, să aduceți cereri de semnătură pe o unitate flash, să semnați și să o luați de asemenea; Și, desigur, faceți copii de rezervă.

În termeni generali, așa sunt utilizate certificatele digitale și protocoalele TLS și SSL. Daca ai intrebari/completi, scrie in comentarii.

Post navigare

: 29 de comentarii

1. cl-service.com

   Clientul generează însuși CSR-ul atunci când comandă un certificat, unde să salveze cheie privată clientul decide si sa emita un certificat, nu avem nevoie de cheie privata si clientul nu ne-o da in niciun fel. Desigur, dacă acest lucru se întâmplă pe unul virtual obișnuit, atunci administratori cu acces root Există acces la server și la cheile care sunt stocate acolo.

2. binevoitor.

   Tema sânilor nu este acoperită, deoarece tehnologia PKI descrisă nu are nimic de-a face cu titlul subiectului. Cel puțin din motive întemeiate, am furnizat link-uri către rfc.
   P.S. Era o glumă despre un câine și un purice.

3. binevoitor.

   Nu am vrut să te jignesc în niciun fel. Căutam informații despre diferența dintre SSl și TLS în practică și linkul tău a fost primul pe Google. Am fost intrigat de titlul subiectului. Totul e misto, tine-o tot asa!

4. DrAibolit

   Vă mulțumim pentru explicațiile dvs. perspicace despre certificarea digitală. Sunt nou in asta =)
   Sper că puteți clarifica următoarea întrebare.
   Deoarece subiectul fraudei este foarte dezvoltat în industria internetului, aș dori să învăț cum să determin „păduchii” site-urilor pe care le vizitez pe cont propriu (în special acolo unde există numerar și plăți, investiții etc.) și pe baza asta determină gradul de încredere (trebuie să mă înregistrez adesea, să plec Informații personale, efectuați cumpărături, tranzacții, investiții). Dacă am înțeles bine, deținerea acestei certificări vă permite să faceți o astfel de evaluare. Ei bine, pe de altă parte, obținerea acestuia nu este o problemă și este chiar gratuită.
   Cum sau cu ce program puteți determina dacă un site web are un certificat digital? și de preferință categoria acesteia, care este atribuită atunci când o autoritate specială emite SSL DV (certificatul se eliberează cu verificarea doar a domeniului), SSL OV (cu verificarea organizației), EV (cu verificare extinsă a persoanei juridice). Site-urile frauduloase cel mai probabil nu vor folosi cea mai recentă opțiune de certificare.
   M-aș bucura dacă mi-ați spune mai multe modalități de a determina fiabilitatea site-urilor))

   1. mnorin Autorul postului

      Nu am întâlnit încă niciun program specific pentru aceste scopuri, dar pot da câteva sfaturi în acest sens.
      Puteți utiliza, de exemplu, Chromium sau Google Chrome. Să luăm, de exemplu, site-ul https://www.thawte.com/ - o companie care se ocupă de fapt cu certificate digitale.
      ÎN bara de adrese se va scrie numele companiei și un lacăt verde. Aceasta înseamnă că organizația este verificată, acesta este cel puțin SSL OV.
      Dacă faceți clic pe lacăt, iar în fereastra drop-down „Detalii”, apoi „Vizualizare certificat”, puteți vedea informații despre certificat. Pentru Thawte, certificatul este semnat de următorul certificat: „thawte Extended Validation SHA256 SSL CA”, iar certificatul pentru click.alfabank.ru este semnat tot de Thawte, dar cu alt certificat. Acesta este „thawte EV SSL CA - G3”, adică au trecut și validarea extinsă.
      Aşa ceva.

5. Ruslan

   Secțiunea „Cum funcționează SSL și TLS”, „Clientul generează o secvență digitală aleatorie.”

   Eram sigur că clientul generează chei private de sesiune și, în consecință, publice (pe care, evident, le-ați numit „secvență digitală”). Cheia publică este transmisă serverului, iar serverul criptează pachetele către client cu cheia publică de sesiune a clientului.

   Vă rog să clarificați.

6. Începător

   Articolul este foarte util! Există chiar exemple practice=) Numai că nu am înțeles un lucru - care este diferența dintre un certificat rădăcină și unul de server? sau este acelasi lucru?

7. Vitalia

   Buna ziua.
   Hosterul a oferit un serviciu - SSL pentru servere virtuale. Noi am profitat de ea. S-a dovedit că pentru al treilea nivel, adică. Certificatul http://www.site.ru este invalid, numai pentru site.ru. Mai mult decât atât, vizitatorii sunt aruncați cu încăpățânare protocol https
   Dar pentru cei care au ajuns pe site, site-ul a început să arate strâmb, o parte din meniu a dispărut, iar unele dintre imaginile din rezultatele căutării au încetat să fie afișate de unele componente.

Descriere

TLS permite aplicațiilor client-server să comunice printr-o rețea într-un mod care împiedică interceptarea și accesul neautorizat.

Deoarece majoritatea protocoalelor de comunicare pot fi utilizate cu sau fără TLS (sau SSL), atunci când stabiliți o conexiune, trebuie să spuneți în mod explicit serverului dacă clientul dorește să instaleze TLS. Acest lucru poate fi realizat fie prin utilizarea unui număr de port uniform pe care conexiunea este întotdeauna stabilită folosind TLS (cum ar fi portul 443 pentru HTTPS), fie prin utilizarea unui port arbitrar și a unei comenzi speciale către server din partea clientului pentru a comuta conexiunea la TLS utilizând protocolul cu mecanisme speciale (cum ar fi STARTTLS pentru protocoalele de e-mail). Odată ce clientul și serverul au convenit să utilizeze TLS, trebuie să stabilească o conexiune sigură. Acest lucru se face folosind o procedură de strângere de mână. Straturi de prize securizate). În timpul acestui proces, clientul și serverul fac un acord cu privire la diverși parametri necesare pentru a stabili o conexiune sigură.

Există și variante de atac bazate direct pe implementare software protocol, și nu pe algoritmul său.

Procedura de strângere de mână TLS în detaliu

Conform protocolului TLS, aplicațiile fac schimb de înregistrări care încapsulează (stochează în sine) informațiile care trebuie transferate. Fiecare dintre intrările poate fi comprimată, completată, criptată sau identificată printr-un MAC (Cod de autentificare a mesajelor) în funcție de starea curentă a conexiunii (starea protocolului). Fiecare intrare TLS conține următoarele câmpuri: tipul de conținut (definește tipul de conținut al intrării), un câmp care indică lungimea pachetului și un câmp care indică versiunea protocolului TLS.

Când conexiunea este stabilită pentru prima dată, interacțiunea are loc utilizând protocolul de strângere de mână TLS, tip de conținut care este 22.

Strângere de mână simplă în TLS

1. Faza de negociere:
   • Clientul trimite un mesaj ClientSalut
   • Serverul răspunde cu un mesaj ServerSalut
   • Serverul trimite un mesaj Certificat
   • Serverul trimite un mesaj ServerHelloDone
   • Clientul răspunde cu un mesaj ClientKeyExchange, care conține cheia publică a PreMasterSecret (Acest PreMasterSecret este criptat folosind cheia publică a certificatului serverului.) sau nimic (din nou depinde de algoritmul de criptare);
   • PreMasterSecret
2. Clientul trimite un mesaj ChangeCipherSpec
   • Clientul trimite un mesaj Terminat
3. Serverul trimite ChangeCipherSpec

Strângere de mână cu autentificarea clientului

Acest exemplu demonstrează autentificarea completă a clientului (în plus față de autentificarea serverului ca în exemplul anterior) prin schimbul de certificate între server și client.

1. Faza de negociere:
   • Clientul trimite un mesaj ClientSalut, indicând cea mai recentă versiune a protocolului TLS acceptat, un număr aleatoriu și o listă de metode de criptare și compresie acceptate potrivite pentru lucrul cu TLS;
   • Serverul răspunde cu un mesaj ServerSalut, conținând: versiunea protocolului selectată de server, un număr aleator trimis de client, un algoritm de criptare și compresie adecvat din lista furnizată de client;
   • Serverul trimite un mesaj Certificat, care conține certificatul digital al serverului (în funcție de algoritmul de criptare, acest pas poate fi omis);
   • Serverul trimite un mesaj Cerere de certificat, care conține o cerere de certificat de client pentru autentificare reciprocă;
   • [Lipsește punctul de obținere și verificare a certificatului de client] ;
   • Serverul trimite un mesaj ServerHelloDone, identificând sfârșitul strângerii de mână;
   • Clientul răspunde cu un mesaj ClientKeyExchange, care conține cheia publică PreMasterSecret sau nimic (din nou în funcție de algoritmul de criptare);
   • Client și server folosind cheia PreMasterSecretși numere generate aleatoriu, se calculează o cheie secretă partajată. Toate celelalte informații despre cheie vor fi derivate din cheia secretă partajată (și valori aleatorii generate de client și server);
2. Clientul trimite un mesaj ChangeCipherSpec, care indică faptul că toate informațiile ulterioare vor fi criptate folosind algoritmul stabilit în timpul procesului de strângere de mână, folosind o cheie secretă partajată. Acestea sunt mesaje la nivel de înregistrare și, prin urmare, sunt de tip 20 mai degrabă decât 22;
   • Clientul trimite un mesaj Terminat, care conține hash-ul și MAC-ul generat din mesajele anterioare de handshake;
   • Serverul încearcă să decripteze mesajul Terminat al clientului și să verifice hash-ul și MAC. Dacă procesul de decriptare sau de verificare eșuează, strângerea de mână este considerată eșuată și conexiunea trebuie încheiată.
3. Serverul trimite ChangeCipherSpecși mesajul criptat Finished, iar la rândul său clientul efectuează și decriptarea și verificarea.

Din acest moment se consideră finalizată confirmarea comunicării, se stabilește protocolul. Toate conținuturile de pachete ulterioare vin cu tipul 23 și toate datele vor fi criptate.

Reluarea unei conexiuni TLS

Algoritmi criptare asimetrică folosite pentru a genera cheia de sesiune sunt de obicei costisitoare din punct de vedere al puterii de calcul. Pentru a evita repetarea lor atunci când conexiunea este reluată, TLS creează etichetă specială la confirmarea conexiunii, folosit pentru a relua conexiunea. În acest caz, în timpul unei confirmări normale de comunicare, clientul adaugă la mesaj ClientSalut ID-ul sesiunii anterioare ID sesiune. Clientul leagă ID ID sesiune cu adresa IP a serverului și portul TCP astfel încât la conectarea la server să puteți utiliza toți parametrii conexiunii anterioare. Serverul se potrivește cu ID-ul sesiunii anterioare ID sesiune cu parametrii de conectare, cum ar fi algoritmul de criptare utilizat și secretul principal. Ambele părți trebuie să aibă același secret principal, altfel conexiunea nu va fi stabilită. Acest lucru previne utilizarea ID sesiune criptoanalist pentru a obține acces neautorizat. Secvențe de numere aleatorii în mesaje ClientSalutŞi ServerSalut vă permit să garantați că cheia de sesiune generată va fi diferită de cheia de sesiune în timpul conexiunii anterioare. RFC numește acest tip de strângere de mână abreviat.

1. Faza de negociere:
   • Clientul trimite un mesaj ClientSalut, indicând cea mai recentă versiune a protocolului TLS acceptat, un număr aleatoriu și o listă de metode de criptare și compresie acceptate potrivite pentru lucrul cu TLS; La mesaj este adăugat și identificatorul de conexiune anterior. ID sesiune.
   • Serverul răspunde cu un mesaj ServerSalut, conținând: versiunea protocolului selectată de server, un număr aleator trimis de client, un algoritm de criptare și compresie adecvat din lista furnizată de client. Dacă serverul recunoaște ID-ul sesiunii ID sesiune ServerSalut același identificator ID sesiune. Acesta este un semnal pentru client că poate fi folosită reluarea sesiunii anterioare. Dacă serverul nu recunoaște ID-ul sesiunii ID sesiune, apoi adaugă la mesaj ServerSalut un alt sens în schimb ID sesiune. Pentru client, aceasta înseamnă că conexiunea reînnoită nu poate fi utilizată. Astfel, serverul și clientul trebuie să aibă același master secret și numere aleatorii pentru a genera o cheie de sesiune;
2. Clientul trimite un mesaj ChangeCipherSpec, care indică faptul că toate informațiile ulterioare vor fi criptate cu cheia secretă partajată stabilită în timpul procesului de strângere de mână. Acestea sunt mesaje la nivel de înregistrare și, prin urmare, sunt de tip 20 mai degrabă decât 22;
3. Clientul trimite un mesaj ChangeCipherSpec, care indică faptul că toate informațiile ulterioare vor fi criptate folosind algoritmul stabilit în timpul procesului de strângere de mână, folosind o cheie secretă partajată. Acestea sunt mesaje la nivel de înregistrare și, prin urmare, sunt de tip 20 mai degrabă decât 22;
   • Clientul trimite un mesaj Terminat, care conține hash-ul și MAC-ul generat din mesajele anterioare de handshake;
   • Serverul încearcă să decripteze mesajul Terminat al clientului și să verifice hash-ul și MAC. Dacă procesul de decriptare sau verificare eșuează, strângerea de mână este considerată eșuată și conexiunea trebuie să fie încheiată;
4. Serverul trimite ChangeCipherSpecși mesajul criptat Finished, iar la rândul său clientul efectuează și decriptarea și verificarea.

Din acest moment se consideră finalizată confirmarea comunicării, se stabilește protocolul. Toate conținuturile de pachete ulterioare vin cu tipul 23 și toate datele vor fi criptate.

Pe lângă beneficiile de performanță, algoritmul de reînnoire a conexiunii poate fi utilizat pentru a implementa conectarea unică, deoarece este garantat că sesiunea inițială și orice sesiune reluată sunt inițiate de același client (RFC 5077). Aceasta are în special important pentru a implementa FTP prin protocolul TLS/SSL, care altfel ar fi vulnerabil la un atac man-in-the-middle, în care un atacator ar putea intercepta conținutul datelor atunci când se stabilește o reconectare.

Algoritmi utilizați în TLS

In aceasta versiunea curentă Următorii algoritmi sunt disponibili în protocol:

• Pentru a schimba cheile și a verifica autenticitatea acestora, se folosesc combinații de algoritmi: RSA ( cifru asimetric), Diffie-Hellman ( schimb sigur chei), DSA (algoritm de semnătură digitală) și algoritmi de tehnologie Fortezza;
• Pentru criptare simetrică: RC2, RC4, IDEA, DES, Triple DES sau AES;

Algoritmii pot fi completați în funcție de versiunea protocolului.

Comparație cu analogii

O aplicație a unei conexiuni TLS este conectarea gazdelor într-o rețea privată virtuală. Pe lângă TLS, se pot folosi și un set de protocoale IPSec și o conexiune SSH. Fiecare dintre aceste abordări de implementare a unei rețele private virtuale are propriile avantaje și dezavantaje. .

1. TLS/SSL
   • Avantaje:
     • Invizibil la protocoalele de nivel superior;
     • Utilizare populară în conexiuni la Internet și aplicații de comerț electronic;
     • Lipsa conexiunii permanente între server și client;
     • TCP/IP, cum ar fi e-mail, instrumente de programare etc.
   • Defecte:
     • UDP și ICMP;
     • Necesitatea de a monitoriza starea conexiunii;
     • Disponibilitate cerințe suplimentare La software despre suportul TLS.
2. IPsec
   • Avantaje:
     • Securitatea și fiabilitatea protecției datelor a protocolului au fost testate și dovedite de când protocolul a fost adoptat ca standard de internet;
     • Lucrul în stratul superior al protocolului de rețea și criptarea datelor deasupra stratului de protocol de rețea.
   • Defecte:
     • Complexitatea implementării;
     • Cerințe suplimentare pentru echipamentele de rețea (routere etc.);
     • Există multe diverse implementări nu interacționează întotdeauna corect unul cu celălalt.
3. SSH
   • Avantaje:
     • Vă permite să creați un tunel pentru aplicațiile care utilizează TCP/IP, precum e-mail, instrumente de programare etc.;
     • Stratul de securitate este invizibil pentru utilizator.
   • Defecte:
     • Greu de utilizat în rețele cu un număr mare gateway-uri precum routere sau firewall-uri;
     • Imposibilitatea de a utiliza cu protocoale UDP și ICMP.

Vezi de asemenea

Legături

1. T. Dierks, E. Rescorla Protocolul Transport Layer Security (TLS), versiunea 1.2 (august 2008). Arhivat din original pe 9 februarie 2012.
2. Protocolul SSL: versiunea 3.0 versiunea finală a Netscape SSL 3.0 schiță (18 noiembrie 1996)
3. „SSL/TLS în detaliu”. Microsoft TechNet. Actualizat la 31 iulie 2003.
4. Dan Goodin . Registrul(19 septembrie 2011). Arhivat
5. Eric RescorlaÎnțelegerea atacului de renegociere TLS. Ghicituri educate(5 noiembrie 2009). Arhivat din original pe 9 februarie 2012. Consultat la 7 decembrie 2011.
6. McMillan, Robert. Security Pro spune că noul atac SSL poate lovi multe site-uri, Lumea PC(20 noiembrie 2009). Preluat la 7 decembrie 2011.
7. SSL_CTX_set_options SECURE_RENEGOTIATION . OpenSSL Docs(25 februarie 2010). Arhivat din original pe 9 februarie 2012. Consultat la 7 decembrie 2010.
8. GnuTLS 2.10.0 a fost lansat. Note de lansare GnuTLS(25 iunie 2010). Arhivat din original pe 9 februarie 2012. Consultat la 7 decembrie 2011.
9. Note de lansare NSS 3.12.6. Note de lansare a NSS(3 martie 2010). Preluat la 24 iulie 2011.
10. Diverse Vulnerabilitatea IE SSL. Ghicituri educate(10 august 2002).

Sesiunea SMTP dintre server și client nu este criptată implicit. Acest lucru face posibilă interceptarea și primirea pachetelor informații confidențiale transmis în text clar (cu excepția cazului în care sunt utilizate alte metode de criptare).

Utilizarea protocolului TLS ne va ajuta să corectăm această situație, ceea ce va asigura:

1. Confidențialitate (Interacțiunea dintre client și server are loc în format criptat
sesiune);

2. Integritate (este imposibil să infiltrați o sesiune neobservată; corupția datelor va fi detectată imediat);

3. Încrederea în autentificare (Clientul și serverul pot face schimb de certificate certificate de o Autoritate de Certificare (CA).

Cum funcționează TLS

Protocolul TLS criptează doar conexiunea dintre două gazde. O sesiune care utilizează acest protocol se desfășoară după cum urmează:

1. Clientul stabilește o conexiune cu serverul.

2. Gazdele încep comunicarea utilizând protocolul SMTP.

3. Serverul, folosind cuvântul cheie STARTTLS, sugerează utilizarea TLS în cadrul interacțiunilor SMTP.

4. Dacă clientul poate folosi TLS, acesta răspunde serverului cu cuvântul cheie STARTTLS.

5. Certificatul public al serverului este semnat cu cheia privată și trimis clientului.

6. Clientul verifică autenticitatea certificatului de server prin verificarea semnăturii autorității de certificare cu semnătura publică a autorității de certificare pe care o are în depozitul rădăcină.

7. Clientul verifică certificatul serverului cu șirul pe care îl conține Nume comun nume de domeniu server.

8. Clientul și serverul activează modul de criptare a datelor.

9. Gazdele fac schimb de date.

10. Sesiunea se încheie.

Să începem să creăm certificate pentru serverul de e-mail server.mydomain.ru , pe care Postfix acționează ca un MTA, iar Dovecot îndeplinește rolul MDA.

Crearea unui nou certificat este ușoară - doar rulați scriptul și rulați câteva comenzi.

Să generăm 2 fișiere - cheia secretă a serverului și o cerere de semnare a certificatului cu comanda:

# openssl req -nodes -newkey rsa:2048 -keyout server.key -out server.csr

unde server este numele serverului (în acest caz poate fi orice)

Completați câmpurile (apăsând „Enter” se lasă valoarea implicită):

Numele țării (cod din 2 litere): RU
Numele statului sau provinciei (numele complet): Orenburg
Numele localității (de exemplu, orașul): Orsk
Numele organizației (de exemplu, companie): Compania mea
Numele unității organizaționale (de exemplu, secțiunea): IT
Nume comun (de exemplu, numele DVS.): server.mydomain.ru
Adresa de e-mail: postmaster @mydomain.ru
O parolă de provocare:
Un nume de companie opțional:

Este foarte important să indicați în teren Nume comun nume de gazdă complet calificat (FQDN) corespunzător înregistrărilor DNS de tipuri MX și A

Folosim ocazia de a obține certificate COMODO gratuite cu o perioadă de valabilitate de 90 de zile pe serviciul FreeSSL.su. Aceste certificate sunt ușor de recunoscut de către toate browserele și clienții de e-mail.

Pe pagina principală, completați toate câmpurile obligatorii, în coloana „Selectați software-ul de utilizat”, selectați „Altele”. În câmp CSR introduceți conținutul fișierului generat anterior server.csr .

După trimiterea cererii și confirmarea acesteia, primim o arhivă certs.zip , care conține următoarele fișiere:

1. AddTrustExternalCARoot.crt;
2. server_mydomain_ru.crt;
3. ComodoUTNSGCCA.crt;
4. EssentialSSLCA_2.crt;
5. UTNAddTrustSGCCA.crt

Fișierul server_mydomain_ru.crt este certificatul necesar. Ce ar trebui să facem cu fișierele rămase? Să facem asta - combină conținutul lor într-un singur fișier ca.txt (certificat CA de încredere C.A. ) în următoarea ordine:

1. EssentialSSLCA_2.crt
2. ComodoUTNSGCCA.crt
3. UTNAddTrustSGCCA.crt
4. AddTrustExternalCARoot.crt

Fișier primit ca.txt Vom folosi în continuare:

Să ne configuram serverul de e-mail. Pentru a face acest lucru, facem modificări în configurații porumbar Şi postfix .

Pentru porumbel:

dovecot.conf:

protocoale = pop3 imap imaps pop3s

protocol pop3 (
asculta = *:110
ssl_listen = *:995
...........
}

protocol imap (
asculta = *:143
ssl_listen = *:993
...........
}

disable_plaintext_auth = nu # Nu interzicem autentificarea în mod deschis
ssl = da # Activați suportul ssl
ssl_cert_file = /etc/ssl/certs/dovecot.pem # fișier de certificat,
# setați permisiunile pentru el: root:root 0444
ssl_key_file = /etc/ssl/private/dovecot.pem # cheie server,
# este recomandat să setați permisiunile: root:root 0400

ssl_verify_client_cert = yes # verificați valabilitatea certificatelor client
ssl_parameters_regenerate = 1 # parametri regenerați la fiecare oră
# (valoarea „0” dezactivează regenerarea)
ssl_cipher_list = ALL:!LOW:!SSLv2 # SSL cipher
verbose_ssl = da # înregistrează erori ssl în jurnal

A obține ssl_cert_file trebuie să îmbinați conținutul fișierelor server_mydomain_ru.crt Şi ca.txt , redenumiți fișierul rezultat în dovecot.pem. În rol ssl_key_file apare fișierul cheie secretă a serverului redenumit server.cheie , generat anterior.

Pentru postfix:

principal.cf

Smtp_use_tls = da # utilizați TLS dacă serverul de la distanță raportează suport TLS
smtpd_use_tls = da # informează clienții despre suportul TLS
smtpd_tls_auth_only = nu # folosește autentificarea SMTP pentru mai mult decât doar conexiuni TLS
smtp_tls_note_starttls_offer = da # nume server de jurnal,
# emiterea unui mesaj STARTTLS pentru care suportul TLS nu este activat

smtpd_tls_CAfile = /etc/ssl/ca.txt # certificat de încredere
smtpd_tls_key_file = /etc/ssl/smtpd.key # cheie privată a serverului
smtpd_tls_cert_file = /etc/ssl/smtpd.crt # certificat de server

smtpd_tls_loglevel = 2 # verbozitatea mesajelor de activitate TLS
smtpd_tls_received_header = yes # solicită antete de mesaje cu informații
# despre versiunea protocolului și algoritmul de criptare
smtpd_tls_session_cache_timeout = 3600s # timp în care datele sunt stocate în cache
# sesiuni TLS sunt considerate actuale
tls_random_source = dev:/dev/urandom # numele dispozitivului generator de numere pseudoaleatoare (PRNG)

Pentru ca Postfix să accepte conexiuni TLS pe ​​un port special (465/SMTPS, nu 25/SMTP), în fișier maestru.cf trebuie să decomentezi rândurile:

maestru.cf

Smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=da
-o smtpd_sasl_auth_enable=da
-o smtpd_client_restrictions=permit_sasl_authenticated,reject

Reporniți postfix și porumbel și verificați jurnalele.

Nu uitați să deschideți porturile necesareîn firewall: 993 (imaps), 995 (pop3s), 465 (smtps)

Serverul nostru de e-mail este gata de lucru TLS !

La clienți de e-mail ar putea folosi corect noile capabilități de server, trebuie să setați setările de protocol FQDN server, așa cum a fost specificat în timpul cheii și solicitării și selectați tipul de securitate a conexiunii SSL/TLS și relevante porturi.

La sfârșitul perioadei de valabilitate de 90 de zile a certificatelor, trebuie să urmați aceeași procedură folosind același dosar pentru a solicita server.csr , așa că trebuie să păstrați o copie a acesteia într-un loc sigur. Întregul proces de actualizare nu va dura mai mult de 10 minute!