Tls-klienten kan ikke se certifikatet. TLS og SSL: Minimum viden påkrævet

Software Kontinent TLS VPN– et system til at give sikker fjernadgang til webapplikationer ved hjælp af GOST-krypteringsalgoritmer. Continent TLS VPN giver kryptografisk beskyttelse af HTTP-trafik på sessionsniveau. Oplysninger krypteres ved hjælp af GOST 28147–89-algoritmen.

Identifikation og autentificering af fjernbrugere

Identifikation og autentificering af brugere udføres ved hjælp af offentlige nøglecertifikater af x.509v3-standarden (GOST R 31.11–94, 34.10–2001). Continent TLS VPN kontrollerer nøglecertifikater i forhold til (CRL'er). Certifikater udstedes af en ekstern certificeringsmyndighed.

Hvis godkendelsesprocedurerne er gennemført, omdirigeres brugerens anmodning via HTTP til et sikkert netværk til den relevante webserver. I dette tilfælde tilføjes specielle identifikatorer (klient-id og IP-id) til hver brugers HTTP-session.

Kryptografisk beskyttelse af overførte oplysninger

Continent TLS VPN giver kryptografisk beskyttelse af HTTP-trafik på sessionsniveau. Oplysninger krypteres ved hjælp af GOST 28147–89-algoritmen. Hash-funktionen beregnes ved hjælp af algoritmen GOST R 34.11–94, GOST R 34.11–2012. Generering og verifikation af en elektronisk signatur udføres i overensstemmelse med algoritmen GOST R 34.10–2001, GOST R 34.10–2012.

Skjuler beskyttede servere og adresseoversættelse

Continent TLS VPN filtrerer anmodninger og sender anmodningsadresser til webservere på virksomhedens netværk. Adresseoversættelse udføres i overensstemmelse med reglerne fastsat af "Continent TLS VPN"-administratoren.

Fejltolerance og skalerbarhed

Continent TLS VPN understøtter drift i et højtydende klyngedesign med belastningsbalancering (ekstern belastningsbalancer). Øget fejltolerance opnås ved at tilføje en redundant node til klyngen. Samtidig kan udvidelsen af balancerende klyngeelementer udføres ubegrænset. Fejl i et klyngeelement fører ikke til afbrudte forbindelser, da belastningen er jævnt fordelt mellem de resterende elementer.

Hændelsesovervågning og logning

I Continent TLS VPN kan administratoren altid indhente driftsoplysninger om den aktuelle tilstand af etablerede forbindelser og statistik om driften. Informationssikkerhedshændelser logges på serveren. Alle hændelser kan sendes til en specificeret server i syslog-format for yderligere analyse, hvilket gør integration med SIEM-systemer så enkel som muligt.

Praktiske styringsværktøjer

Kombinationen af lokale og eksterne værktøjer med en webgrænseflade og en praktisk grafisk administrationskonsol giver fleksibel konfiguration af Continent TLS VPN i overensstemmelse med kravene i sikkerhedspolitikker.

Understøttede protokoller

Continent TLS VPN understøtter TLS v.1, TLS v.2 protokoller.

Brugeroplevelse via enhver webbrowser

Ved at bruge Continent TLS VPN Client-applikationen kan brugere få adgang til beskyttede ressourcer fra enhver webbrowser. Continent TLS VPN Client er en lokal proxy, opsnapper browsertrafik til beskyttede webservere og pakker den ind i en http-tunnel. Takket være dette kan brugeren arbejde med enhver webbrowser installeret på sin enhed.

Brug af en brugervenlig softwareklient

Brug af en brugervenlig softwareklient Continent TLS VPN Client eller CryptoPro CSP version 3.6.1 kan bruges som klient på brugerens enhed.

TLS og SSL er blevet nævnt mere og mere på det seneste, brugen af digitale certifikater er blevet mere relevant, og der er dukket endda virksomheder op, der er klar til at levere gratis digitale certifikater til alle for at sikre, at trafikken mellem besøgte websteder og klientens browser er krypteret. Dette er naturligvis nødvendigt af hensyn til sikkerheden, så ingen på netværket kan modtage de data, der sendes fra klienten til serveren og tilbage. Hvordan fungerer det hele, og hvordan bruger man det? For at forstå dette må vi måske starte med teori og så vise det i praksis. Altså SSL og TLS.

Hvad er SSL, og hvad er TLS?

SSL - Secure Socket Layer, et lag af sikre sockets. TLS - Transport Layer Security, transportlagssikkerhed. SSL er et tidligere system, TLS kom senere og er baseret på SSL 3.0-specifikationen udviklet af Netscape Communications. Disse protokoller har dog én opgave - at sikre sikker dataoverførsel mellem to computere på internettet. Denne overførsel bruges til forskellige hjemmesider, til e-mail, til beskeder og meget mere. I princippet kan du overføre enhver information på denne måde; mere om det nedenfor.

Sikker transmission er sikret ved autentificering og kryptering af de transmitterede oplysninger. I det væsentlige fungerer disse protokoller, TLS og SSL, det samme; der er ingen grundlæggende forskelle. TLS kan siges at være efterfølgeren til SSL, selvom de kan bruges samtidigt, selv på samme server. En sådan support er nødvendig for at sikre arbejde med både nye klienter (enheder og browsere) og ældre klienter, der ikke understøtter TLS. Sekvensen for forekomsten af disse protokoller ser sådan ud:

SSL 1.0 - aldrig offentliggjort
SSL 2.0 - februar 1995
SSL 3.0 - 1996
TLS 1.0 - januar 1999
TLS 1.1 - april 2006
TLS 1.2 - august 2008

Sådan fungerer SSL og TLS

Funktionsprincippet for SSL og TLS er som sagt det samme. En krypteret kanal etableres oven på TCP/IP-protokollen, inden for hvilken data overføres via applikationsprotokollen - HTTP, FTP, og så videre. Sådan kan det repræsenteres grafisk:

Applikationsprotokollen er "indpakket" i TLS/SSL, som igen er pakket ind i TCP/IP. I det væsentlige transmitteres applikationsprotokoldata over TCP/IP, men de er krypteret. Og kun den maskine, der etablerede forbindelsen, kan dekryptere de overførte data. For alle andre, der modtager de transmitterede pakker, vil denne information være meningsløs, hvis de ikke kan dekryptere den.

Forbindelsen etableres i flere trin:

1) Klienten etablerer en forbindelse til serveren og anmoder om en sikker forbindelse. Dette kan opnås enten ved at etablere en forbindelse til en port, der oprindeligt er beregnet til at fungere med SSL/TLS, for eksempel 443, eller ved yderligere at anmode klienten om at etablere en sikker forbindelse efter etablering af en almindelig.

2) Ved etablering af en forbindelse giver klienten en liste over krypteringsalgoritmer, som den "kender". Serveren tjekker den modtagne liste med listen over algoritmer, som serveren selv "kender" og vælger den mest pålidelige algoritme, hvorefter den fortæller klienten, hvilken algoritme den skal bruge

3) Serveren sender klienten sit digitale certifikat, underskrevet af certificeringsmyndigheden, og serverens offentlige nøgle.

4) Klienten kan kontakte serveren for den betroede certifikatmyndighed, der underskrev servercertifikatet, og kontrollere, om servercertifikatet er gyldigt. Men måske ikke. Operativsystemet har normalt allerede installeret rodcertifikater fra certificeringsmyndigheder, mod hvilke signaturerne af servercertifikater verificeres, for eksempel af browsere.

5) En sessionsnøgle genereres til en sikker forbindelse. Dette gøres som følger:
— Klienten genererer en tilfældig digital sekvens
— Klienten krypterer det med serverens offentlige nøgle og sender resultatet til serveren
— Serveren dekrypterer den modtagne sekvens ved hjælp af den private nøgle
Da krypteringsalgoritmen er asymmetrisk, er det kun serveren, der kan dekryptere sekvensen. Ved brug af asymmetrisk kryptering bruges to nøgler - private og offentlige. En besked sendt offentligt er krypteret, og en besked sendt privat er dekrypteret. Det er umuligt at dekryptere en besked, hvis du har en offentlig nøgle.

6) Dette etablerer en krypteret forbindelse. Data, der overføres over det, krypteres og dekrypteres, indtil forbindelsen afbrydes.

Rodcertifikat

Lige ovenfor nævnte jeg rodcertifikatet. Dette er et autorisationscentercertifikat, hvis underskrift bekræfter, at det certifikat, der er underskrevet, er det, der tilhører den tilsvarende tjeneste. Selve certifikatet indeholder normalt en række informationsfelter, der indeholder oplysninger om navnet på den server, som certifikatet blev udstedt til, og gyldighedsperioden for dette certifikat. Hvis certifikatet er udløbet, er det ugyldigt.

Signaturanmodning (CSR, Certificate Sign Request)

For at få et signeret servercertifikat skal du generere en signaturanmodning (CSR, Certificate Sign Request) og sende denne anmodning til autorisationscentret, som returnerer et signeret certifikat installeret direkte på serveren. Nedenfor ser vi hvordan du gør dette i praksis. Først genereres en krypteringsnøgle, og derefter, baseret på denne nøgle, genereres en signaturanmodning, en CSR-fil.

Klientcertifikat

Et klientcertifikat kan genereres til både enheds- og brugerbrug. Typisk bruges sådanne certifikater i tovejsverifikation, hvor klienten verificerer, at serveren er den, den siger, den er, og serveren gør det samme til gengæld. Denne interaktion kaldes tovejsgodkendelse eller gensidig godkendelse. Tovejsgodkendelse forbedrer sikkerhedsniveauet sammenlignet med envejsgodkendelse og kan også tjene som erstatning for godkendelse ved hjælp af et login og adgangskode.

Kæde af handlinger til generering af certifikater

Lad os tage et praktisk kig på, hvordan de handlinger, der er forbundet med at generere certifikater, sker helt fra begyndelsen og i praksis.

Den første ting at gøre er at generere et rodcertifikat. Rodcertifikatet er selvsigneret. Og så vil andre certifikater blive underskrevet med dette certifikat.

$ openssl genrsa -out root.key 2048 Genererer RSA privat nøgle, 2048 bit lang modul .......+++ ....... ............... .........+++ e er 65537 (0x10001) $ openssl req -new -key root.key -out root.csr Du er ved at blive bedt om at indtaste oplysninger, der vil blive inkorporeret i din certifikatanmodning . Det, du er ved at indtaste, er det, der kaldes et Distinguished Name eller et DN. Der er en del felter, men du kan lade nogle være tomme. For nogle felter vil der være en standardværdi. Hvis du indtaster ".", vil feltet stå tomt. ----- Landenavn (2 bogstavskode) :RU Stats- eller provinsnavn (fuldt navn) :N/A Lokalitetsnavn (f.eks. by) :Saint-Petersburg Organisationsnavn (f.eks. virksomhed) :Min virksomheds organisationsenhedsnavn (f.eks. sektion): IT-tjenestens almindelige navn (f.eks. server FQDN eller DIT navn) : E-mail-adresse for mit firmarodcertifikat: [e-mail beskyttet] Indtast venligst følgende "ekstra" attributter, der skal sendes med din certifikatanmodning. En udfordringsadgangskode: Et valgfrit firmanavn: Mit firma $ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem Signatur ok emne=/C=RU/ST=N/A/L=Saint-Petersburg/O=Min virksomhed/OU=IT-service/CN=Min virksomheds rodcertifikat/ [e-mail beskyttet] Får privat nøgle

Således genererede vi først en privat nøgle, derefter en signaturanmodning og underskrev derefter vores egen anmodning med vores nøgle og modtog vores eget digitale certifikat, udstedt for 10 år. Du behøver ikke indtaste en udfordringsadgangskode, når du genererer et certifikat.

Den private nøgle SKAL opbevares et sikkert sted; har du den, kan du underskrive ethvert certifikat på dine vegne. Og det resulterende rodcertifikat kan bruges til at identificere, at serverens certifikat for eksempel blev underskrevet af os og ikke af en anden. Det er de handlinger, som autorisationscentre udfører, når de genererer deres egne certifikater. Når du har oprettet rodcertifikatet, kan du begynde at generere servercertifikatet.

Se certifikatoplysninger

Indholdet af certifikatet kan ses som følger:

$ openssl x509 -noout -udsteder -slutdato -in root.pem udsteder= /C=RU/ST=N/A/L=Saint-Petersburg/O=Min virksomhed/OU=IT Service/CN=Min virksomheds rodcertifikat/ [e-mail beskyttet] notAfter=22. jan 11:49:41 2025 GMT

Vi kan se, hvem der har udstedt dette certifikat, og hvornår dets udløbsdato udløber.

Servercertifikat

For at underskrive et certifikat til serveren skal vi gøre følgende:

1) Generer en nøgle
2) Generer en signaturanmodning
3) Send CSR-filen til autorisationscentret eller underskriv den selv

Et servercertifikat kan omfatte kæden af certifikater, der underskriver servercertifikatet, men det kan også gemmes i en separat fil. I princippet ser alt nogenlunde det samme ud, som når man genererer et rodcertifikat

$ openssl genrsa -out server.key 2048 Genererer privat RSA-nøgle, 2048 bit lang modul ................................ ....... ................................................ . +++ .........................+++ e er 65537 (0x10001) $ openssl req -new -key server.key - out server .csr Du er ved at blive bedt om at indtaste oplysninger, der vil blive inkorporeret i din certifikatanmodning. Det, du er ved at indtaste, er det, der kaldes et Distinguished Name eller et DN. Der er en del felter, men du kan lade nogle være tomme. For nogle felter vil der være en standardværdi. Hvis du indtaster ".", vil feltet stå tomt. ----- Landenavn (2 bogstavskode) :RU Stats- eller provinsnavn (fuldt navn) :N/A Lokalitetsnavn (f.eks. by) :Saint-Petersburg Organisationsnavn (f.eks. virksomhed) :Min virksomheds organisationsenhedsnavn (f.eks. sektion) :IT Service Common Name (f.eks. server FQDN eller DIT navn) :www.mycompany.com E-mail-adresse: [e-mail beskyttet] Indtast venligst følgende "ekstra" attributter, der skal sendes med din certifikatanmodning. En udfordringsadgangskode: Et valgfrit firmanavn: $ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out server. pem -dage 365 Signatur ok subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=Mit firma/OU=IT Service/CN=www.mycompany.com/ [e-mail beskyttet] Henter CA Private Key $ openssl x509 -noout -udsteder -emne -slutdato -in server.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=Mit firma/OU=IT Service/CN =Mit firma rodcertifikat/ [e-mail beskyttet] subject= /C=RU/ST=N/A/L=Saint-Petersburg/O=Min virksomhed/OU=IT Service/CN=www.mycompany.com/emailAd [e-mail beskyttet] notAfter=Jan 25 12:22:32 2016 GMT

På denne måde signeres servercertifikatet, og vi ved, hvilken organisation der har udstedt dette certifikat. Efter signering kan det færdige certifikat bruges til dets tilsigtede formål, for eksempel installeret på en webserver.

Installation af et SSL/TLS-certifikat på en server med nginx

For at installere et SSL/TLS-certifikat på nginx-webserveren skal du følge et par enkle trin:

1) Kopier .key- og .pem-filerne til serveren. På forskellige operativsystemer kan certifikater og nøgler gemmes i forskellige mapper. I Debian, for eksempel, er dette mappen /etc/ssl/certs for certifikater og /etc/ssl/private for nøgler. På CentOS er dette /etc/pki/tls/certs og /etc/pki/tls/private

2) Skriv de nødvendige indstillinger i konfigurationsfilen for værten. Sådan skal det nogenlunde se ud (bare et eksempel):

Server (lyt 443; server_name www.mycompany.com; root html; index index.html index.htm; ssl on; ssl_certificate server.pem; ssl_certificate_key server.key; ssl_session_timeout 5m; # SSLv3 anbefales ikke!!! # Det er her for eksempel kun ssl_protocols SSLv3 TLSv1; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP; ssl_prefer_server_ciphers on; location / ( try_files/ $uri $uri; ))

3) Genstart nginx

4) Gå til serverport 443 med en browser - https://www.mycompany.com og tjek dens funktionalitet.

Installation af et SSL/TLS-certifikat på en server, der kører Apache

Installation af et SSL/TLS-certifikat på Apache ser ens ud.

1) Kopier nøgle- og certifikatfilerne til serveren i de relevante mapper

2) Aktiver ssl-modulet til Apache med kommandoen "a2enmod ssl", hvis det ikke allerede er aktiveret

3) Opret en virtuel vært, der lytter til port 443. Konfigurationen vil se sådan ud:

ServerAdmin [e-mail beskyttet] DocumentRoot /var/www Indstillinger FølgSymLinks TilladOverride Ingen Indstillinger Indekser FølgSymLinks MultiViews Tillad Tilsidesæt Ingen Bestil tillad, afvis tillad fra alle ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ TilladOverride Ingen Indstillinger +ExecCGI -MultiViews +SymLinksIfOwnerMatch Ordre tillad, nægt Tillad fra alle ErrorLog $(APACHE_LOG_DIR)/error.log LogLevel advarsel CustomLog $(APACHE_LOG_DIR)/ssl_access.log kombineret SSLEngine på SSLCertificateFile /etc/ssl/certs/server.pem SSLCertificateKeyFile /etc/ssl/This directiveserver add a #private/privateserver fil , der indeholder en liste # over alle certifikater, der signerede servercertifikatet #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

Samtidig er der noget andet, der skal gøres. Find i filen httpd.conf, eller apache2.conf eller ports.conf, afhængigt af systemet, følgende sektion af config:

Hør 443

Hvis der ikke er en sådan betingelse, skal den tilføjes til konfigurationen. Og en ting mere: Du skal tilføje linjen

NameVirtualHost *:443

Denne linje kan være i filen httpd.conf, apache2.conf eller ports.conf

4) Genstart Apache-webserveren

Oprettelse af et klientcertifikat

Et klientcertifikat oprettes stort set på samme måde som et servercertifikat.

$ openssl genrsa -out client.key 2048 Genererer privat RSA-nøgle, 2048 bit lang modul ........................+++ ..... ........................................+++ e er 65537 (0x10001) $ openssl req -new -key client.key -out client.csr Du er ved at blive bedt om at indtaste oplysninger, der vil blive inkorporeret i din certifikatanmodning. Det, du er ved at indtaste, er det, der kaldes et Distinguished Name eller et DN. Der er en del felter, men du kan lade nogle være tomme. For nogle felter vil der være en standardværdi. Hvis du indtaster ".", vil feltet stå tomt. ----- Landenavn (2 bogstavskode) :RU Stats- eller provinsnavn (fulde navn) :Saint-Petersburg Lokalitetsnavn (f.eks. by) :^C mnorin@mnorin-work:~/Temp/certs/CA$ openssl req -new -key client.key -out client.csr Du er ved at blive bedt om at indtaste oplysninger, der vil blive inkorporeret i din certifikatanmodning. Det, du er ved at indtaste, er det, der kaldes et Distinguished Name eller et DN. Der er en del felter, men du kan lade nogle være tomme. For nogle felter vil der være en standardværdi. Hvis du indtaster ".", vil feltet stå tomt. ----- Landenavn (2 bogstavskode) :RU Stats- eller provinsnavn (fuldt navn) :N/A Lokalitetsnavn (f.eks. by) :Saint-Petrersburg Organisationsnavn (f.eks. virksomhed) :Min virksomheds organisationsenhedsnavn (f.eks. sektion) :Engineering almindeligt navn (f.eks. server FQDN eller DIT navn) :Ivan Ivanov E-mail-adresse: [e-mail beskyttet] Indtast venligst følgende "ekstra" attributter, der skal sendes med din certifikatanmodning. En udfordringsadgangskode: Et valgfrit firmanavn: $ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client. pem -dage 365 Underskrift ok emne=/C=RU/ST=N/A/L=Saint-Petrersburg/O=Mit firma/OU=Engineering/CN=Ivan Ivanov/ [e-mail beskyttet] Hent CA Private Key $ openssl x509 -noout -udsteder -emne -slutdato -in client.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=Mit firma/OU=IT Service/CN =Mit firma rodcertifikat/ [e-mail beskyttet] emne= /C=RU/ST=N/A/L=Saint-Petrersburg/O=Mit firma/OU=Engineering/CN=Ivan Ivanov/e-mail [e-mail beskyttet] notAfter=Jan 25 13:17:15 2016 GMT

Hvis du har brug for et klientcertifikat i PKCS12-format, skal du oprette det:

$ openssl pkcs12 -eksport -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12 Indtast Eksportkodeord: Bekræfter - Indtast Eksportkodeord:

Nu kan du bruge klientcertifikatet til at arbejde med vores server.

Konfiguration af nginx til at bruge klientcertifikater

Oftest bruges, som jeg allerede har sagt, envejsgodkendelse, normalt er det kun servercertifikatet, der kontrolleres. Lad os se, hvordan man tvinger nginx-webserveren til at verificere klientcertifikatet. Det er nødvendigt at tilføje indstillinger til serversektionen for at arbejde med klientcertifikater:

# Rodcertifikat(er), som klienten er signeret med ssl_client_certificate /etc/nginx/certs/clientroot.pem; # Mulige muligheder: på | slukket | valgfri | optional_no_ca ssl_verify_client valgfri; # Verifikationsdybde af kæden af certifikater, som klienten er signeret med ssl_verify_depth 2;

Herefter skal du genstarte indstillingerne eller hele serveren, og du kan kontrollere handlingen.

Konfiguration af Apache til at bruge klientcertifikater

Apache kan også konfigureres ved at tilføje yderligere muligheder til den virtuelle værtssektion:

# Katalog indeholdende rodcertifikater til klientbekræftelse SSLCARevocationPath /etc/apache2/ssl.crl/ # eller fil, der indeholder certifikater SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Klientbekræftelsesmulighed. Mulige muligheder: # ingen, valgfri, kræve og optional_no_ca SSLVerifyClient kræver # Se dybden af signaturkæden. Standard 1 SSLVerifyDepth 2

Som du kan se, er mulighederne omtrent de samme som for nginx, da verifikationsprocessen er organiseret ensartet.

Lytte til certifikatoplysninger ved hjælp af openssl

For at teste, hvordan serveren interagerer med klientcertifikater, kan du kontrollere, om forbindelsen er etableret ved hjælp af TLS/SSL.

På serversiden begynder vi at lytte på porten ved hjælp af openssl:

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

På klientsiden får vi adgang til serveren, for eksempel med culr:

Curl -k https://127.0.0.1:443

I konsollen på serversiden kan du observere processen med informationsudveksling mellem serveren og klienten.

Du kan også bruge mulighederne -verify [verification depth] og -Verify [verification depth]. Muligheden for små sager beder klienten om et certifikat, men det er ikke påkrævet at give et. Store bogstaver - Hvis et certifikat ikke leveres, vil der opstå en fejl. Lad os begynde at lytte på serversiden sådan her:

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

Fra serversiden ser fejlen sådan ud:

140203927217808:fejl:140890C7:SSL-rutiner:SSL3_GET_CLIENT_CERTIFICATE:peer returnerede ikke et certifikat:s3_srvr.c:3287:

Fra klientsiden sådan her:

Curl: (35) fejl:14094410:SSL-rutiner:SSL3_READ_BYTES:sslv3-alarm-håndtryksfejl

Lad os tilføje et certifikat og et domænenavn på klientsiden (du kan indtaste værtsnavnet for adressen 127.0.0.1 i filen /etc/hosts for at kontrollere):

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

Nu vil forbindelsen være vellykket, og du kan installere servercertifikatet på webserveren, give klientcertifikatet til klienten og arbejde med dem.

Sikkerhed

Ved brug af SSL/TLS er en af hovedmetoderne MITM (Man In The Middle) metoden. Denne metode er afhængig af brugen af et servercertifikat og en nøgle på en eller anden node, der vil lytte til trafikken og dekryptere informationen, der udveksles mellem serveren og klienten. For at organisere lytning kan du f.eks. bruge programmet sslsniff. Derfor er det normalt tilrådeligt at gemme rodcertifikatet og nøglen på en maskine, der ikke er tilsluttet netværket; til signering skal du medbringe signaturanmodninger på et flashdrev, underskrive og tage det væk. Og selvfølgelig lave sikkerhedskopier.

Generelt er det sådan, digitale certifikater og TLS- og SSL-protokollerne bruges. Har du spørgsmål/tilføjelser, så skriv i kommentarfeltet.

Indlægget blev udgivet af forfatteren i kategorien tagget , .

: 29 kommentarer

cl-service.com
Klienten genererer selv CSR'en ved bestilling af et certifikat, hvor klienten også beslutter at gemme den private nøgle, for at udstede et certifikat behøver vi ikke den private nøgle, og klienten giver os den ikke på nogen måde. Hvis dette sker på en almindelig virtuel server, så har administratorer med root-adgang til serveren naturligvis også adgang til de nøgler, der er gemt der.
Velbekomme.
Emnet bryster er ikke dækket, fordi den beskrevne PKI-teknologi ikke har noget at gøre med titlen på emnet. I det mindste med god grund gav jeg links til rfc.
P.S. Der var en joke om en hund og en loppe.
Velbekomme.
Jeg havde ikke til hensigt at fornærme dig på nogen måde. Jeg ledte efter information om forskellen mellem SSl og TLS i praksis, og dit link var det første i Google. Jeg var fascineret af titlen på emnet. Alt er fedt, fortsæt!
DrAibolit
Tak for dine indsigtsfulde forklaringer om digital certificering. Jeg er ny i det her =)
Jeg håber, du kan afklare følgende spørgsmål.
Da emnet svindel er meget udviklet i internetindustrien, vil jeg gerne lære at bestemme "lusene" på de sider, jeg besøger på egen hånd (især hvor der er kontanter og betalinger, investeringer osv.) og baseret på dette bestemmer graden af min tillid (jeg skal ofte registrere, efterlade personlige oplysninger, foretage køb, transaktioner, investeringer). Hvis jeg forstår det rigtigt, giver det dig mulighed for at foretage en sådan vurdering at have denne certificering. Nå, på den anden side er det ikke et problem at få det, og det er endda gratis.
Hvordan eller med hvilket program kan du afgøre, om en hjemmeside har et digitalt certifikat? og helst dens kategori, som tildeles, når en særlig myndighed udsteder SSL DV (certifikatet udstedes med verifikation af kun domænet), SSL OV (med verifikation af organisationen), EV (med udvidet verifikation af den juridiske enhed). Svigagtige websteder vil højst sandsynligt ikke bruge den seneste certificeringsmulighed.
Jeg ville være glad, hvis du fortæller mig flere måder at bestemme pålideligheden af websteder))
1. mnorin Post forfatter
  Jeg er endnu ikke stødt på noget specifikt program til disse formål, men jeg kan give et par tips om denne sag.
  Du kan for eksempel bruge Chromium eller Google Chrome. Lad os for eksempel tage siden https://www.thawte.com/ – en virksomhed, der rent faktisk beskæftiger sig med digitale certifikater.
  Adresselinjen vil indeholde firmanavnet og en grøn hængelås. Det betyder, at organisationen er verificeret, dette er mindst SSL OV.
  Hvis du klikker på låsen, og i rullemenuen “Detaljer” og derefter “Vis certifikat”, kan du se information om certifikatet. For Thawte er certifikatet underskrevet af følgende certifikat: "thawte Extended Validation SHA256 SSL CA", og certifikatet for click.alfabank.ru er også underskrevet af Thawte, men med et andet certifikat. Dette er "thawte EV SSL CA - G3", det vil sige, at de også bestod Extended Validation.
  Sådan noget.
Ruslan
Afsnit "Sådan fungerer SSL og TLS", "Klienten genererer en tilfældig digital sekvens."

Jeg var sikker på, at klienten genererer session private og følgelig offentlige nøgler (som du åbenbart kaldte "digital sekvens"). Den offentlige nøgle sendes til serveren, og serveren krypterer pakkerne til klienten med klientens offentlige sessionsnøgle.

Forklar venligst.
Nybegynder
Artiklen er meget nyttig! Der er endda praktiske eksempler =) Men jeg forstod ikke én ting - hvad er forskellen mellem et rodcertifikat og et servercertifikat? eller er det det samme?
Vitaly
Hej.
Hosteren tilbød en tjeneste - SSL til virtuelle servere. Vi udnyttede det. Det viste sig, at for tredje niveau, dvs. http://www.site.ru-certifikatet er ugyldigt, kun for site.ru. Desuden skifter besøgende konstant til https-protokollen, uanset om de går til site.ru eller http://www.site.ru. Selvfølgelig begynder browseren i det andet tilfælde at bande hjerteskærende, og den besøgende kommer aldrig til siden.
Men for dem, der kom til siden, begyndte siden at se skæv ud, en del af menuen forsvandt, og nogle af billederne i søgeresultaterne holdt op med at blive vist af nogle komponenter.

For at installere Continent TLS Client-softwaren skal du bruge:

Figur 33. Startvinduet for "Continent TLS Client" softwareinstallationsguiden.

Figur 34. Licensaftalevindue for Continent TLS Client-softwaren.

3. Marker afkrydsningsfeltet "Jeg accepterer vilkårene i licensaftalen", og klik på knappen "Næste". Der vises et vindue på skærmen til indtastning af licensnøglen, der følger med Continent TLS Client-softwaren på papir eller elektroniske medier.

Figur 35. Vindue til indtastning af licensnøglen til Continent TLS Client-softwaren.

4. Indtast licensnøglen, og klik på Næste. En dialogboks til valg af installationsstien til Continent TLS Client-softwaren vises på skærmen.

Figur 36. Vindue til valg af installationsstien til Continent TLS Client-softwaren.

5. Forlad standardinstallationsstien. Klik på "Næste". Dialogen "Start konfigurator" vises på skærmen.

Figur 37. Startvindue for Continent TLS Client-softwarekonfiguratoren.

6. Marker afkrydsningsfeltet "Kør konfiguratoren efter installationen er fuldført".

Figur 38. Klarhedsvindue til installation af Continent TLS Client-softwaren.

8. Klik på knappen "Installer". Installationen af komponenten begynder.

Figur 39. Installationsproces af Continent TLS Client-softwaren.

9. Dialogboksen "Continent TLS Client" softwareindstillinger vil blive vist på skærmen.

Figur 40. Konfiguration af Continent TLS Client-softwaren.

For at konfigurere den software, du skal bruge:

a) I afsnittet "Continent TLS Client Settings" skal du lade "Port"-værdien være på standardværdien 8080.

b) I afsnittet "Beskyttede serverindstillinger" i feltet "Adresse" skal du angive TLS-servernavnet: lk.budget.gov.ru.

c) I afsnittet "Beskyttede serverindstillinger" i feltet "Certifikat" skal du angive TLS-servercertifikatfilen, der er kopieret til den lokale mappe i afsnit 3.1 i denne vejledning.

Figur 41. Konfiguration af Continent TLS Client-softwaren. Valg af certifikat.

d) Hvis brugerens arbejdsstation ikke bruger en ekstern proxyserver, skal du klikke på knappen "OK".

e) Ellers angives adressen og porten på organisationens eksterne proxyserver, der bruges.

Figur 42. Konfiguration af Continent TLS Client-softwaretjenesten. Opsætning af en ekstern proxyserver.

f) Klik på knappen "OK".

10. En dialogboks til fuldførelse af installationen af Continent TLS Client-softwaren vil blive vist på skærmen.

Figur 43. Dialog for færdiggørelse af installationen af Continent TLS Client-softwaren.

11. Klik på knappen "Udført".

12. Der vises en dialog på skærmen om behovet for at genstarte brugerens arbejdsstation.

Figur 44. Dialog om behovet for at genstarte brugerens arbejdsstation.

13. Klik på knappen "Nej".