Прошлое и настоящее SSL-сертификатов / Хабр

Что такое центры сертификации (ca)?

Это организация, которая обладает правом выдачи цифровых сертификатов. Она производит проверку данных, содержащихся в CSR, перед выдачей сертификата. В самых простых сертификатах проверяется только соотвествие доменного имени, в самых дорогих производится целый ряд проверок самой организации, которая запрашивает сертификат. Об этом мы поговорим ниже.

Так вот, разница между самоподписными бесплатным и платными сертификатами, выданными центром сертификации как раз и заключается в том, что данные в сертификате проверены центром сертификации и при использовании такого сертификата на сайте ваш посетитель никогда не увидит огромную ошибку на весь экран.

Говоря в общем, SSL сертификаты содержат и отображают (как минимум одно из) ваше доменное имя, ваше название организации, ваш адрес, город и страницу. Также сертификат всегда имеет дату окончания и данные о центре сертификации, ответственного за выпуск сертификата.

Браузер подключается к защищенному сайту, получает от него SSL сертификат и делает ряд проверок: он не просрочен ли сертификат, потом он проверяет, выпущен ли сертификат известным ему центром сертификации (CA) используется ли сертификат на сайте, для которого он был выпущен.

Если один из этих параметров не проходит проверку, браузер отображает предупреждение посетителю, чтобы уведомить, что этот сайт не использует безопастное соединение SSL. Он предлагает покинуть сайт или продолжить просмотр, но с большой осторожностью.

Центров сертификации существует достаточно много, вот перечень самых популярных:Comodo — работает с 1998 штабквартира в Jersey City, New Jersey, США.Geotrust — основан в 2001, в 2006 продан Verisign, штабквартира Mountain View, California, СШАSymantec — бывший Verisign в состав которого входит и Geotrust.

Как видим самый крупный игрок на рынке SSL сертификатов это Symantec, который владеет тремя крупнейшими центрами сертификации — Thawte, Verisgin и Geotrust.

Что проверяется в таких случаях?

У разных центров сертификации проверка несколько отличается, поэтому приведу общий список пунктов, которые могут быть проверены или запрошены:

1. Наличие организации в международных желтых страницах — проверяется не всеми центрами сертифации
2. Наличие в whois домена названия вашей организации — а вот это уже проверят обязательно, и если такое название там не указано от вас скорей всего затребуют гарантийное письмо, в котором нужно указать, что домен действительно принадлежит организации, иногда могут затребовать подтверждение от регистратора
3. Свидетельство о государственной регистрации — требуют все реже, чаще сейчас производится проверка через специальные компании, которые производят проверку существования организации по своим каналам. Например для Украины вас могут проверить по базе ЕДРПОУ
4. Счет от телефонной компании, в которой содержится название вашей организации и ваш номер телефона, указанный в заказе — таким образом проверяется валидность вашего телефона. Требуют все реже.
5. Проверочный звонок — все чаще правильность телефона проверяют осуществляя звонок, на номер телефона, указанный вами в заказе. При звонке спросят сотрудника, указанного в административном контакте. Не у всех центров сертификации есть русскоговорящие сотрудники, поэтому предупредите человека, который отвечает на телефон, что возможен звонок от англоязычной компании.

Начальные настройки

Сперва заполним файл /root/.rnd, который используется как источник начальных случайных значений в генераторе псевдослучайных чисел OpenSSL. Суть использования этого файла описана на сайте OpenSSL. Нам надо заполнить свой файл случайными данными, как вариант — скопировав из /dev/urandom 32768 байт в файл .rnd таким образом:

Далее создадим сертификат для CA:

root@shpc:/opt/simple_CA# openssl req -newkey rsa:4096-keyform PEM -keyout ca.key -x509-days3650-outform PEM -out ca.cer

Опции для сертификата берутся из файла /etc/ssl/openssl.cnf. Сам файл довольно большой, мы не будем приводить здесь его содержимое. В реальности стоит создать свой конфигурационный файл с необходимыми опциями и блоками — и использовать его для генерации сертификатов.

На выходе получим два файла: ключ и сертификат. 

Оба файла надо беречь. Если они попадут к злоумышленнику, он сможет использовать их для генерации сертификатов. Посмотреть сертификат можно при помощи этой команды (вывод обрезан для краткости):

root@shpc:/opt/simple_CA# openssl x509 -text-noout-in ca.cer

Далее на основе полученного сертификата (напомним, что это сертификат корневого CA) можно сгенерировать сертификат для сервера. Вначале генерируем закрытый ключ для сервера:

root@shpc:/opt/simple_CA# openssl genrsa -out server.key 4096

Теперь используем этот ключ для генерации запроса на выдачу сертификата (CSR):

root@shpc:/opt/simple_CA# openssl req -new-key server.key -out server.req -sha256

Отметим, что данные, которые вы вводите в поля, должны совпадать со значениями в тех полях, что указывались при создании сертификата корневого сервера. Теперь возьмём корневой сертификат CA и запрос — и сгенерируем на их основе сертификат для сервера:

root@shpc:/opt/simple_CA# openssl x509 -req-in server.req -CA ca.cer -CAkey ca.key -set_serial 100-extensions server -days1460-outform PEM -out server.cer -sha256

Должно получиться 5 файлов.

Файл server.req можно удалить — а при необходимости создать заново. Теперь надо перенастроить веб-сервер для работы с сертификатами.

Что такое ssl сертификат для сайта, почты [айти бубен]

# cp /etc/ssl/openssl.cnf /etc/ssl/openssl.cnf.orig
# nano openssl.cnf
...
[ CA_default ]

dir             = ./demoCA
# cacert.pem- Это открытый ключ центра сертификации. Он должен находиться в корневых хранилищах ваших хостов,
# чтобы они могли проверить родпись в открытом сертификате (например, Postfix).
certificate     = $dir/cacert.pem
# cakey.pem - это секретный ключ центра сертификации. Он должен быть хорошо защищен,
# доступ к нему на чтение и запись должен иметь только администратор центра сертификации.
private_key     = $dir/private/cakey.pem
# Время жизни сертификата (по умолчанию 1 год)
default_days    = 1095
[ req ]
# длина RSA ключа (по умолчанию 1024 bit). Длину ключа можете настроить по своему усмотрению.
default_bits            = 1024
[ req_distinguished_name ]
countryName_default             = UA
0.organizationName_default      = Example INC
stateOrProvinceName_default     = Example
organizationalUnitName_default  = Example

# В подавляющем большинстве случае должно соответствовать полному доменному имени хоста.
# Common Name (eg, your name or your server's hostname) []:OpenVPN-CA

commonName                      = Common Name (eg, YOUR name)
commonName_default              = mail.example.com
...
# /usr/lib/ssl/misc/CA.pl -newca

# mkdir /etc/postfix/certs
# cd /etc/postfix/certs
# openssl req -new -nodes -x509 -out smtpd.pem -keyout smtpd.pem -days 3650
# chmod 644 smtpd.pem

smtp_use_tls = yes
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_tls_auth_only = yes
smtp_tls_note_starttls_offer = yes
smtpd_tls_key_file = /etc/postfix/certs/smtpd.pem              
smtpd_tls_cert_file = /etc/postfix/certs/smtpd.pem              
smtpd_tls_CAfile = /etc/postfix/certs/smtpd.pem
smtpd_tls_CApath = /etc/ssl/certs
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

smtps inet n - n - - smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes

Firefox

Поскольку Firefox принадлежит Mozilla, то этот веб браузер, конечно, также использует Mozilla Network Security Services (NSS).

Стандартными расположениями папок с базами данных NSS являются:

• ~/.pki/nssdb (на уровне пользователей)
• /etc/pki/nssdb (на общесистемном уровне, может отсутствовать)

Firefox НЕ использует ни одно из этих стандартных расположений, база данных хранится в профиле пользователя, который имеет общий вид ~/.mozilla/firefox/СЛУЧАЙНЫЕ-БУКВЫ-ЦИФРЫ.default/cert9.db, например, ~/.mozilla/firefox/3k0r4loh.default/cert9.db.

Посмотреть корневые сертификаты CA которые использует Firefox в Linux можно следующей командой:

certutil -L -d ~/.mozilla/firefox/*.default/

У Firefox-esr это папка:

certutil -L -d ~/.mozilla/firefox/*.default-esr/

Также вы можете просмотреть корневые CA сертификаты в настройках браузера:

Приватность и Защита → Сертификаты → Просмотр сертификатов → Центры сертификации:

Google chrome / chromium

Как уже было сказано, при работе на Linux, Google Chrome использует библиотеку Mozilla Network Security Services (NSS) для выполнения верификации сертификатов.

Корневые CA сертификаты, которые добавил пользователь, хранятся в файле ~/.pki/nssdb/cert9.db, их можно просмотреть командой:

certutil -L -d ~/.pki/nssdb

Поскольку Chrome не может удалить сертификаты из хранилища NSS, то если вы отключите некоторые из них в настройках веб браузера (Privacy and security → Manage certificates → Authorities), то в том же файле, где хранятся добавленные пользователем корневые CA сертификаты, будут сохранены изменения о полномочиях отключённого сертификата:

Используемые в Google Chrome / Chromium корневые CA сертификаты в Linux можно посмотреть следующим причудливым способом:

1. Найдите расположение файла libnssckbi.so (как было сказано в предыдущем разделе, в нём NSS хранит доверенные корневые сертификаты):

locate libnssckbi.so

Примеры расположений этого файла:

• /usr/lib/libnssckbi.so
• /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so

2. Теперь выполните команду вида:

ln -s /ПУТЬ/ДО/libnssckbi.so ~/.pki/nssdb

Например:

ln -s /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so ~/.pki/nssdb

2. Затем запустите команду:

certutil -L -d sql:$HOME/.pki/nssdb/ -h 'Builtin Object Token'

Вы увидите доверенные корневые сертификаты, которые использует Google Chrome в Linux.

Также вы можете просмотреть корневые CA сертификаты в настройках браузера:

Конфиденциальность и безопасность (выбрать «Ещё») → Настроить сертификаты → Центры сертификации, на английском это Privacy and security → Manage certificates → Authorities.

Mozilla network security services (nss)

Network Security Services (NSS) это набор библиотек, разработанных для поддержки кросс-платформенной разработки защищенных клиентских и серверных приложений. Приложения построенные с использование NSS могут использовать SSL v2 и v3, TLS, PKCS#5, PKCS#7, PKCS#11, PKCS#12, S/MIME, сертификаты X.509 v3 и другие стандарты обеспечения безопасности.

В отличие от OpenSSL, NSS использует файлы базы данных в качестве хранилища сертификатов.

NSS начинается с жёстко закодированного списка доверенных сертификатов CA внутри файла libnssckbi.so. Этот список можно просмотреть из любого приложения, использующего NSS, способного отображать (и манипулировать) хранилищем доверенных сертификатов, например, Chrome-совместимые или Firefox-совместимые браузеры.

Некоторые приложения, использующие библиотеку NSS, используют хранилище сертификатов, отличное от рекомендованного. Собственный Firefox от Mozilla является ярким примером этого.

В вашем дистрибутиве скорее всего уже установлен пакет NSS, в некоторых дистрибутивах он называется libnss3 (Debian и производные) в некоторых — nss (Arch Linux, Gentoo и производные).

Если вы хотите просматривать и изменять хранилища сертификатов NSS, то понадобиться утилита certutil. В Arch Linux эта утилита входит в пакет nss и, следовательно, предустановлена в Arch Linux. А в Debian и производные установка делается так:

sudo apt install libnss3-tools

Где получить ssl сертификат бесплатно

Нашла для вас пять способов получить SSl сертификат без затрат.

Эта некоммерческая организация выдает бесплатные SSL DV сертификаты со сроком жизни три месяца. Можно получить wildcard-сертификат.

Еще одна некоммерческая организация, которая также выдает 90-дневные DV сертификаты. Отличается от Let’s Encrypt совместимостью: как заявляет компания, их сертификаты поддерживаются на 99,99% устройств. Нет опции wildcard.

У этого сервиса есть бесплатный тариф — DV сертификат на 90 дней. Как и Free SSL, заявляют о 99,99% совместимости с серверами, браузерами и устройствами, однако на бесплатном тарифе не поддерживается wildcard.

Этот сервис защищает сайты от DDoS-атак — моментов, когда злоумышленники пытаются перегрузить ваш сайт множеством одновременных запросов, а также ускоряет загрузку. Бесплатный SSL сертификат — приятное дополнение к сервису. CloudFlare предлагает получить SSL сертификат бесплатно и на неопределенный срок на базовом тарифе, который предназначен для личных некоммерческих сайтов.

У бесплатного SSL от CloudFlare есть одно «но». Загрузка сайта ускоряется благодаря тому, что сервис кеширует ваш сайт на свои серверы и контент попадает пользователю с них. Общение происходит по цепочке «пользователь — серверы CloudFlare — ваш сервер», и SSL зашифрует только первую связь.

Злоупотребление доверием

Главное слабое звено любых схем безопасности — люди. PKI не исключение. В случае, если интересы государства или иных силовых структур превозмогают ожидания пользователя, становится возможным использование т. н. SSL-прокси (вариант атаки

), тем самым исчезает уверенность в том, что обмен данными остаётся конфиденциальным.

Два известных примера, иллюстрирующих возможные опасности использования схем доверия, фундаментальных для этой инфраструктуры. Голландский CA DigiNotar был закрыт после ряда инцидентов, начавшихся 10 июля 2021 года, когда злоумышленниками были получены подложные мультидоменные сертификаты (вначале использовавшиеся для маскировки под сервисы Google, несколькими днями позже к списку добавились домены других популярных интернет-сервисов).

Другой пример — инцидент с CA TrustWave, который выпустил в 2021 году подчинённый (дочерний) CA-сертификат, пригодный для фальсификации любого сертификата в ситуации, когда установлен корневой сертификат TrustWave. Хотя компания и признала сам факт такой выдачи, а также отметила, что были приняты все меры, чтобы подобной фальсификации не могло произойти, их корневой сертификат был отозван большинством ОС и программных продуктов.

В случае подобных инцидентов главное — оперативность отзыва корневых сертификатов. В этом заключается один из недостатков SSL-сертификатов: нет механизма, гарантирующего быстрый отзыв того или иного сертификата. По ряду причин далеко не все ОС и программные продукты всегда используют последние, наиболее актуальные списки доверенных корневых сертификатов.

Также следует отметить, что производители некоторых ОС и программных продуктов (пример: Microsoft в случае с Windows) могут дополнять список доверенных сертификатов в хранилище ОС без явного уведомления о том пользователя.

Как добавить корневой сертификат в доверенные в windows на уровне системы

1. Мастер импорта сертификатов

Если сертификат имеет расширение .crt, то его достаточно запустить двойным кликом:

В открывшемся окне нажмите кнопку «Установить сертификат»:

Выберите один из вариантов:

• «Текущий пользователь» – сертификат будет иметь эффект только для одного пользователя
• «Локальный компьютер» – сертификат будет иметь эффект для всех пользователей данного компьютера

Выберите «Пометить все сертификаты в следующие хранилища»:

Нажмите кнопку «Обзор» и выберите «Доверенные корневые центры сертификации»:

Нажмите «Далее»:

Нажмите «Готово»:

Сообщение об успешном импорте:

Теперь сертификат будет доступен в Менеджере Сертификатов:

2. Добавление root CA сертификата в Менеджере Сертификатов

Чтобы открыть Менеджер Сертификатов нажмите Win r, введите в открывшееся поле и нажмите Enter:

certmgr.msc

Кликните правой кнопкой мыши по пункту «Доверенные корневые центры сертификации», выберите пункт «Все задачи» → «Импорт»:

Нажмите «Далее»:

Укажите папку и имя файла:

Нажмите «Далее»:

Всё готово:

Подтвердите:

Теперь действительно всё готово:

Только что импортированный сертификат в Менеджере Сертификатов:

Криптография с открытым ключом

До 1970 года использовалась практически только криптография с симметричным ключом. Очевидное слабое звено таких криптографических схем — необходимость передачи ключа всем участвующим в защищённом обмене сторонам.

Изобретателем методики шифрования с открытым ключом считается Ральф Меркл. Если в случае симметричного шифрования один и тот же ключ (фиксированный набор данных произвольной длины) используется как для зашифровки, так и для расшифровки, то в подходе с открытым ключом есть два ключа: секретный, который надлежит знать только владельцу, и открытый — доступный всем желающим. Только владелец секретного ключа может дешифровать предназначенный для него шифротекст или подписать своим ключом любой набор данных (файл). В то же время любой владелец открытого ключа может отправить (зашифровать) текст владельцу секретного ключа, или проверить подпись того или иного файла.

Теоретически система шифрования с открытым ключом опирается на то, что разложение на простые множители достаточно больших чисел потребует много времени и/или значительных вычислительных мощностей. Это лежит в основе подбора секретного ключа по известному открытому. Всё упирается в вычислительные ресурсы и время. Сегодня принято считать, что использование ключей длиной 2048 бит не позволяет в общем случае подобрать секретный ключ за разумный срок в пределах вычислительной мощности, доступной в настоящее время. Рекомендуем ознакомиться с подробностями того, как длина ключа влияет на вероятность вскрытия шифра в случае симметричного шифрования и шифрования с открытым ключом. Упрощая: открытый ключ длиной 1024 бит по уровню требуемой вычислительной мощности примерно так же стоек, как и 80-битный симметричный ключ.

В случае использования RSA (сокращение по фамилиям изобретателей этой криптосистемы, Rivest-Shamir-Adleman) скорость шифрования примерно пропорциональна квадрату длины ключа, а расшифровки — кубу. Современные программы криптографии оперируют в общем случае с ключами вплоть до 4096 бит.

Даже 2048 бит во многих случаях достаточно, чтобы исключить возможность взлома за разумное время. Использование более длинных ключей может серьёзно повысить затраты времени и вычислительной мощности, а также размер полученного шифротекста, при этом не добавляя существенных различий во времени, необходимом для дешифровки. Что сто лет, что миллион — на практике в большинстве случаев разницы нет.

Важный момент: если удалось сохранить и шифротекст, и актуальный для того момента открытый ключ, то рано или поздно (теоретически) текст удастся прочесть. Это следует иметь в виду, если информация предназначена для длительного хранения без доступа к ней третьих лиц.

Настройка apache 2 для использования сертификатов

Переходим в каталог /etc/apache2:

root@shpc:/mnt# cd/etc/apache2/

Создаём каталог для хранения сертификатов:

root@shpc:/etc/apache2# mkdir ssl

Включаем модуль SSL для веб-сервера. Тестирование проводилось на ОС Ubuntu Linux, поэтому модуль достаточно просто включить:

a2enmod headers

Перезапускаем веб-сервер:

root@shpc:/etc/apache2# systemctl restart apache2

Аналогично нужно включить поддержку заголовков: 

Теперь создадим конфигурационный файл для модуля SSL. Пример содержимого для него можно взять на Syslink.pl. Команды такие:

root@shpc:/mnt# cd /etc/apache2/conf-available
root@shpc:/etc/apache2/conf-available# nano ssl-params.conf

Сам файл будет содержать следующие параметры (чтобы было проще работать, мы отключили заголовки Strict-Transport-Securrity, X-Frame-Options и X-Content-Type-Options):

Далее созданный конфиг надо активировать:

root@shpc:/etc/apache2/conf-available# a2enconf ssl-params

Теперь переходим в каталог /etc/apache2/sites-available:

root@shpc:/etc/apache2/conf-available# cd/etc/apache2/sites-available

И делаем на всякий случай резервные копии всех хранящихся там файлов:

root@shpc:/etc/apache2/sites-available# cp 000-default.conf 000-default.conf.bak
root@shpc:/etc/apache2/sites-available# cp default-ssl.conf default-ssl.conf.bak

Теперь ещё раз проверяем подключённые модули headers и SSL:

Далее нам надо перенести созданные сертификаты (сертификат CA и сертификат сервера) в каталог /etc/ssl/certs, а ключ сертификата сервера — в каталог /etc/ssl/private:

root@shpc:/opt/simple_CA# cp ca.cer /etc/ssl/certs/
root@shpc:/opt/simple_CA# cp server.cer /etc/ssl/certs/server.crt
root@shpc:/opt/simple_CA# cp server.key /etc/ssl/private/server.key

Далее откроем конфиг сайта (/etc/apache2/sites-available/000-default-ssl.conf) и добавим туда следующие опции:

SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key
SSLCACertificateFile /etc/ssl/certs/ca.cer

Теперь перезагружаем веб-сервер:

root@shpc:/etc/apache2# a2ensite default-ssl
root@shpc:/etc/apache2/sites-available# service apache2 restart

Проверяем доступность сайта:

Видим, что Firefox не может проверить сертификат сайта. Чтобы смог, надо импортировать цепочку сертификатов, подтверждающих сертификат сервера, в список доверенных. Создадим цепочку:

root@shpc:/opt/simple_CA# openssl crl2pkcs7 -nocrl-certfile ca.cer -certfile server.cer -out serve-and-ca-chain.p7c -outform der

У полученного файла не забываем сменить атрибуты на 555:

root@shpc:/opt/simple_CA# chmod555 serve-and-ca-chain.p7c 

Теперь откроем в браузере менеджер сертификатов и импортируем полученную цепочку (кнопка Import):

Далее можно просмотреть сертификаты и настроить доверие — вдруг что-то упущено:

Когда сертификаты добавлены в список доверенных, можно снова зайти на сайт и увидеть, что соединение помечается как доверенное:

Сейчас время настроить аутентификацию для клиентов. 

Настройка аутентификации клиентов

Веб-сервер Apache поддерживает аутентификацию клиента. Это значит, что мы можем выписать клиенту сертификат SSL, а сервер сможет его проверить. Если у пользователя не будет сертификата — аутентификация не пройдёт. Для активации такой возможности надо добавить в конфиг default-ssl.conf такие опции:

SSLCACertificateFile /opt/simple_CA/ca.cer 
SSLVerifyClient require 
SSLVerifyDepth 2

После этого к сайту сможет подключиться только тот пользователь, сертификат которого:

• установлен в браузере, если клиентом является браузер, — тогда сертификат будет предъявлен при подключении к серверу;
• подписан сертификатом доверенного УЦ.

Сначала сгенерируем сертификат для клиента. Первым делом создаём ключ:

root@shpc:/opt/simple_CA# openssl genrsa -out client.key 4096

Затем на основе ключа сгенерируем CSR:

root@shpc:/opt/simple_CA# openssl req -new-key client.key -out client.req

Теперь на базе запроса сгенерируем сам сертификат:

root@shpc:/opt/simple_CA# openssl req -new-key client.key -out client.req

И импортируем сертификат в формате p12:

root@shpc:/opt/simple_CA# openssl pkcs12 -export-inkey client.key -in client.cer -out client.p12 

В итоге у нас должен получиться файл client.p12. Нужно поменять права на файл, иначе сертификат не импортируется:

root@shpc:/opt/simple_CA# chmod555 client.p12

Теперь можно импортировать его в браузер по аналогии с корневыми сертификатами:

После импорта должно получиться примерно так:

После этого перезапускаем веб-сервер и возвращаемся на сайт. Видим окно выбора сертификата того пользователя, которого мы импортировали в браузер:

Общесистемные корневые ca сертификаты

Консолидированный файл, включающий в себя все корневые сертификаты CA операционной системы, находится в файле /etc/ssl/certs/ca-certificates.crt. Этот файл может быть символической ссылкой на фактическое расположение сертификатов в файлах /etc/ssl/cert.pem или /etc/ca-certificates/extracted/tls-ca-bundle.pem.

Корневые CA сертификаты в виде отдельных файлов расположены в директории /etc/ssl/certs, в этой директории могут быть ссылки на фактическое расположение сертификатов, например, в /etc/ca-certificates/extracted/cadir/.

Для просмотра Subject всех корневых CA сертификатов в системе:

awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt

Эти сертификаты используются утилитоми curl, wget и другими. Веб-браузеры Chromium и Firefox используют свои собственные хранилища корневых CA сертификатов.

Чтобы узнать, где веб браузеры хранять корневые CA сертификаты в Linux, нам нужно познакомиться с NSS.

Перспективы использования ssl-сертификатов

В ближайшее время вряд ли появится альтернатива PKI на базе стандарта X.509: размах необходимых действий по глобальному переходу на новые стандарты был бы весьма велик. По той же причине не следует ожидать существенного преодоления уже известных проблем стандарта, таких как невозможность оперативного исключения корневого сертификата, или трудоёмкая процедура получения сертификата в целом.

Практически все протоколы и сети Интернета переходят на защищённый канал передачи данных. Как следствие, спрос на SSL-сертификаты будет только возрастать. Насколько жизнеспособными окажутся модели OpenCA и Lets Encrypt, можно только гадать.

А пока тщательная проверка репутации CA перед приобретением у него сертификата является самым надёжным средством убедиться, что вас не ждут неприятности в этой области, как минимум до появления ближайшего обновления любого из установленных у вас на компьютере продуктов, использующих SSL/TSL.

По какому принципу работает ssl сертификат?

Итак для того, чтобы получить SSL сертификат самое первое, что нужно сделать, это сформировать специальный запрос на выпуск сертификата, так называемый (Certificate Signing Request). При формировании этого запроса вам будет задан ряд вопросов, для уточнения деталей о вашем домене и вашей компании. После завершения ваш веб сервер создаст 2 типа криптографических ключей — приватный ключ и публичный ключ.

Публичный ключ не является секретным и он помещается в запрос CSR.Вот пример такого запроса:—–BEGIN CERTIFICATE REQUEST—–MIIC3zCCAccCAQAwgZkxCzAJBgNVBAYTAlVBMQ0wCwYDVQQIEwRLaWV2MQ0wCwYDVQQHEwRLaWV2MRQwEgYDVQQKEwtIb3N0QXV0b21hdDEQMA4GA1UECxMHaG9zdGluZzEmMCQGCSqGSIb3DQEJARYXc3VwcG9ydEBob3N0YXV0b21hdC5jb20xHDAaBgNVBAMTE3d3dy5ob3N0YXV0b21hdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDTg7iUv/iX SyZl74GcUVFHjFC5IqlTNEzWgLWrsSmxGxlGzXkUKidNyXWa0O3ayJHOiv1BSX1l672tTqeHxhGuM6F7l5FTRWUyFHUxSU2Kmci6vR6fw5ccgWOMMNdMg7V5bMOD8tfI74oBkVE7hV95Ds3c594u7kMLvHR xui2S3z2JJQEwChmflIojGnSCO/iv64RL9vjZ5B4jAWJwrruIXO5ILTdis41Z1nNIx3bBqkif0H/G4eO5WF6fFb7etm8M d8ebkqEztRAVdhXvTGBZ4Mt2DOV/bV4e/ffmQJxffTYEqWg8wb465GdAJcLhhiSaHgqRzrprKns7QSGjdAgMBAAGgADANBgkqhkiG9w0BAQUFAAOCAQEAuCfJKehyjt7N1IDv44dd V61MIqlDhna0LCXH1uT7R9H8mdlnuk8yevEcCRIkrnWAlA9GT3VkOY3Il4WTGg3wmtq6WAgLkVXQnhIpGDdYAflpAVeMKil8Z46BGIhKQGngL2PjWdhMVLlRTB/01nVSKSEk2jhO8 7yLOY1MoGIvwAEF4CL1lAjov8U4XGNfQldSWT1o8z9sDeGsGSf5DAXpcccx0gCyk90HFJxhbm/vTxjJgchUFro/0goVpBcredpKxtkwBMuCzeSyDnkQft0eLtZ9b9Q4 ZNDWsPPKxo/zWHm6Pa/4F4o2QKvPCPx9x4fm /xHqkhkR79LxJ EHzQ==—–END CERTIFICATE REQUEST—–

Данные которые содержатся в этом ключе можно легко проверить с помощью сервисов CSR Decoder. Как пример: CSR Decoder 1 или CSR Decoder 2. Второй сервис выдает больше информации о CSR и проверяет ее на валидность, поле Signature в результатах проверки.

Если мы вставим такой запрос в форму для его расшифровки, то увидим, какие данные содержатся в публичном ключе.

Появление ssl

SSL (Secure Sockets Layer), семейство транспортных криптографических протоколов, известно примерно с 1994 года (первые работы по использованию средств криптографии в качестве транспорта для уже известных протоколов проводились и раньше).

Последний протокол семейства, SSL v3, в июне 2021 года в RFC7568 объявлен устаревшим. Взамен него надлежит использовать новые версии семейства SSL, протоколы TLS (Transport Layer Security) версии 1.2 или старше (на момент написания этого текста).

Оба протокола используют так называемый сертификат открытого ключа стандарта X.509, который не вполне корректно принято называть сейчас SSL-сертификатом. Стандарт известен с 1988 года. Сертификат открытого ключа, успешно использовавшийся на протяжении всего прошедшего времени, успел продемонстрировать свои сильные и слабые стороны (о них сказано ниже).

X.509 используется в так называемой инфраструктуре открытых ключей (PKI) — сюда входит не только программное обеспечение для использования сертификатов и других компонентов стандарта для передачи данных по защищённым от перехвата каналам, но также и оборудование, организации, собственно люди, соблюдающие упомянутые стандарты и обеспечивающие функционирование всей инфраструктуры в самых разных масштабах. Одного системного администратора может быть достаточно для успешного поддержания PKI в рамках достаточно крупной локальной сети не очень большой организации.

Важно понимать, что SSL-сертификат — всего лишь формат документа. Он не является «магическим» инструментом для формирования доверия к тому или иному ресурсу. Сертификат позволяет, при соблюдении ряда условий, проверить аутентичность передаваемых данных, указать на степень доверия к источнику зашифрованных данных.

Просмотр содержимого ключей и сертификатов

Мы можем подробно изучить содержимое всех созданных в OpenSSL файлов, а также при необходимости конвертировать их в другие форматы.

В следующих командах используются тестовые файлы со следующими именами:

Обратите внимание на расширения файлов — они могут отличаться от тех, которые используются в других инструкциях. Например, вместо .key и .crt может использоваться расширение .pem. Расширение файла не имеет особого значения кроме как служить подсказкой пользователю, что именно находится в этом файле. Это же самое касается и имён файлов — вы можете выбирать любые имена.

Все эти файлы являются текстовыми:

cat rootCA.key

Там мы увидим примерно следующее:

-----BEGIN PRIVATE KEY-----
MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQDJBKkr6XzzAcXD
eyDQdvB0SWE2Fl3nqlX/c2RgqMgScXtgidEzOu9ms3Krju5UKLokkQJrZFPMtiIL
MuPJFdYjVyfkfnqlZiouBVgJ60s8NQBBI8KnyyAoJCIFdASoW4Kv5C5LT8pX9eRa
/huJaRJL5XsFUGnTOLvW2ZLN52iAux9CoZlmH6ZF4nuQpblwN0MHULAhze52VNFT
…………………………………………………..
…………………………………………………..
…………………………………………………..
…………………………………………………..
…………………………………………………..
…………………………………………………..
-----END PRIVATE KEY-----

Различные модели доверия

CA может проводить как упрощённую верификацию, только по домену (DV — когда проверяется, что заказывающий сертификат управляет настройками домена), так и расширенную (OV — верификация организации; EV — расширенная верификация организации). В зависимости от ситуации и типа запрошенного сертификата, верификация может включать проверку существования организации-заказчика, наличие действующих контактных данных и т. д.

Вследствие всего этого цены на сертификаты OV/EV-типа, для которых требуется проверка, а главное — гарантия (например, в виде страхования), могут оказаться весьма высокими. В этой связи стоит упомянуть модель «сеть доверия» (Web of trust), когда доверие распространяется не только от корневого сертификата, надёжность которого не подлежит сомнению, а от человека или организации, за которых поручились другие участники сети доверия.

Проще говоря, если подтверждено доверие к одному из участников сети, то оно применяется и ко всем остальным участникам той же сети. Сама процедура верификации обычно требует физического присутствия человека, поэтому распространение таких сетей может оказаться не слишком простым процессом.

В число недостатков подхода «сеть доверия» можно включить не очень понятную процедуру отзыва доверия (как усилиями самого участника сети, так и усилиями других лиц или организаций).

Примером CA, работающего по схеме сети доверия, является OpenCA. При минимальном уровне доверия их сертификаты по сути подтверждают только факт управления доменным именем. Кроме того, корневой сертификат OpenCA не входит по умолчанию в хранилища доверенных сертификатов ОС и отдельных программных продуктов — так что ещё предстоит убедить пользователя внести его вручную. Использование сертификатов для ресурсов коммерческой направленности, для ресурсов, обрабатывающих или хранящих частные данные, и т. п. становится проблематичным.

Организация EFF (Electronic Frontier Foundation) объявила о запуска в сентябре 2021 года сервиса Lets Encrypt, где бесплатный сертификат сможет получить каждый ресурс.

Способ 1: окно «выполнить»

1. При помощи нажатия комбинации клавиш «Win R» попадаем в окошко «Выполнить». Вводим в командную строку certmgr.msc.



2. Цифровые подписи хранятся в папке, которая находятся в директории «Сертификаты – текущий пользователь». Здесь сертификаты находятся в логических хранилищах, которые разделены по свойствам.

   

   В папках «Доверенные корневые центры сертификации» и «Промежуточные центры сертификации» находится основной массив сертификатов Виндовс 7.



3. Чтобы посмотреть информацию о каждом цифровом документе, наводим на него и кликаем ПКМ. В открывшемся меню выбираем «Открыть».

   

   Переходим во вкладку «Общие». В разделе «Сведения о сертификате» будет отображено предназначение каждой цифровой подписи. Также представлена информация «Кому выдан», «Кем выдан» и сроки действия.

   

Способ 2: панель управления

Также есть возможность посмотреть сертификаты в Windows 7 через «Панель управления».

1. Открываем «Пуск» и переходим в «Панель управления».



2. Открываем элемент «Свойства обозревателя».



3. В открывшемся окне переходим во вкладку «Содержание» и щелкаем по надписи «Сертификаты».



4. В открывшемся окошке предоставлен перечень различных сертификатов. Чтобы посмотреть подробную информацию об определённой цифровой подписи, жмём по кнопке «Просмотр».

После прочтения данной статьи вам не составит никакого труда открыть «Хранилище сертификатов» Windows 7 и узнать подробную информацию о свойствах каждой цифровой подписи в вашей системе.

Отзыв ключей и сертификатов

Тем, кто пользуется криптографией, например, программой вида

(или её «предком» — OpenPGP), известно понятие сертификата отзыва (revocation certiificate). Поскольку для распространения GnuPG-ключей используются публичные серверы ключей, для аннулирования последующих операций с конкретным ключом обычно достаточно отправить на сервер ключей специальный сертификат, объявляющий конкретный ключ отозванным.

В случае SSL-сертификатов есть несколько протоколов (CMP, OCSP и т. д.), позволяющих определить статус сертификата и, соответственно, возможность или невозможность его использования. На практике, поскольку в реальности связность в пределах Интернета и быстрый ответ тех или иных ресурсов не гарантирован, нет возможности достоверно объявить об отзыве сертификата.