За да инсталирате софтуера Continent TLS Client, трябва:
Фигура 33. Стартовият прозорец на съветника за инсталиране на софтуера Continent TLS Client.
Фигура 34. Прозорец лицензионно споразумение Continent TLS клиентски софтуер.
3. Поставете отметка в квадратчето „Приемам условията на лицензионното споразумение“ и щракнете върху бутона „Напред“. На екрана ще се появи прозорец за въвеждане на лицензния ключ, доставен със софтуера Continent TLS Client на хартиен или електронен носител.
Фигура 35. Прозорец за въвеждане на лицензен ключ за софтуера Continent TLS Client.
4. Въведете лицензионен ключи щракнете върху бутона "Напред". На екрана ще се появи диалогов прозорец за избор на пътя за инсталиране на софтуера Continent TLS Client.
Фигура 36. Прозорец за избор на пътя за инсталиране на софтуера Continent TLS Client.
5. Оставете инсталационния път по подразбиране. Натиснете "Напред". На екрана ще се появи диалоговият прозорец "Стартиране на конфигуратора".
Фигура 37. Прозорец за стартиране на конфигуратора на софтуера Continent TLS Client.
6. Поставете отметка в квадратчето „Изпълни конфигуратора след завършване на инсталацията“.
Фигура 38. Прозорец на готовност за инсталиране на софтуера Continent TLS Client.
8. Щракнете върху бутона "Инсталиране". Инсталирането на компонента ще започне.
Фигура 39. Процесът на инсталиране на софтуера Continent TLS Client.
9. На екрана ще се покаже диалоговият прозорец за конфигурация на софтуера Continent TLS Client.
Фигура 40. Конфигуриране на софтуера Continent TLS Client.
За да конфигурирате софтуера, от който се нуждаете:
a) В секцията „Настройки на континента на TLS на клиента“ оставете стойността „Порт“ по подразбиране, равна на 8080.
б) В секцията „Настройки на защитен сървър“ в полето „Адрес“ посочете името TLS сървъри: lk.budget.gov.ru.
c) В раздела „Настройки на защитен сървър“, в полето „Сертификат“, посочете файла със сертификат на TLS сървъра, копиран в локалната директория в точка 3.1 от това Ръководство.
Фигура 41. Конфигуриране на софтуера Continent TLS Client. Избор на сертификат.
d) Ако работната станция на потребителя не използва външен прокси сървър, щракнете върху бутона "OK".
д) В противен случай посочете адреса и порта на външния прокси сървър на организацията, който да се използва.
Фигура 42. Настройване на софтуерната услуга Continent TLS Client. Настройка на външен прокси сървър.
f) Натиснете бутона OK.
10. На екрана ще се покаже диалоговият прозорец за завършване на инсталацията на софтуера Continent TLS Client.
Фигура 43. Диалогов прозорец за завършване на инсталирането на софтуера Continent TLS Client.
11. Натиснете бутона "Край".
12. На екрана ще се появи диалогов прозорец с молба да рестартирате работната станция на потребителя.
Фигура 44. Диалогов прозорец за необходимостта от рестартиране на работната станция на потребителя.
13. Натиснете бутона "Не".
Софтуер Континент TLS VPN– система за осигуряване на сигур отдалечен достъпкъм уеб приложения, използващи GOST алгоритми за криптиране. Continent TLS VPN внедрява криптографска защита HTTP трафик на ниво сесия. Криптирането на информацията се извършва съгласно алгоритъма GOST 28147–89.
Идентифициране и удостоверяване на отдалечени потребители
Идентификацията и удостоверяването на потребителите се извършват с помощта на сертификати за публичен ключ на стандарта x.509v3 (GOST R 31.11–94, 34.10–2001). TLS VPN Continent проверява сертификатите за ключове спрямо списъците за анулирани сертификати (CRL). Сертификатите се издават от външен сертифициращ орган.
В случай на успешно завършване на процедурите за удостоверяване, заявката на потребителя се пренасочва чрез HTTP към защитена мрежа към съответния уеб сървър. В този случай към всяка HTTP сесия на потребителя се добавят специални идентификатори (клиентски идентификатор и IP идентификатор).
Криптографска защита на предаваната информация
TLS VPN Continent изпълнява криптографска защита на HTTP трафик на ниво сесия. Криптирането на информацията се извършва съгласно алгоритъма GOST 28147–89. Хеш функцията се изчислява съгласно алгоритъма GOST R 34.11–94, GOST R 34.11–2012. Формирането и проверката на електронния подпис се извършват в съответствие с алгоритъма GOST R 34.10–2001, GOST R 34.10–2012.
Скриване на защитени сървъри и превод на адреси
TLS VPN Continent филтрира заявките и превежда адресите на заявките към уеб сървъри корпоративна мрежа. Преводът на адреси се извършва в съответствие с правилата, определени от администратора на "Continent TLS VPN".
Толерантност към грешки и мащабируемост
TLS VPN Continent поддържа работа във високопроизводителна клъстерна схема с балансиране на натоварването (външен балансьор на натоварването). Повишаването на толерантността към грешки се постига чрез добавяне на излишен възел към клъстера. В същото време елементите на балансиращия клъстер могат да се увеличават неограничено. Повредата на елемент на клъстера не води до прекъсване на връзките, тъй като натоварването е равномерно разпределено между останалите елементи.
Мониторинг и регистриране на събития
В TLS VPN Continent администраторът винаги може да получи актуална информация за текущото състояние на установените връзки и статистика за неговата работа. Събитията се регистрират на сървъра информационна сигурност. Всички събития могат да бъдат изпратени до посочения сървър във формат syslog за допълнителен анализ, което прави интеграцията със SIEM системите възможно най-проста.
Удобни инструменти за управление
Комбинацията от местни и дистанционни инструментис уеб интерфейс и удобна графична конзола за управление осигурява гъвкава конфигурация на TLS VPN Continent в съответствие с изискванията на политиките за сигурност.
Поддържани протоколи
TLS VPN Continent поддържа протоколи TLS v.1, TLS v.2.
Потребителска работа през всеки уеб браузър
Използвайки приложението Continent TLS VPN Client, потребителите могат да имат достъп до защитени ресурси от всеки уеб браузър. Continent TLS VPN Клиентът е локален прокси, който прихваща трафика на браузъра към защитени уеб сървъри и го пакетира в http тунел. Благодарение на това потребителят може да работи с всеки уеб браузър, инсталиран на устройството му.
Използване на удобен за потребителя софтуерен клиент
Използване на удобен за потребителя софтуерен клиент Continent TLS VPN Client или CryptoPro може да се използва като клиент на устройството на потребителя CSP версии 3.6.1.
TLS и SSL се споменават все по-често напоследък, използването на цифрови сертификати става все по-актуално и дори се появиха компании, които са готови да предоставят цифрови сертификати на всички безплатно, за да гарантират криптиране на трафика между посетените сайтове и браузъра на клиента. Това е необходимо, разбира се, за сигурност, така че никой в мрежата да не може да получи данни, които се предават от клиента към сървъра и обратно. Как работи всичко това и как да го използвате? За да разберем това, може би е необходимо да започнем с теория и след това да покажем на практика. И така, SSL и TLS.
Какво е SSL и какво е TLS?
SSL означава Secure Socket Layer, нивото на защитените сокети. TLS - Transport Layer Security, сигурност на транспортния слой. SSL е по-стара система, TLS е по-нова и се основава на спецификацията SSL 3.0, разработена от Netscape Communications. Въпреки това задачата на тези протоколи е една и съща - да осигурят сигурен трансфер на данни между два компютъра в Интернет. Този трансфер се използва за различни сайтове, за електронна поща, за съобщения и много други. По принцип можете да прехвърляте всяка информация по този начин, повече за това по-долу.
Сигурното предаване се осигурява чрез удостоверяване и криптиране на предаваната информация. Всъщност тези протоколи, TLS и SSL, работят по същия начин, няма фундаментални разлики. Може да се каже, че TLS е наследник на SSL, въпреки че те могат да се използват едновременно, дори на един и същи сървър. Такава поддръжка е необходима, за да се осигури работа както с нови клиенти (устройства и браузъри), така и със стари, които не поддържат TLS. Последователността на появата на тези протоколи изглежда така:
SSL 1.0 - никога не е публикуван
SSL 2.0 - февруари 1995 г
SSL 3.0 - 1996 г
TLS 1.0 - януари 1999 г
TLS 1.1 - април 2006 г
TLS 1.2 - август 2008 г
Как работят SSL и TLS
Принципът на работа на SSL и TLS, както казах, е един и същ. По протокола TCP / IP се установява криптиран канал, в рамките на който данните се предават чрез протокола на приложението - HTTP, FTP и т.н. Ето как може да се представи графично:
Протоколът на приложението е "опакован" в TLS/SSL, който от своя страна е опакован в TCP/IP. Всъщност данните от протокола на приложението се предават през TCP / IP, но са криптирани. И само машината, която е установила връзката, може да дешифрира предадените данни. За всички останали, които получават предадените пакети, тази информация ще бъде безсмислена, ако не могат да я дешифрират.
Връзката се осъществява в няколко стъпки:
1) Клиентът установява връзка със сървъра и иска защитена връзка. Това може да се постигне или чрез установяване на връзка на порт, който първоначално е проектиран да работи с SSL/TLS, като например 443, или допълнителна заявкаклиент, установяващ защитена връзка след установяване на нормална.
2) При установяване на връзка клиентът предоставя списък с алгоритми за криптиране, които „познава“. Сървърът сравнява получения списък със списъка от алгоритми, които самият сървър "познава" и избира най-надеждния алгоритъм, след което казва на клиента кой алгоритъм да използва
3) Сървърът изпраща на клиента своя цифров сертификат, подписан от сертифициращия орган и публичния ключ на сървъра.
4) Клиентът може да се свърже със сървъра на доверения CA, който е подписал сертификата на сървъра и да провери дали сертификатът на сървъра е валиден. Но може да не се свърже. Операционната система обикновено вече има инсталирани основни сертификати на сертифициращи органи, спрямо които се проверяват подписите на сървърни сертификати, например браузъри.
5) Сесиен ключ се генерира за защитена връзка. Това става по следния начин:
- Клиентът генерира произволна цифрова последователност
- Клиентът го криптира с публичния ключ на сървъра и изпраща резултата на сървъра
- Сървърът дешифрира получената последователност с помощта на частния ключ
Като се има предвид, че алгоритъмът за криптиране е асиметричен, само сървърът може да дешифрира последователността. При използване на асиметрично криптиране се използват два ключа - частен и публичен. Публично изпратеното съобщение е криптирано, а личното съобщение е декриптирано. Не можете да дешифрирате съобщение с публичния ключ.
6) Така се установява криптирана връзка. Данните, предавани по него, се криптират и декриптират, докато връзката бъде прекратена.
Основен сертификат
Точно по-горе споменах основния сертификат. Това е сертификат на авторизационен център, чийто подпис потвърждава, че подписаният сертификат е този, който принадлежи на съответната услуга. Самият сертификат обикновено съдържа няколко информационни полета, които съдържат информация за името на сървъра, на който е издаден сертификатът, и периода на валидност на този сертификат. Ако сертификатът е изтекъл, той се анулира.
Заявка за подпис (CSR, Заявка за подпис на сертификат)
За да получите подписан сървърен сертификат, трябва да генерирате заявка за подписване (CSR, Certificate Sign Request) и да изпратите тази заявка до център за оторизация, който ще върне подписан сертификат, който е инсталиран директно на сървъра, ще видим как да направете това на практика по-долу. Първо се генерира ключ за криптиране, след което въз основа на този ключ се генерира заявка за подписване, CSR файл.
Клиентски сертификат
Клиентски сертификат може да бъде генериран както за използване от устройство, така и за използване от потребител. Обикновено такива сертификати се използват при двупосочна проверка, когато клиентът проверява, че сървърът наистина е този, за когото се представя, и сървърът прави същото в отговор. Това взаимодействие се нарича двупосочно удостоверяване или взаимно удостоверяване. Двупосочното удостоверяване ви позволява да повишите нивото на сигурност в сравнение с еднопосочното удостоверяване и може също да служи като заместител на удостоверяването чрез потребителско име и парола.
Веригата от действия за генериране на сертификати
Нека видим на практика как работят действията, свързани с генерирането на сертификати от самото начало, а в същото време и на практика.
Първото нещо, което трябва да направите, е да генерирате основен сертификат. Основният сертификат се подписва сам. И тогава други сертификати ще бъдат подписани с този сертификат.
$ openssl genrsa -out root.key 2048 Генериране на RSA частен ключ, модул с дължина 2048 бита ..........+++ ................... ........................+++ e е 65537 (0x10001) $ openssl req -new -key root.key -out root.csr Вие сте ще бъдете помолени да въведете информация, която ще бъде включена във вашата заявка за сертификат. Това, което ще въведете, е това, което се нарича отличително име или DN. Има доста полета, но можешоставете някои празни За някои полета ще има стойност по подразбиране. Ако въведете ".", полето ще остане празно. ----- Име на държавата (2 буквен код) :RU Име на щат или провинция (пълно име) :N/A Име на населено място (напр. град) :Санкт Петербург Име на организация (напр. компания) :Име на организационната единица на моята компания (напр. раздел) : Общо име на ИТ услуга (напр. FQDN на сървъра или ВАШЕТО име) : Имейл адрес на основния сертификат на моята фирма : [имейл защитен]Моля, въведете следните „допълнителни“ атрибути, които да бъдат изпратени с вашата заявка за сертификат. Парола за предизвикателство: Незадължително име на фирма: My Company $ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem Подпис ok subject=/C=RU/ST=N/A/L=Санкт-Петербург/O=Моята компания/OU=ИТ услуга/CN=Основен сертификат на моята компания/ [имейл защитен]Получаване на личен ключ
Така първо генерирахме частен ключ, след това заявка за подпис, след което подписахме собствената си заявка с нашия ключ и получихме собствен цифров сертификат, издаден за 10 години. Паролата (парола за предизвикателство) може да бъде пропусната при генериране на сертификат.
Частният ключ ТРЯБВА да се съхранява на сигурно място, с него можете да подпишете всеки сертификат от ваше име. И полученият основен сертификат може да се използва за идентифициране, че сертификатът, например, на сървъра е подписан от нас, а не от някой друг. Това са действията, които центровете за оторизация извършват, когато генерират собствени сертификати. След като създадете основния сертификат, можете да започнете да генерирате сървърния сертификат.
Вижте информацията за сертификата
Съдържанието на сертификата може да се види по следния начин:
$ openssl x509 -noout -issuer -enddate -in root.pem issuer= /C=RU/ST=N/A/L=Санкт-Петербург/O=Моята компания/OU=ИТ услуга/CN=Основен сертификат на моята компания/ [имейл защитен] notAfter=22 януари 11:49:41 2025 GMT
Виждаме кой е издал това удостоверение и кога изтича.
Сървърен сертификат
За да подпишем сертификат за сървър, трябва да направим следното:
1) Генерирайте ключ
2) Генерирайте заявка за подпис
3) Изпратете CSR файла до центъра за оторизация или го подпишете сами
Сертификатът на сървъра може да включва веригата от сертификати, подписали сертификата на сървъра, но може също да се съхранява в отделен файл. По принцип всичко изглежда почти същото като при генериране на основен сертификат
$ openssl genrsa -out server.key 2048 Генериране на RSA частен ключ, модул с дължина 2048 бита ................................ ................................................. . +++ ..................++ e е 65537 (0x10001) $ openssl req -new -key server.key - out server.csr Вие сте на път да бъдете поиска да въведете информация, която ще бъде включена във вашата заявка за сертификат. Това, което ще въведете, е това, което се нарича отличително име или DN. Има доста полета, но можете да оставите някои празни За някои полета ще има стойност по подразбиране. Ако въведете ".", полето ще остане празно. ----- Име на държавата (2 буквен код) :RU Име на щат или провинция (пълно име) :N/A Име на населено място (напр. град) :Санкт Петербург Име на организация (напр. компания) :Име на организационната единица на моята компания (напр. раздел) : Общо име на ИТ услуга (напр. FQDN на сървъра или ВАШЕТО име) : www.mycompany.com Имейл адрес : [имейл защитен]Моля, въведете следните „допълнителни“ атрибути, които да бъдат изпратени с вашата заявка за сертификат Парола за предизвикателство: Незадължително име на фирма: $ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out сървър. pem -days 365 Подпис ok subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/ [имейл защитен]Получаване на CA Private Key $ openssl x509 -noout -issuer -subject -enddate -in server.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN =Основен сертификат на моята компания/ [имейл защитен] subject= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/ [имейл защитен] notAfter=25 януари 12:22:32 2016 GMT
Така сертификатът на сървъра е подписан и ще знаем коя организация е издала този сертификат. След подписване готовият сертификат може да се използва по предназначение, например инсталиран на уеб сървър.
Инсталиране на SSL/TLS сертификат на сървър с nginx
За да инсталирате SSL / TLS сертификат на уеб сървъра nginx, трябва да следвате няколко прости стъпки:
1) Копирайте .key и .pem файловете на сървъра. В различни операционни системи сертификатите и ключовете могат да се съхраняват в различни директории. В Debian, например, това е /etc/ssl/certs за сертификати и /etc/ssl/private за ключове. В CentOS това са /etc/pki/tls/certs и /etc/pki/tls/private
2) Предписване необходими настройкив конфигурационен файлза домакина. Ето как трябва да изглежда (това е само пример):
Сървър (слушайте 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 не се препоръчва!!! # Просто е тук например 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/ =404; ) )
3) Рестартирайте nginx
4) Отидете на сървъра на порт 443 на браузъра - https://www.mycompany.com и проверете неговата производителност.
Инсталиране на SSL/TLS сертификат на Apache сървър
Инсталирането на SSL/TLS сертификат на Apache изглежда приблизително по същия начин.
1) Копирайте файловете с ключ и сертификат на сървъра в съответните директории
2) Активирайте ssl модула за Apache с командата "a2enmod ssl", ако вече не е активиран
3) Създайте виртуален хост, който ще слуша на порт 443. Конфигурацията ще изглежда така:
В същото време трябва да се направи още нещо. Намерете във файла httpd.conf, или apache2.conf, или ports.conf, в зависимост от системата, следния раздел от конфигурацията:
Ако няма такова условие, то трябва да се добави към конфигурацията. И още нещо: трябва да добавите ред
ИмеVirtualHost *:443
Този ред може да бъде в httpd.conf, apache2.conf или ports.conf
4) Рестартирайте уеб сървъра на Apache
Създайте клиентски сертификат
Сертификатът на клиента се създава почти по същия начин като сертификата на сървъра.
$ openssl genrsa -out client.key 2048 Генериране на RSA частен ключ, модул с дължина 2048 бита ........................+++ ..... .............................................+++ e е 65537 (0x10001) $ openssl req -new -key client.key -out client.csr Това, което ще въведете, е това, което се нарича отличително име или DN. Има доста полета, но можете да оставите някои празни За някои полета ще има стойност по подразбиране. Ако въведете ".", полето ще остане празно. ----- Име на държавата (код от 2 букви) :RU Име на щат или провинция (пълно име) :Име на населеното място в Санкт Петербург (напр. град) :^C [имейл защитен]:~/Temp/certs/CA$ openssl req -new -key client.key -out client.csr Ще бъдете помолени да въведете информация, която ще бъде включена в заявката ви за сертификат. Това, което ще въведете, е това, което се нарича отличително име или DN. Има доста полета, но можете да оставите някои празни За някои полета ще има стойност по подразбиране. Ако въведете ".", полето ще остане празно. ----- Име на държавата (код от 2 букви) :RU Име на щат или провинция (пълно име) :N/A Име на местност (напр. град) :Санкт-Петербург Име на организация (напр. фирма) :Име на организационната единица на моята компания (напр. раздел) :Инженерно общо име (напр. FQDN на сървъра или ВАШЕТО име) :Иван Иванов имейл адрес : [имейл защитен]Моля, въведете следните „допълнителни“ атрибути, които да бъдат изпратени с вашата заявка за сертификат Парола за предизвикателство: Незадължително име на фирма: $ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client. pem -days 365 Подпис ok subject=/C=RU/ST=N/A/L=Saint-Petrersburg/O=Моята компания/OU=Engineering/CN=Ivan Ivanov/ [имейл защитен]Получаване на CA Private Key $ openssl x509 -noout -issuer -subject -enddate -in client.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN =Основен сертификат на моята компания/ [имейл защитен] subject= /C=RU/ST=N/A/L=Saint-Petrersburg/O=Моята фирма/OU=Инженеринг/CN=Иван Иванов/ [имейл защитен] notAfter=25 януари 13:17:15 2016 GMT
Ако имате нужда от клиентски сертификат във формат PKCS12, създайте го:
$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12 Въведете парола за експортиране: Проверка - Въведете парола за експортиране:
Сега можем да използваме клиентския сертификат за работа с нашия сървър.
Конфигуриране на nginx за използване на клиентски сертификати
Най-често, както казах, се използва еднопосочна автентификация, обикновено се проверява само сертификатът на сървъра. Нека видим как да накараме уеб сървъра nginx да валидира клиентския сертификат. Необходимо е да добавите опции за работа с клиентски сертификати към сървърния раздел:
# Основен сертификат(и), подписан от клиент ssl_client_certificate /etc/nginx/certs/clientroot.pem; # Възможни опции: на | изключен | по избор | optional_no_ca ssl_verify_client по избор; # Дълбочина на проверка на веригата от сертификати, подписани от клиента ssl_verify_depth 2;
След това трябва да рестартирате настройките или целия сървър и можете да проверите работата.
Конфигуриране на Apache за използване на клиентски сертификати
Apache също се конфигурира чрез добавяне допълнителни опциикъм раздела за виртуален хост:
# Директория, съдържаща основни сертификати за проверка на SSLCARevocationPath клиенти /etc/apache2/ssl.crl/ # или файл, съдържащ SSLCARevocationFile сертификати /etc/apache2/ssl.crl/ca-bundle.crl # Опция за проверка на клиента. Опциите са: # няма, по избор, изисква и optional_no_ca SSLVerifyClient изисква # Дълбочина на търсене на веригата на подписа. По подразбиране 1 SSLVerifyDepth 2
Както можете да видите, опциите са почти същите като за nginx, тъй като процесът на проверка е организиран по еднакъв начин.
Слушане на информация за сертификат с openssl
За да проверите дали сървърът взаимодейства с клиентските сертификати, можете да проверите дали връзката е установена чрез TLS/SSL.
От страната на сървъра започваме да слушаме порта с помощта на openssl:
Openssl s_server -accept 443 -cert server.pem -key server.key -state
От страна на клиента, ние осъществяваме достъп до сървъра, например, с culr:
Curl -k https://127.0.0.1:443
В конзолата от страната на сървъра можете да наблюдавате процеса на обмен на информация между сървъра и клиента.
Можете също да използвате опциите -verify [дълбочина на проверка] и -Verify [дълбочина на проверка]. Опцията с малки букви иска от клиента сертификат, но не се изисква да предостави такъв. С главни букви - Ако сертификатът не е предоставен, ще възникне грешка. Нека започнем да слушаме от страната на сървъра така:
Openssl s_server -accept 443 -cert server.pem -key server.key -state -Verify 3
От страна на сървъра грешката изглежда така:
140203927217808:грешка:140890C7:SSL процедури:SSL3_GET_CLIENT_CERTIFICATE:партньорът не върна сертификат:s3_srvr.c:3287:
От страна на клиента така:
Curl: (35) грешка: 14094410: SSL процедури: SSL3_READ_BYTES: sslv3 неуспешно ръкостискане на предупреждение
Добавете сертификат от страна на клиента и Име на домейн(за проверка можете да въведете името на хоста за адреса 127.0.0.1 във файла /etc/hosts):
Curl https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key client.key
Сега връзката ще бъде успешна и можете да инсталирате сървърния сертификат на уеб сървъра, да дадете клиентския сертификат на клиента и да работите с него.
Безопасност
Когато използвате SSL/TLS, един от основните методи е методът MITM (Man In The Middle). Този метод разчита на използването на сървърен сертификат и ключ на някакъв възел, който ще слуша трафика и ще дешифрира информацията, обменяна между сървъра и клиента. За да организирате слушане, можете да използвате например програмата sslsniff. Следователно обикновено е желателно да съхранявате главния сертификат и ключа на машина, която не е свързана към мрежата, да донесете заявки за подписване на флаш устройство за подписване, да ги подпишете и да ги вземете по същия начин. И, разбира се, правете резервни копия.
Като цяло, това е начинът, по който се използват цифровите сертификати и протоколите TLS и SSL. Ако имате въпроси / допълнения, пишете в коментарите.
Този запис беше публикуван в етикет , от автора.Навигация на публикации
: 29 коментара
cl-service.com
Клиентът сам генерира CSR при поръчка на сертификат, където клиентът също така решава да съхранява частния ключ, ние не се нуждаем от частен ключ за издаване на сертификат и клиентът не ни го прехвърля по никакъв начин. Естествено, ако това се случи на обикновен виртуален, тогава администраторите с root достъпсървърът има достъп до ключовете, които се съхраняват там.
- Доброжелател.
Темата за циците не се разкрива, тъй като описаната PKI технология няма нищо общо със заглавието на темата. Дори само с причина бих дал линкове към rfc.
P.S. Имаше виц за куче и бълха. - Доброжелател.
Никога не съм искал да те обидя. Търсих информация за разликата между SSl и TLS на практика и вашият линк в Google беше първият. Бях заинтригуван от заглавието на темата. Всичко е супер, продължавай все така!
- DrAibolit
Благодаря за смислените обяснения относно дигиталното удостоверяване. Нов съм в това =)
Надявам се, че можете да изясните следващия въпрос.
Тъй като темата за измамите е много развита в интернет индустрията, бих искал да се науча как да определям „въшките“ на сайтовете, които посещавам сам (особено там, където има пари и плащания, инвестиции и т.н.) и да определям, въз основа на това степента на моето доверие (често трябва да се регистрирам, да оставя лична информация, да правя покупки, сделки, инвестиции). Ако разбирам правилно, наличието на тази заверка ви позволява да направите такава оценка. Е, от друга страна, получаването му не е проблем и дори безплатно.
Как или с помощта на коя програма можете да определите наличието на цифров сертификат за определен сайт? и за предпочитане неговата категория, която се присвоява, когато специален орган издава SSL DV (издаването на сертификат се извършва само с проверка на домейна), SSL OV (с проверка на организацията), EV (с разширена проверка на юридическото лице). Най-вероятно измамни сайтове последен вариантсертификат няма да се използва.
Ще се радвам, ако ми кажете повече начини за определяне на надеждността на сайтовете))- мноринАвтор на публикацията
някои конкретна програмаза тези цели все още не съм се срещал, но мога да дам няколко съвета по този въпрос.
Можете да използвате например Chromium или Google Chrome. Да вземем за пример сайта https://www.thawte.com/ – фирма, която всъщност се занимава с цифрови сертификати.
AT адресна лентаще бъде изписано името на фирмата и зелен катинар. Това означава, че организацията е проверена, тя е поне SSL OV.
Ако щракнете върху ключалката и в падащото поле „Подробности“ и след това „Преглед на сертификата“, можете да видите информация за сертификата. За Thawte сертификатът е подписан със следния сертификат: "thawte Extended Validation SHA256 SSL CA", а сертификатът за click.alfabank.ru също е подписан от Thawte, но с различен сертификат. Това са "thawte EV SSL CA - G3", тоест те също са преминали Extended Validation.
Нещо като това.
- мноринАвтор на публикацията
- Руслан
Раздел "Принципът на работа на SSL и TLS", "Клиентът генерира произволна цифрова последователност".
Бях сигурен, че клиентът генерира частна сесия и съответно публичен ключ (който явно си нарекъл "цифрова последователност"). публичен ключсе предава на сървъра и сървърът криптира пакетите към клиента с публичния ключ на сесията на клиента.
Моля, пояснете.
- Новак
Статията е много полезна! Даже има практически примери =) Само едно нещо не разбрах - каква е разликата между root сертификат и сървърен? или е едно и също?
- Виталий
Здравейте.
Хостерът предложи услуга - SSL за виртуални сървъри. Възползвали са се. Оказа се, че за трето ниво, т.е. http://www.site.ru сертификатът е невалиден, само за site.ru. Освен това посетителите упорито се хвърлят към https протокола, няма значение дали отиват на site.ru или http://www.site.ru. Разбира се, във втория случай браузърът започва да ругае сърцераздирателно и посетителят никога не стига до сайта.
И за тези, които стигнаха до сайта, сайтът започна да изглежда крив, част от менюто изчезна, някои от снимките в резултатите от търсенето вече не се показват от някои компоненти.
Настройката на работната станция E-budget става на няколко етапа, не са сложни, но изискват внимание. Ние правим всичко според инструкциите за настройка на електронен бюджет. Кратко и по същество...
Електронна настройка на бюджета на работното място
Електронен бюджет на основен сертификат
Създайте папка с ключове в Моите документи, за да съхранявате изтеглените сертификати в тази папка:
На сайта http://roskazna.ru/gis/udostoveryayushhij-centr/kornevye-sertifikaty/ в менюто ГИС -> Сертифициращ орган -> Основни сертификати, трябва да изтеглите " Основен сертификат (квалифициран)" (вижте фигурата), или ако сте получили флашка със сертификати, копирайте ги от папката Сертификати.
Сертификат Континент TLS VPN
Вторият сертификат, който трябва да изтеглите, е сертификатът TLS VPN Continent, но не можах да го намеря в новия уебсайт на roskazna, затова поставих връзка от моя уебсайт. Изтеглете Continent TLS VPN сертификата в папката с ключове, ще ни трябва по-късно, когато конфигурираме клиентската програма Continent TLS.
Инсталирайте изтегления Root сертификат (квалифициран), за да работите с електронния бюджет.
В менюто СТАРТ -> Всички програми -> CRYPTO-PRO -> стартирайте програмата Сертификати.
Отидете до елемента Сертификати, както е показано на фигурата по-долу:
Отидете в менюто Действие - Всички задачи - Импортиране, ще се появи прозорецът на съветника за импортиране на сертификати - Напред - Общ преглед - Намерете изтегления Основен сертификат (квалифициран)в нашия случай той се намира в My Documents в папката key
Ако всичко е направено правилно, тогава основният сертификат на CA на Федералната хазна ще се появи в папката със сертификати.
Инсталация "Continent TLS Client" за работа с електронен бюджет
Continent_tls_client_1.0.920.0 може да се намери в интернет.
Разопаковайте изтегления архив, отидете в папката на CD и стартирайте ContinentTLSSetup.exe
От елемента щракнете върху Continent TLS Client KC2 и стартирайте инсталацията.
Приемаме условията
В целевата папка оставете по подразбиране
В прозореца на конфигуратора за стартиране поставете отметка в квадратчето Изпълни конфигуратора след завършване на инсталацията.
По време на инсталацията ще се появи прозорецът за настройки на услугата:
Адрес - посочете lk.budget.gov.ru
Сертификат - изберете втория сертификат, изтеглен по-рано в папката с ключове.
Щракнете върху OK и завършете инсталацията, Готово.
Поискано рестартиране операционна системаотговаряме с Не.
Инсталиране на инструмента за електронен подпис "Jinn-Client"
Можете да изтеглите програмата Jinn-Client от Интернет.
Отидете в папката Jinn-client - CD, стартирайте setup.exe
Щракнете от списъка Jinn-Client, инсталацията на програмата започва
Игнорирайте грешката, щракнете върху Продължи, Напред, приемете споразумението и щракнете върху Напред.
Въведете издадения лицензен ключ
Задайте програмата по подразбиране, щракнете върху Напред
Завършваме инсталацията, отговаряме на въпроса за рестартиране на операционната система №
Инсталиране на модул за работа с електронен подпис "Cubesign"
Ако имате нужда от архив с програмата, пишете в коментарите.
Стартирайте инсталационния файл cubesign.msi
Настройка на браузъра Mozilla Firefox за работа с Електронния бюджет.
1. Отворете менюто "Инструменти" и изберете "Настройки".
2. Отидете в раздела „Разширени“ в раздела „Мрежа“.
3. В секцията с настройки „Връзка“ щракнете върху бутона „Конфигуриране…“.
4. В прозореца с параметри на връзката, който се отваря, задайте стойността
„Ръчно конфигуриране на прокси услугата.“
5. Задайте стойностите на полетата за HTTP прокси: 127.0.0.1; Порт: 8080.
6. Натиснете бутона OK.
7. В прозореца "Настройки" щракнете върху бутона "ОК".
Влезте в личния акаунт на Електронния бюджет
Отваря се прозорец с избор на удостоверение за влизане в личната сметка на Електронния бюджет.
Изберете сертификат за влизане Лична зонаЕ-бюджет, ако има парола за частната част на сертификата, напишете и натиснете OK, след което ще се отвори Личен акаунт на Е-бюджет.
