Подробно об SSL и сертификатах

Основные сведения об SSL

Что такое сертификаты и зачем они нужны

Сертификаты представляют собой текстовые файлы на веб-сервере, размещение и содержание которых подтверждает личность ответственного владельца веб-ресурса. Подтверждение владельца осуществляют специально уполномоченные компании или подразделения организации – Удостоверяющие Центры (они же УЦ, Certificate Authority, CA).

Дополнительно сертификат содержит публичный ключ необходимый для установки шифрованного соединения для работы в сети с целью исключить перехват данных злоумышленниками. Протоколы, по которым устанавливается данное соединение, оканчиваются на букву «S», от английского слова «Secure», что в переводе означает «Безопасный». Например, HTTP(S), FTP(S) и т.д. Это значит, что используются стандартные протоколы сети Интернет, такие как HTTP и FTP, поверх защищённого шифрованием TLS-соединения, тогда как обычные обмениваются сообщениями поверх TCP/IP в исходном виде. TLS (англ. Transport Layer Security, безопасность транспортного уровня) – протокол обеспечения безопасной передачи данных, основанный на базе другого криптографического протокола SSL (англ. Secure Sockets Layer, уровень защищённых сокетов), использующего асимметричную криптографию для аутентификации ключей обмена для установки сеанса, симметричное шифрование для последующего сохранения конфиденциальности сеанса и криптографическую подпись сообщений для гарантирования доставки информации без потерь. Несмотря на то, что фактически используется только протокол TLS, в силу привычки всё семейство данных протоколов называют SSL, а сопутствующие сертификаты – SSL-сертификатами.

Использование SSL-сертификатов в первую очередь позволяет предупредить кражу данных с использованием клонов сайтов известных сервисов, когда злоумышленники дублируют основные страницы известных сайтов, используя схожие доменные имена, и подделывают формы для ввода персональной информации. Пользователь может указать на поддельных сайтах данные о себе, о своих документах, о платёжных реквизитах. В результате персональная информация пользователей может быть использована с целью получения несанкционированного доступа к иным ресурсам или социальным сетям, перепродажи либо попытки кражи средств с банковского счёта. Владельцы сервисов могут помочь клиентам избежать данных проблем, настроив HTTPS на своём ресурсе и сигнализируя пользователям о подлинности своих веб-страниц непосредственно в адресной строке браузера.

Как было сказано выше, TLS/SSL используется для шифрования трафика от клиента к веб-серверу, в результате чего предотвращается перехват трафика злоумышленниками в публичных незащищённых сетях.

Как они работают

В ходе работы TLS/SSL участвуют три стороны: клиент – потребитель услуг или товаров в сети Интернет, сервер – поставщик данных услуг или товаров, а также Удостоверяющий Центр, в обязанности которого входит убедиться, что доменное имя и ресурс принадлежит именно той организации, которая указана в регистрационной информации сертификата.

Алгоритм работы TLS/SSL выглядит следующим образом:

1. Владельцы сервиса обращаются в Удостоверяющий Центр через партнёров и указывают информацию о себе.
2. Удостоверяющий Центр наводит справки о владельцах сервиса. Если первичная информация подтверждается, то Удостоверяющий центр выпускает и передаёт владельцам сервиса сертификат, в состав которого входят проверенные сведения и публичный ключ.
3. Пользователь запускает браузер на персональном устройстве и переходит на страницу сервиса.
4. Браузер наряду со стандартными операциями в ходе загрузки страницы сервиса запрашивает его SSL-сертификат.
5. Сервис отправляет браузеру копию сертификата в ответ.
6. Браузер с помощью предварительно установленных корневых сертификатов Удостоверяющих Центров проверяет срок действия и валидность присланной копии сертификата. Если проверки успешно пройдены, то браузер отправляет соответствующий ответ сервису, подписанный ключом клиента.
7. Сервис получает подтверждение прохождения проверки на стороне клиента с его цифровой подписью и начинает шифрованный сеанс.

Шифрование сеанса осуществляется при помощи средств PKI (Public Key Infrastructure, инфраструктура открытых ключей). В основе PKI лежат следующие принципы:

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

SSL-сертификат от Удостоверяющего Центра является способом распространения открытого ключа от сервера к клиентам в незащищённых сетях. Клиент после проверки валидности сертификата все исходящие сообщения шифрует прикреплённым к сертификату открытым ключом и дешифрует входящие своим приватным, тем самым обеспечивается защищённый канал связи.

Кто их выпускает

Сертификаты выпускают Удостоверяющие Центры по запросам от клиентов. Удостоверяющий Центр – это независимая сторонняя организация, официально занимающаяся проверкой указанных в запросе на сертификат сведений: действительно ли доменное имя, принадлежит ли сетевой ресурс с данным именем конкретной компании или физическому лицу, на которые оно зарегистрировано; подлинный ли сайт компании или физического лица, для которого был выпущен SSL-сертификат и прочие проверки. Наиболее известные международные Удостоверяющие Центры – Comodo, Geotrust, GoDaddy, GlobalSign, Symantec. Корневые SSL-сертификаты данных Удостоверяющих Центров предустановлены в качестве доверенных во всех популярных браузерах и операционных системах. Приобретать сертификаты зачастую выгоднее не напрямую у Удостоверяющего Центра, а у их партнёров, для которых действуют оптовые скидки. В России продажей сертификатов известных Удостоверяющих Центров занимается множество компаний и хостинг-провайдеров, имеющих собственные тарифы на услугу SSL-сертификатов.

Продвинутые сведения про сертификаты

Какие крипто алгоритмы используются

При установке защищённого соединения используются следующие алгоритмы:

• алгоритм шифрования;
• алгоритмы хеширования;
• алгоритмы аутентификации.

Наиболее часто используемыми алгоритмами шифрования, которые используются для криптографических операций в TLS/SSL, являются комбинации алгоритмов RSA (аббревиатура от фамилий создателей Rivest, Shamir и Adleman), DSA (англ. Digital Signature Algorithm, запатентованный Национальным институтом стандартов и технологий США) и несколько вариаций алгоритма Диффи–Хеллмана (англ. Diffie–Hellman, DH), такие как единовременный DH (англ. Ephemeral Diffie–Hellman, EDH) и DH на основе эллиптических кривых (англ. Elliptic curve Diffie–Hellman, ECDH). Данные вариации Диффи-Хэллмана, в отличие от исходного алгоритма, обладают свойством прогрессивной секретности, т.е. когда записанные ранее данные невозможно дешифровать через какое-то время, даже если удалось получить секретный ключ сервера, т.к. исходные параметры алгоритма генерируются заново при повторном установлении канала после принудительного разрыва в течение определённого таймаута соединения.

В основе алгоритмов хеширования лежит семейство математических функций вычисления хеша SHA (англ. Secure Hash Algorithm). Хеш-функция позволяет преобразовать исходный массив данных в строку определённой длины, в зависимости от которой варьируется время обработки и требуемые вычислительные мощности. Все алгоритмы шифрования сегодня поддерживают алгоритм хеширования SHA2, чаще всего SHA-256. SHA-512 имеет похожую структуру, но в нем длина слова равна 64 бита вместо 32, количество раундов в цикле равно 80 вместо 64, а сообщение разбивается на блоки по 1024 бита, вместо 512 бит. Раньше для тех же целей применялись алгоритмы SHA1 и MD5, но сегодня они считаются уязвимыми. Современные сервисы используют ключи длиной 64 бита и выше. Актуальная версия алгоритма SHA-3 (Keccak).

Хеш-алгоритм также использует величину, необходимую для проверки целостности передаваемых данных, — MAC (англ. Message Authentication Code). MAC использует функцию отображения, чтобы представлять данные сообщения как фиксированное значение длины, а затем хеширует сообщение. В современных версиях протокола TLS применяется HMAC (англ. Hashed Message Authentication Code), который использует хеш-функцию сразу с общим секретным ключом. Данный ключ передаётся вместе с потоком информации, и для подтверждения подлинности обе стороны должны использовать одинаковые секретные ключи, что обеспечивает большую безопасность.

Общий алгоритм работы SSL

Соглашение о рукопожатии (Handshake protocol). Протокол

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

• Тип – категория сообщений. Существует 10 категорий сообщений.
• Длина – длина каждого сообщения в байтах.
• Содержимое – непосредственно сообщение и его параметры.

В ходе соглашения о рукопожатии проходят следующие этапы:

1.1 Определение поддерживаемых алгоритмов. На первом этапе инициируется соединение между клиентом и сервером и осуществляется выбор алгоритмов шифрования. Сначала клиент отправляет клиенту приветственное сообщение на сервер и переходит в режим ожидания ответа. Сервер после получения приветственного сообщения клиента возвращает клиенту собственное приветственное сообщение для подтверждения установки соединения. Приветственное сообщение клиента включает следующие данные:

1. Максимальный номер версии SSL, который может поддерживать клиент.
2. 32-байтовое случайное число, используемое для генерации главного секрета.
3. Идентификатор сеанса.
4. Список комплектов шифров.
5. Список алгоритмов сжатия.

Формат списка комплектов шифров:

<1>_<2>_<3>_<4>

Где:

1. Название протокола, например, «SSL» или «TLS».
2. Алгоритм обмена ключами (с указанием алгоритма аутентификации).
3. Алгоритм шифрования.
4. Алгоритм хеширования. Например, запись «SSL_DHE_RSA_WITH_DES_CBC_SHA» означает, что фрагмент «DHE_RSA» (временный Diffie-HellMan с цифровой подписью RSA) определяется как алгоритм обмена ключами; фрагмент «DES_CBC» определяется, как алгоритм шифрования; а фрагмент «SHA» определяется как алгоритм хеширования. Как будет рассмотрено далее, в TLSv1.3 протоколы обмена ключами и шифрования объединены в алгоритм аутентифицированного шифрования с присоединёнными данными (AEAD), поэтому запись там будет короче. Пример: TLS_AES_256_GCM_SHA384. Ответ сервера включает в себя следующие поля:
   • Номер версии SSL. На клиенте сравниваются самый низкий номер версии, поддерживаемый клиентом, и самый большой номер версии, поддерживаемый сервером. В зависимости от настроек сервера приоритет в выборе может отдаваться клиенту либо серверу.
   • 32-байтовое случайное число, используемое для генерации главного секрета.
   • Идентификатор сессии.
   • Набор шифров из списка шифров, поддерживаемых клиентом.

Метод сжатия из списка методов сжатия, поддерживаемых клиентом.

1.2 Проверка подлинности сервера и обмен ключами

На втором этапе все сообщения отправляет сервер. Этот этап делится на 4 стадии:

1. Отправка цифрового сертификата клиенту, чтобы клиент мог использовать открытый ключ сервера для аутентификации.
2. Обмен ключами на сервере. В зависимости от установленного алгоритма данный этап может отсутствовать.
3. Запрос сертификата у клиента. В зависимости от настроек сервер может потребовать от клиента отправку собственного сертификата.
4. Сообщение о завершении этапа и перехода к следующим операциям.

1.3 Аутентификация клиента и обмен ключами:

На третьем этапе все сообщения отправляет клиент. Этот этап делится на 3 стадии:

1. Отправка сертификата на сервер, если сервер запрашивал его, в зависимости от установленного алгоритма. Таким образом клиент может подтвердить подлинность на сервере, например, в IIS можно настроить обязательную проверку подлинности сертификата клиента.
2. Обмен ключами клиента (англ. Pre-master-secret) – отправка мастер-ключа на сервер, который впоследствии будет шифроваться ключом сервера. Клиент знает мастер-ключ и в случае подмены сервера сможет прервать соединение.

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

1.4 Завершение работы сервера.

На четвёртом этапе осуществляется непосредственно обмен сообщениями и контроль ошибок, при обнаружении которых вступает в силу протокол тревоги. Этот этап состоит из обмена сообщениями о сеансе: первые 2 приходят от клиента, а последние 2 сообщения – от сервера.

Процесс генерации ключей

Чтобы обеспечить целостность и конфиденциальность информации, SSL требует шесть секретов шифрования: четыре ключа и два значения вектора инициализации (англ. Initialization Vector, IV, см. далее). Достоверность информации гарантируется ключом аутентификации (например, HMAC), шифрование данных обеспечивается открытым ключом, и блоки данных создаются на основе IV. Ключи, требуемые SSL, являются однонаправленными, что значит при взломе клиента полученные данные нельзя использовать для взлома сервера.

Запись соглашения (Record Protocol)

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

1. Конфиденциальность путём использования секретного ключа, определённого на этапе рукопожатия.
2. Целостность путём анализа MAC определённого при квитировании.

Протокол тревоги

Когда клиент и сервер обнаруживают ошибку, они отправляют соответствующее сообщение. Если это критичная ошибка, алгоритм немедленно закрывает соединение SSL, и обе стороны сначала удаляют реквизиты сеанса: идентификатор, секрет и ключ. Каждое сообщение об ошибке имеет длину 2 байта. Первый байт указывает тип ошибки. При сбое соединения, значение равно 1, при обнаружении критичной ошибки – 2. Второй байт указывает фактический тип ошибки.

Версии SSL (SSL, TLS) и чем они отличаются

При первоначальной установке защищённого соединения между клиентом и сервером осуществляется выбор протокола среди поддерживаемых обеими сторонами из набора SSLv3, TLSv1, TLSv1.1, TLSv1.2 или TLSv1.3.

Более ранние версии протокола SSL не используются. Версия SSLv1 так и не была обнародована. Версия SSLv2 была выпущена в феврале 1995 года, но содержала много недостатков безопасности, которые привели к разработке SSLv3. Различные IT-компании начали предпринимать попытки реализовать собственные версии протоколов безопасной передачи данных. Чтобы предотвратить разобщённость и монополизацию в сфере безопасности в сети, международное сообщество проектировщиков, учёных, сетевых операторов и провайдеров (англ. Internet Engineering Task Force, IETF), созданное советом по архитектуре Интернета в 1986 году и занимающееся развитием протоколов и организации работы Интернета, стандартизировало протокол TLS версии 1, незначительно отличающийся от SSL 3.0.

Технические детали работы протокола фиксируются выпуском документа под названием RFC (англ. Request for Comments, рабочее предложение). Данные документы можно найти на сайте IETF www.ietf.org/rfc/rfcXXXX.txt, где XXXX — состоящий из 4 цифр номер RFC. Таким образом, версия TLSv1 зафиксирована в RFC 2246, версия TLSv1.1 – в RFC 4346, версия TLSv1.2 – в RFC 5246, а версия TLSv1.3 – в RFC 8446. Кроме того, в RFC 3546 определено несколько расширений для случаев, когда TLS используются в системах с ограниченной пропускной способностью, таких как беспроводные сети; в RFC 6066 определён ряд дополнительных изменений TLS, внесённых в формат расширенного приветствия клиента (представленного в TLSv1.2 ); в RFC 6961 определён метод уменьшения трафика, когда клиент запрашивает у сервера информацию о состоянии сертификата; и, наконец, в RFC 7925 определяется, что происходит с TLS (и DTLS) при его использовании в IoT (англ. Internet Of Things, интернет вещей) при обмене данными между аппаратными средствами и иными физическими объектами без участия человека.

Как было сказано выше, протокол TLSv1 был выпущен в качестве обновления SSLv3. Как указано в RFC 2246, «различия между этим протоколом и SSLv3 не являются существенными, но они достаточно значительны, чтобы исключить взаимодействие между TLSv1 и SSLv3».

Протокол TLSv1.1 по сравнению с TLS версии 1.0 имел следующие отличия:

• Добавлена защита от атак с использованием CBC (англ. Cipher Block Chaining), когда каждый блок открытого текста перед шифрованием связывается с предыдущим блоком зашифрованного текста.
  • Неявный вектор инициализации (исходное псевдослучайное число инициирующее вычисление дальнейшего шифра, IV) был заменён на явный, являющийся не секретным, а непредсказуемым за разумное время.
  • Изменение в обработке ошибок заполнения блоков, когда пакет данных дополняется до размера фиксированного блока.
• Поддержка регистрации параметров IP-адресов серверов и прочей сетевой информации.

Протокол TLS 1.2 основан на спецификации TLS 1.1. Наиболее распространён на текущий момент. Основные отличия включают:

• Комбинация алгоритмов хеширования MD5–SHA-1 в псевдослучайной функции (англ. Pseudorandom Function, PRF) была заменена на более устойчивую к взлому SHA-256, с возможностью использования набора шифров, указанной функции.
• Размер хеша в готовом сообщении стал составлять не менее 96 бит.
• Комбинация алгоритмов хеширования MD5–SHA-1 в цифровой подписи была заменена одним хешем, согласованным во время рукопожатия, который по умолчанию равен SHA-1.
• Реализация функции выбора алгоритмов шифрования и хеширования для клиента и сервера.
• Расширение поддержки аутентифицированных шифров шифрования, используемых в основном для режима Galois/ Counter (GCM) и режима CCM для стандарта Advanced Encryption Standard (AES).
• Добавление определений расширений TLS и наборов шифров AES.
• Удаление обратной совместимости с SSLv2 в рамках 6176 RFC. Таким образом, сеансы TLS перестали согласовывать использование SSL версии 2.0 уровня защищённых сокетов.

Протокол TLS 1.3 основан на спецификации TLS 1.2. Осуществляется постепенный переход на данный протокол у интернет-сервисов. Основные отличия включают в себя:

• Отделение алгоритмов согласования ключей и аутентификации от наборов шифров.
• Удаление поддержки неустойчивых и менее используемых именованных эллиптических кривых.
• Удаление поддержки криптографических хеш-функций MD5 и SHA-224.
• Требование цифровых подписей даже при использовании предыдущей конфигурации.
• Интеграция функции формирования ключа, основанной на HMAC (англ. HKDF), и полу-эфемерного предложения DH.
• Поддержка однократного времени возобновления сеанса приёма-передачи (англ. Round Trip Time или 1-RTT) рукопожатий, и начальная поддержка нулевого времени возобновления сеанса приёма-передачи (наименование режима 0-RTT).
• Гарантия невозможности компрометации сессионных ключей, полученных при помощи набора ключей долговременного пользования, при получении злоумышленниками доступа к ним. Данное свойство называется совершенная прямая секретность (англ. Perfect forward secrecy, PFS) и реализуется посредством использования эфемерных ключей во время соглашения о ключах DH.
• Отказ от поддержки многих небезопасных или устаревших функций, включая сжатие, повторное согласование, шифры, отличные от AEAD-режимов блочного шифрования (англ. Authenticated Encryption with Associated Data), обмен ключами, отличными от PFS (среди которых статический обмен ключами RSA и статический обмен ключами DH), настраиваемые группы EDH, согласование формата точки эллиптической кривой ECDH, протокол спецификации изменения шифрования, приветственное сообщение UNIX time и т.д.
• Запрет на согласование SSL или RC4, присутствовавшее для обеспечения обратной совместимости.
• Отказ от использования номера версии уровня записи и фиксация номера для улучшения обратной совместимости.
• Добавление потокового шифра ChaCha20 с кодом аутентификации сообщения Poly1305.
• Добавление алгоритмов цифровой подписи Ed25519 и Ed448.
• Добавление протоколов обмена ключами x25519 и x448.
• Добавление поддержки отправки нескольких ответов протокола определения состояния сетевого сертификата (англ. Online Certificate Status Protocol, OCSP).
• Шифрование всех подтверждений приёма-передачи блока данных после вызова сервера.

Что такое PKI (Public Key Infrastructure)

Инфраструктура открытых ключей (англ. Public Key Infrastructure, PKI) – система программных, аппаратных и регламентных способов, обеспечивающих решение криптографических задач на базе пары закрытого и открытого ключей. В основе PKI лежит эксклюзивное доверие участников обмена удостоверяющему центру при отсутствии информации друг о друге. Удостоверяющий центр в свою очередь подтверждает или опровергает принадлежность открытого ключа заданному лицу, которое владеет соответствующим закрытым ключом.

Основные компоненты PKI:

• Удостоверяющий центр или Центр сертификации – организация, осуществляющая в том числе и юридическую проверку данных об участниках сетевого взаимодействия (клиент или сервер). С технической точки зрения, Удостоверяющий центр представляет собой программно-аппаратный комплекс, который осуществляет управление жизненным циклом сертификатов, но не их непосредственным использованием. Является доверенной третьей стороной.
• Сертификат открытого ключа (чаще всего просто сертификат) – это данные клиента или сервера, а также открытый ключ, подписанные электронной подписью Удостоверяющего центра. Выпуск сертификата открытого ключа Удостоверяющим центром гарантирует, что лицо, указанное в сертификате, владеет и закрытой частью единой ключевой пары.
• Регистрационный центр (РЦ) – промежуточный Удостоверяющий центр, действующий на основания доверия к корневому Удостоверяющему центру. Корневой Удостоверяющий центр доверяет данным, полученным регистрационным центром в ходе проверки информации о субъекте. Регистрационный центр после проверки достоверности информации подписывает её собственным ключом и передаёт полученные данные корневому Удостоверяющему центру. Корневой Удостоверяющий центр проверяет подпись регистрационного центра и в случае успеха выпускает сертификат. Один регистрационный центр может работать с несколькими Удостоверяющими центрами (иными словами, состоять в нескольких PKI), так же, как и один Удостоверяющий центр может работать с несколькими регистрационными центрами. Данный компонент может отсутствовать в корпоративной инфраструктуре.
• Репозиторий – хранилище действующих сертификатов и список отозванных сертификатов, которые постоянно обновляются. Список отозванных сертификатов (англ. Certificate Revocation List, CRL) содержит данные о выпущенных сертификатах, у которых истёк оплаченный период или срок действия, а также сертификаты владельцев ресурсов, которые были скомпрометированы или не была подтверждена подлинность. В Федеральном Законе РФ № 63 «Об электронной подписи» Российской Федерации данный компонент называется реестром сертификатов ключей подписей.
• Архив сертификатов – хранилище всех выпущенных когда-либо сертификатов (включая сертификаты с закончившимся сроком действия) в рамках текущей PKI. Архив сертификатов используется для расследований инцидентов безопасности, которые включают в себя проверку когда-либо подписанных данных.
• Центр запросов – личный кабинет клиента Удостоверяющего центра, где конечные пользователи могут запросить новый или отозвать имеющийся сертификат. Реализуется чаще всего в виде веб-интерфейса для регистрационного центра.

Конечные пользователи – клиенты, приложения или системы, являющиеся владельцами сертификата и использующие инфраструктуру управления открытыми ключами.

Как браузер работает с SSL сертификатами

Что происходит в браузере при проверке сертификата

Независимо от каких-либо расширений браузеры должны всегда проверять основную информацию о сертификате, такую как подпись или издатель. Шаги проверки информации о сертификате:

1. Проверка целостности сертификата. Выполняется с помощью криптографической операции Verify, выполняемой с открытым ключом. Если подпись недействительна, то сертификат считается поддельным, который был изменён после его выдачи третьей стороной, и отклоняется.
2. Проверка действительности сертификата. Выполняется с помощью криптографической операции Decrypt и считыванием сопутствующей информации. Сертификат считается действительным в течение оплаченного клиентом периода либо срока годности. Срок годности сертификата – это срок гарантии подлинности владельца со стороны Удостоверяющего центра, осуществившего его выпуск. Браузеры отклоняют любые сертификаты со сроком годности, истёкшим до или начавшимся после даты и времени проверки.
3. Проверка статуса отзыва сертификата. Выполняется с помощью криптографической операции Decrypt, загрузкой и сверкой c CRL. Ряд обстоятельств, например, обращение правоохранительных органов, обнаружение изменения исходной информации или подтверждение факта компрометации закрытого ключа сервера могут привести к тому, что сертификат станет недействительным до истечения срока его действия. Для этого сертификат добавляют в CRL на стороне Удостоверяющего центра.

Центры сертификации на периодической основе выпускают новую версию подписанного CRL, который распространяется в общедоступных репозиториях. Браузеры получают и просматривают последнюю версию CRL при проверке сертификата. Главный недостаток такого подхода заключается в ограничении проверки периодом выдачи CRL. Браузер будет уведомлён об отзыве только после того, как получит актуальный CRL. В зависимости от политики подписывающего Удостоверяющего центра период обновления CRL может исчисляться неделями.

При работе с TLSv2 и TLSv3 браузер может использовать протокол определения состояния сетевого сертификата OCSP, описанного в RFC 6960. OCSP позволяет браузеру запрашивать статус отзыва определённого сертификата в режиме онлайн (операция reply). При корректной настройке OCSP проверка наличия сертификата в CRL выполняется намного быстрее и позволяет избежать использования фактически отозванных сертификатов до следующего обновления CRL. Существует технология OCSP Stapling, позволяющая включать копию ответа на запрос состояния сертификата от Удостоверяющего центра в заголовки HTTP-ответов веб-сервера, что в свою очередь повышает производительность и скорость обмена данными.

4. Проверка издателя сертификата по цепочке сертификатов.

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

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

Формат X.509 v3 позволяет определять какие именно сертификаты цепочки следует проверить. Данные ограничения редко влияют на обычного пользователя Интернета, хотя они довольно часто встречаются в корпоративных системах на этапе разработки и отладки.

5. Проверка ограничения доменного имени

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

6. Проверка политики выпуска сертификата

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

7. Проверка длины цепочки сертификата

Формат X.509 v3 позволяет издателям определять максимальное количество промежуточных удостоверяющих центров, которые могут поддерживать сертификат. Данное ограничение было введено после того, как в 2009-м году была продемонстрирована возможность подделки действительного сертификата путём включения самоподписанного сертификата в очень длинную цепочку.

8. Проверка назначения открытого ключа

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

9. Проверка остальных сертификатов цепочки

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

Как посмотреть сведения о сертификате и проверить, что все работает корректно

Сертификат безопасности можно проверить непосредственно в браузере. Все современные браузеры отображают сведения о сертификате непосредственно в адресной строке. Признак установки защищённого соединения с веб-ресурсом представлен в виде замка в левой части адресной строки браузера. В случае ошибки будет отображаться перечёркнутое слово «HTTPS» или пиктограмма в виде открытого замка. В зависимости от вида браузера и его версии вид пиктограмм и поведение при работе с SSL-сертификатами может отличаться. Ниже приведены примеры изображений для различных версий современных браузеров:

Google Chrome

Mozilla Firefox

Opera

Microsoft Edge

Chrome for Android

Safari for iOS

Чтобы посмотреть детали сертификата, кликните по пиктограмме в виде замка и в появившемся меню кликните по пункту, связанному с безопасностью. Информация о сертификате появится после клика по соответствующей кнопке или по информационной ссылке:

Сообщение о том, что браузер не доверяет сертификату

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

Существует ряд причин, по которым SSL-сертификат может считаться недействительным в браузере. Наиболее распространённые причины:

• Ошибки в процессе установки цепочки сертификатов, не хватает промежуточного сертификата;
• Срок действия SSL-сертификата истёк;
• SSL-сертификат действителен только для основного домена, а не для поддоменов;
• Используется самоподписанный SSL-сертификат, или корневой сертификат Удостоверяющего центра не добавлен в список доверенных на текущем устройстве;

Удостоверяющие центры

Более детально про удостоверяющие центры

Как было сказано выше, основная задача Удостоверяющего центра – подтверждать подлинность ключей шифрования с помощью сертификатов электронной подписи. Главный принцип работы описывается тезисом «никто не доверяет друг другу, но все доверяют Удостоверяющему центру».

Любое HTTPS-взаимодействие основывается на том, что один участник имеет сертификат, подписанный Удостоверяющим центром, а второй пытается проверить подлинность этого сертификата. Проверка будет успешной, если оба участника доверяют одному и тому же Удостоверяющему центру. Для решения такой проблемы в операционные системы и браузеры предустановлены сертификаты Удостоверяющего центра. Если непосредственно сам Удостоверяющий центр выпустил сертификат, он называется корневым. Если сертификат был выпущен партнёром Удостоверяющего центра, с которым у него есть доверительные отношения, то такой сертификат называется промежуточным. В результате формируется дерево из сертификатов, между которыми есть цепочка доверия.

Установив сертификат Удостоверяющего центра в систему, можно доверять тем сертификатам, которые он подписал. Если сертификат (в частности для HTTPS) выдан, но не подписан каким-нибудь корневым или промежуточным Удостоверяющим центром, то его называют самоподписанным и он считается недоверенным на всех устройствах, где данный сертификат не добавлен в списки корневых/промежуточных.

По уровню распространения сертификатов Удостоверяющий центр может быть международным, региональным и корпоративным. Деятельность инфраструктуры управления открытыми ключами осуществляется на основе регламента соответствующего уровня: публичные директивы, зафиксированные международным сообществом пользователей Интернета, законодательство региона или соответствующие положения организации.

Основные функции удостоверяющего центра:

• проверка личности будущих пользователей сертификатов;
• выдача пользователям сертификатов;
• аннулирование сертификатов;
• ведение и публикация списков отозванных сертификатов (Certificate Revocation List/CRL), которые используются клиентами инфраструктуры открытого ключа, когда они решают вопрос о доверии сертификату.

Дополнительные функции удостоверяющего центра:

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

Браузеры и операционные системы устройств фиксируют доверие Удостоверяющему центру, принимая корневой сертификат в своё хранилище – специальную базу данных о корневых сертификатах Удостоверяющих центров. Хранилище размещается на устройстве пользователя после установки ОС или браузера. Например, Windows поддерживает своё хранилище корневых сертификатов в операционных системах, Apple имеет так называемое хранилище доверия, Mozilla (для своего браузера Firefox) создаёт отдельное хранилище сертификатов. Многие операторы мобильной связи также имеют собственное хранилище. Региональные и корпоративные должны быть добавлены или на этапе сертификации ПО в стране, или путём обращения в техническую поддержку организации.

Региональные представители всемирных Удостоверяющих центров имеют полномочия на юридические запросы деятельности организаций, связанной с публикацией веб-ресурсов. Для корпоративных Удостоверяющих центров это необязательно, поскольку обычно они имеют доступ к внутренней информации организации. Исходя из целей безопасности, Удостоверяющие центры не должны выдавать цифровые сертификаты напрямую из корневого сертификата, передаваемого операторам, а только через один или несколько промежуточных центров сертификации (англ. Intermediate Certificate Authority, ICA). Данные промежуточные Центры сертификации обязаны выполнять рекомендации по безопасности чтобы свести к минимуму уязвимость корневого Удостоверяющего центра для хакерских атак, но есть и исключения, так, например, GlobalSign — один из немногих центров сертификации, которые всегда (с 1996 года) использовали ICA.

Сертификаты бывают разных форматов и поддерживают не только SSL, а ещё и аутентификацию людей и устройств, а также заверяют подлинность кода и документов. В рамках российского законодательства подобная деятельность должна быть лицензирована ФСБ, поскольку связана с криптографическими операциями.

Универсальный алгоритм получения сертификата у Удостоверяющего центра:

1. Генерация закрытого ключа.
2. Создание запроса подписи сертификата (англ. Certificate Signing Request, CSR-запрос).
3. Получение сертификата, подписанного корневым сертификатом Удостоверяющего центра после прохождения проверок.
4. Конфигурация веб-сервера для вашего ресурса.

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

Что такое корневые сертификаты

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

На основе корневого сертификата удостоверяющего центра строится цепочка доверия сертификатам. Любая электронная подпись, выпущенная Удостоверяющем центром корректно работает только при наличии корневого сертификата.

В корневом сертификате хранится информация с датами его действия. Также криптопровайдер с помощью корневого сертификата получает доступ к реестру организации.

Что такое цепочка сертификатов

Исторически и технологически сложилось так, что ряд Удостоверяющих центров получили наибольшее признание среди пользователей SSL, поэтому было принято согласованное решение считать сертификаты, которые они выпускают, корневыми и всегда им доверять. Региональные Удостоверяющие сертификаты в свою очередь могут быть подтверждены корневым Удостоверяющим центром. В свою очередь они могут подтвердить другие сертификаты, образуя цепочку доверия сертификатам. В роли поручителя-удостоверителя выступает Удостоверяющий центр, который выпустил SSL-сертификат по запросу владельца веб-ресурса.

Сертификат и веб-ресурс, для которого он выпущен, удостоверяются электронной цифровой подписью (ЭЦП). Эта подпись указывает на собственную принадлежность сертификата и фиксирует его содержимое, то есть позволяет проверить, не был ли он кем-то изменён после выпуска и подписания.

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

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

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

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

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

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

Сертификационные центры могут выдавать множество SSL-сертификатов, связанных по принципу древовидной структуры. Так, корневой сертификат является корнем дерева, секретным ключом которого подписываются другие сертификаты. Все промежуточные сертификаты, находящиеся на уровень ниже, наследуют степень доверия к нему. SSL-сертификаты, находящиеся далее по структуре, таким же образом получают доверие от Удостоверяющих центров, находящихся выше по цепочке. На примере Удостоверяющего центра Comodo структуру SSL сертификатов можно изобразить следующим образом:

• Корневой сертификат Удостоверяющего центра Comodo: AddTrustExternalCARoot
  • Промежуточные сертификаты: PositiveSSL CA 2, ComodoUTNSGCCA, UTNAddTrustSGCCA, EssentialSSLCA, Comodo High-Assurance Secure Server CA
    • SSL-сертификаты для отдельных доменов.

Общие сведения о типах сертификатов

Платные доверенные сертификаты

Приобретение доверенных сертификатов, за исключением некоторых случаев – это платная услуга.

Где и как купить

В России чаще всего услуга SSL-сертификата предоставляется компаниями – хостингами веб-ресурсов или организациями-партнёрами международных Удостоверяющих центрах. Есть возможность приобретения сертификатов непосредственно у Удостоверяющих центров, но такие сертификаты обычно дороже, чем у партнёров, которые закупают их оптом.

Процедура покупки SSL-сертификата ничем не отличается от приобретения других Интернет-услуг. Общий порядок:

1. Выберите поставщика и перейдите на страницу заказа SSL-сертификатов.
2. Выберите подходящий тип SSL-сертификата и нажмите кнопку покупки.
3. Введите имя вашего домена и выберите вариант защиты — на один домен или Wildcard-сертификат на группу поддоменов.
4. Оплатите услугу любым удобным способом.
5. Продолжите настройку услуги. Могут быть следующие параметры:
   1. Количество доменов, которые защищает сертификат. Один или более.
   2. Поддержка поддоменов.
   3. Скоростью выпуска. Быстрее всего выпускаются сертификаты с валидацией только домена, дольше всего выпускаются сертификаты с EV валидацией.
   4. Количество перевыпусков сертификата — у большинства Удостоверяющих неограниченно. Требуется, если допустили ошибку в данных об организации.
   5. Гарантия – для некоторых сертификатов есть гарантия от 10.000 $. Это гарантия скорее не для покупателя сертификата, а для посетителя сайта, где установлен сертификат. В случае если посетитель сайта с таким сертификатом пострадает от фрода и потеряет деньги, Удостоверяющий центр обязуется компенсировать украденные средства до суммы указанной в гарантии. На практике такие случаи крайне редки.
   6. Бесплатный тестовый период – из платных сертификатов есть у сертификатов Symantec Secure Site, Geotrust Rapidssl, Comodo Positive SSL, Thawte SSL Веб Server. Также существуют бесплатные сертификаты.
   7. Возврат средств – почти у всех сертификатов в течении 30 дней, хотя бывают и сертификаты без периода.

Примерная стоимость

Типы SSL-сертификатов подразделяются по своим свойствам.

1. Обычные SSL-сертификаты. Данные сертификаты выпускаются мгновенно и подтверждают только одно доменное имя. Стоимость: от 20$ в год
2. SGC сертификаты. Сертификаты с поддержкой повышения уровня шифрования. Технология Server Gated Cryptography позволяет в старых браузерах, которые поддерживали только 40 или 56 бит шифрование, повышать принудительно уровень шифрования до 128 бит. Технология решает проблему с криптографией, но не справляется с другими уязвимостями небезопасных браузеров, поэтому ряд корневых Удостоверяющих центров отказываются от данной технологии. Стоимость: от 300 $ в год.
3. Wildcard-сертификаты Обеспечивают шифрование всех поддоменов одного домена по маске. Например, есть домен domain.com и вам нужно установить такой же сертификат на support.domain.com, forum.domain.com и billing.domain.com, можно выпустить сертификат на *.domain.com. В зависимости от количества поддоменов, на которые требуется сертификат, бывает выгодней приобрести отдельно несколько обычных SSL-сертификатов. Примеры wildcard-сертификатов: Comodo PositiveSSL Multi-Domain Wildcard и Comodo Multi-Domain Wildcard SSL Стоимость: от 180$ в год.
4. SAN сертификаты Технология Subject Alternative Name позволяет использовать один сертификат на несколько разных доменов, размещённых на одном сервере. Такие сертификаты могут также называть UCC (англ. Unified Communication Certificate), MDC (англ. Multi-domain certificate) или EC (англ. Exchange certificate). Стандартно один SAN-сертификат включает до 5 доменов, при этом их количество можно увеличивать за дополнительную плату. Стоимость: от 395 $ в год
5. Сертификаты c поддержкой IDN Сертификаты с поддержкой национального домена (англ. International Domain Name, такие как *.RU, *.CN, *.UK). Не все сертификаты могут поддерживать работу IDN. Следует уточнять данную возможность у Удостоверяющего центра. Сертификаты, поддерживающие IDN:
   • Thawte SSL123 Certificate;
   • Thawte SSL Веб Server;
   • Symantec Secure Site;
   • Thawte SGC SuperCerts;
   • Thawte SSL Веб Server Wildcard;
   • Thawte SSL Веб Server with EV;
   • Symantec Secure Site Pro;
   • Symantec Secure Site with EV;
   • Symantec Secure Site Pro with EV.

Как было сказано выше, партнёры Удостоверяющих центров могут предоставлять значительные скидки на цену сертификата, такие предложения могут начинаться от 10 $ либо входить в состав пакетов услуг.

Какие бывают

Сертификаты подразделяются по следующим уровням валидации:

1. DV Domain Validation, или сертификаты с проверкой домена. Удостоверяющий центр проверяет, что клиент, запрашивающий сертификат, контролирует домен, для которого требуется выпустить сертификат, с помощью сетевого сервиса проверки принадлежности веб-ресурсов WHOIS. Данный вид сертификата самый дешёвый и популярный, но не может считаться полностью безопасным, так как содержит только информацию о зарегистрированном доменном имени в поле CN (CommonName – общее доменное имя веб-ресурса).
2. OV Organization Validation, или сертификаты с проверкой организации. Удостоверяющий центр проверяет принадлежность коммерческой, некоммерческой или государственной организации клиенту, который должен предоставить юридическую информацию при покупке. Данный вид сертификатов считается более надёжным, так как отвечает стандартам RFC и подтверждает ещё регистрационные данные компании-владельца в полях:
   • O (Organization – наименование организации);
   • OU (OrganizationalUnit – наименование подразделения организации);
   • L (Locality – наименование населённого пункта юридического адреса организации);
   • S (StateOrProvinceName – наименование территориально-административной единицы юридического адреса организации);
   • C (CountryName – наименование страны организации).

Удостоверяющий центр может связаться напрямую с компанией для подтверждения этой информации. Сертификат содержит информацию о том, кто его подтвердил, но данные о владельце не отображаются. OV-сертификат для частного лица называются IV (Individual Validation, индивидуальная проверка) и проверяет личность человека, запрашивающего сертификат.

3. EV

Extended Validation, или сертификат с расширенной проверкой. Удостоверяющий центр проверяет те же данные, что и OV, но в соответствии с более строгими стандартами, установленными CA/Browser Forum. CA/Browser Forum (англ. Certification Authority Browser Forum) – это добровольный консорциум центров сертификации, разработчиков интернет-браузеров и программного обеспечения для безопасной электронной почты, операционных систем и других приложений с поддержкой PKI. Консорциум публикует отраслевые рекомендации, регулирующие выпуск сертификатов и управление ими. Данный вид сертификатов считается самым надёжным. Ранее в браузерах при использовании данных сертификатов изменялся цвет адресной строки и выводилось наименование организации. Широко используется веб-ресурсами, которые проводят финансовые транзакции и требуют высокий уровень конфиденциальности. Однако многие сайты предпочитают перенаправлять пользователей для совершения платежей на внешние ресурсы, подтверждённые сертификатами с расширенной проверкой, при этом используя сертификаты OV, которых вполне хватает для защиты остальных данных пользователей

Как проходит процесс настройки (общие сведения, что такое CSR)

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

Процедура генерации CSR полностью зависит от программного обеспечения, используемого на вашем сервере, и чаще всего производится с помощью настройки в административной панели вашего хостинга. Если ваш хостинг не предоставляет такой возможности, то можно воспользоваться онлайн-сервисами для генерации CSR запроса либо специализированным ПО, например, OpenSSL, GnuTLS, Networ Security Services и т.д. После генерации CSR будет сформирован и закрытый ключ.

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

• Country Name — страна регистрации организации в двухбуквенном формате. Для Российской Федерации — RU;
• State or Province Name — область, регион регистрации организации. Для Москвы — Moscow;
• Locality Name — город регистрации организации. Для Москвы — Moscow;
• Organization Name — название организации. Для физических лиц указывается «Private Person»;
• Common Name — доменное имя, для которого заказывается сертификат;
• Email Address — адрес электронной почты для связи с администратором. Допустимые значения:
  • admin@имя_домена;
  • administrator@имя_домена;
  • hostmaster@имя_домена;
  • postmaster@имя_домена;
  • вебmaster@имя_домена.

Самоподписанные сертификаты

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

Let’s Encrypt

Let’s Encrypt – Удостоверяющий центр, предоставляющий бесплатные криптографические сертификаты X.509 для шифрования передаваемых через интернет данных HTTPS и других протоколов, используемых серверами в Интернете. Процесс выдачи сертификатов полностью автоматизирован. Сервис предоставляется публичной организацией Internet Security Research Group (ISRG).

Проект Let’s Encrypt создан для перевода большей части интернет-сайтов на HTTPS. В отличие от коммерческих Удостоверяющих центров, в данном проекте не требуется оплата, переконфигурация веб-серверов, использование электронной почты и обработка просроченных сертификатов, что упрощает процессы установки и настройки TLS-шифрования. Например, на типичном веб-сервере на базе Linux требуется выполнить две команды, которые настроят HTTPS-шифрование, получат и установят сертификат примерно за 20-30 секунд.

Корневые сертификаты Let’s Encrypt установлены в качестве доверенных у основных производителей ПО, включая Microsoft, Google, Apple, Mozilla, Oracle и Blackberry.

Центр сертификации Let’s Encrypt выдаёт сертификаты DV со сроком действия в 90 дней. Сертификаты с уровнем подтверждения OV и EV не планируются. Некоторое время назад реализована поддержка Wildcard-сертификатов.

Ключ от корневого сертификата стандарта RSA с 2015 года хранится в аппаратном хранилище HSM (англ. Hardware Security Module), не подключённом к компьютерным сетям. Этим корневым сертификатом подписаны два промежуточных корневых сертификата, которые также были подписаны центром сертификации IdenTrust. Один из промежуточных сертификатов используется для выпуска конечных сертификатов сайтов, второй держится в качестве резервного в хранилище, не подключённом к Интернету, на случай компрометации первого сертификата. Поскольку корневой сертификат центра IdenTrust предустановлен в большинстве операционных систем и браузеров в качестве доверенного корневого сертификата, выдаваемые проектом Let’s Encrypt сертификаты проходят проверку и принимаются клиентами, несмотря на отсутствие корневого сертификата ISRG в списке доверенных.

Для автоматической выдачи сертификата конечному сайту используется протокол аутентификации Automated Certificate Management Environment (ACME). В этом протоколе к веб-серверу, запросившему подписание сертификата, производится серия запросов для подтверждения факта владения доменом (DV). Для получения запросов клиент ACME настраивает специальный TLS-сервер, который опрашивается сервером ACME с применением Server Name Indication (Domain Validation using Server Name Indication, DVSNI). Валидация проводится многократно, с использованием различных сетевых путей. Записи DNS опрашиваются из множества географически распределённых мест для предотвращения атак DNS spoofing, когда данные кэша доменных имён изменяются злоумышленником с целью возврата ложного IP-адреса и переадресации посредника на ресурс злоумышленника (или любой другой ресурс в сети)

Платные доверенные сертификаты

Использование на Windows Server и IIS

Какие форматы приватного ключа бывают

Существуют следующие форматы приватного ключа:

1. PEM-формат

Этот формат чаще всего используется Удостоверяющими центрами. PEM сертификаты чаще всего имеют расширения *.pem, *.crt, *.cer или *.key (для закрытых ключей) и другие. Например, файл пакета SSL.com CA, доступный в таблице загрузок в порядке сертификата, имеет расширение *.ca-bundle. Содержимое файлов зашифровано с помощью Base64 и содержит строки «—–BEGIN CERTIFICATE—–» и «—–END CERTIFICATE—–».

Данный формат сертификатов распространён в ОС Linux. Несколько PEM сертификатов и даже приватный ключ могут быть включены в один файл, один под другим. Но большинство серверов, таких как Apache, ожидает, что сертификат и приватный ключ находятся в разных файлах.

2. PKCS#7/P7B формат

Формат PKCS#7 или P7B сертификаты обычно сохраняются в формате Base64 ACVII и имеют расширение *.p7b или *.p7c. Сертификат P7B содержит строки «—–BEGIN PKCS7—–» и «—–END PKCS7—–». Этот формат содержит только сертификат и цепочку сертификатов, но не приватный ключ. Несколько распространённых платформ поддерживают этот формат, включая Microsoft Windows и Java Tomcat.

3. PKCS#12/PFX формат

Формат PKCS#12 или PFX – это бинарный формат для сохранения сертификата, любых промежуточных сертификатов и приватного ключа в один зашифрованный файл. PFX файлы обычно сохраняются с расширением *.pfx или *.p12. Как правило, этот формат используется на Windows сертификатах для экспорта/импорта сертификата и приватного ключа2.

Как сгенерировать CSR запрос

Для генерации CSR-запроса в IIS 10 выполните следующие операции.

1. Запустите IIS из командной строки iis.msc или из визуального интерфейса.
2. Выберите в списке Connections свой сервер и кликните по кнопке Server Certificates.

3. На странице Server Certificates кликните в блоке Actions ссылку Create Certificate Request….

4. В окне Request Certificate мастера заполните поля CSR и нажмите кнопку Next:

5. В окне Cryptographic Service Provider Properties мастера выберите требуемый криптопровайдер, в зависимости от нужного алгоритма, и длину ключа, после чего нажмите кнопку Next:

6. В окне File Name мастера укажите путь к создаваемому CSR, после чего нажмите кнопку Finish:

Для отправки созданного CSR в Удостоверяющий центр откройте получившийся файл в текстовом редакторе и скопируйте содержимое в веб-форму поставщика сертификатов.

Как создать приватный ключ

В результате создания CSR приватный ключ будет создан автоматически средствами IIS. Просмотр доступен на оснастке консоли Certificates в пунктах Personal или Веб Hosting дерева сертификатов.

Оснастка может быть скрыта в консоли. Чтобы её добавить, выполните в Start menu > Run команду mmc и в появившемся окне добавьте оснастку Certificates в список доступных на локальной машине:

Как его экспортировать

Для экспорта приватного ключа с целью резервного копирования или настройки нового сервера выполните следующие действия:

1. Найдите в оснастке Certificates консоли управления созданный сертификат, кликните правой кнопкой мыши по нему, в появившемся контекстном меню кликните по пункту меню All Tasks > Export:

2. В окне Welcome to the Certificate Export Wizard мастера Certificate Export Wizard нажмите Next и далее в окне Export Private Key установите переключатель в положение Yes, export the private key, после чего нажмите кнопку Next:

3. В окне Export File Format мастера выберите тип пункт Personal Information Exchange – PKCS #12 (.PFX) и установите чекбокс Include all certificates in the certification path if possible., после чего нажмите кнопку Next. Будьте внимательны, если чекбокс Delete the private key if the export is successful будет отмечен, то созданный приватный ключ на текущем сервере будет удалён после экспорта:

4. В окне Security мастера поставьте чекбокс Password и дважды введите пароль для защиты приватного ключа. Он потребуется при последующем импорте. Дополнительно рекомендуется ограничить пользователей или группы Active Directory, которые имеют возможность использовать приватный ключ. Для этого поставьте чекбокс Group or user name и выберите требуемые группы или пользователей, после чего нажмите кнопку Next:

5. В окне File to Export мастера укажите путь к экспортируемому файлу с приватным ключом и его имя. Для этого введите его вручную или воспользуйтесь системным диалоговым окном поиска файла, после чего нажмите кнопку Next:

6 В окне File to Export мастера укажите путь к экспортируемому файлу с приватным ключом и его имя. Для этого введите его вручную или воспользуйтесь системным диалоговым окном поиска файла, после чего нажмите кнопку Next. В следующем окне Completing the Certificate Export Wizard будет приведён перечень установленных настроек. Нажмите в нём кнопку Finish. Экспортированный файл появится в указанной директории.

Как настроить SSL на IIS

Для настройки SSL в IIS выполните следующие действия:

1. Запустите IIS из командной строки iis.msc или из визуального интерфейса.
2. Выберите в списке Connections свой сервер и кликните по ссылке Bindings… в блоке Actions.

3. В окне Site Bindings нажмите кнопку Add.

4. В окне Add Site Bindings заполните следующие поля и нажмите кнопку OK:

• IP address – выберите в выпадающем списке IP-адреса серверов, с которыми нужно связать сертификат или нажмите кнопку All Unassigned для связывания сертификата со всеми серверами.
• Port – оставьте значение 443. Это стандартный порт SSL.
• SSL certificate – в выпадающем списке выберите нужный SSL-сертификат.

Настройка закончена, можно проверять работу веб-сервиса. Если приватный ключ отсутствует, то импортируйте его в оснастке Certificates консоли управления. Для этого выберите нужный ресурс, кликните правой кнопкой мыши по нему, в появившемся контекстном меню кликните по пункту меню All Tasks > Import, далее следуйте инструкциям мастера.

Использование на Linux

Как создать приватный ключ

Созданный приватный ключ может быть получен в интерфейсе поставщика SSL-сертификатов после отправки CSR или с помощью специализированного ПО, например, OpenSSL.

Ниже приведён фрагмент генерации приватного ключа в веб-интерфейсе поставщика SSL-сертификатов.

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

Чтобы создать приватный ключ RSA с помощью OpenSSL, достаточно одной команды:

openssl genrsa -out rsaprivkey.pem 2048

Это команда генерирует закрытый ключ PEM и сохраняет его в файле rsaprivkey.pem. В нашем примере создается ключ размером 2048 бит, который подойдёт почти для всех ситуаций.

Для создания ключа DSA необходимо выполнить два шага:

openssl dsaparam -out dsaparam.pem 2048
openssl gendsa -out dsaprivkey.pem dsaparam.pem

На первом шаге создаётся файл параметров DSA (dsaparam.pem), который в данном случае содержит инструкции для OpenSSL по созданию на шаге 2 ключа размером 2048 бит. Файл dsaparam.pem не является ключом, поэтому его можно удалить после создания открытого и закрытого ключей. На втором шаге генерируется закрытый ключ (файл dsaprivkey.pem), который необходимо хранить в секрете.

Для создания файла в формате PKCS#12, используемом в ОС Windows, воспользуйтесь следующей командой:

openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt

Где:

• pkcs12 – формат приватного ключа;
• export – операция экспорта приватного ключа в требуемый формат;
• out – каталог в файловой системе, куда должен быть размещён результирующий файл;
• inkey – файл приватного ключа в формате PEM;
• in – файл сертификата, полученный от Удостоверяющего центра;
• certfile – копия корневого сертификата и промежуточных сертификатов в цепочке. На примере выше они отсутствуют.

Как сгенерировать CSR запрос

Чтобы сгенерировать CSR, в веб-форме поставщика услуги SSL-сертификата заполните предлагаемые поля. На рисунке выше указан пример заполнения. Набор минимально необходимых полей одинаковый и приведён в разделе про описание CSR, но некоторые поставщики могут добавлять свои либо изменять способ ввода.

Для генерации CSR средствами OpenSSL воспользуйтесь следующей командой:

openssl req -new -key private.key -out domain_name.csr -sha256

Где:

• new – создание нового CSR-запроса посредством прямого ввода в консоли. Без данной опции будут использоваться данные конфигурационного файла OpenSSL;
• key – наименование приватного ключа, требуемого для генерации. Если опция не указана, будет создан новый приватный ключ в соответствии с алгоритмом по умолчанию;
• out – путь к создаваемому CSR-файлу;
• sha256 – алгоритм шифрования.

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

Затем отправьте полученный CSR Удостоверяющему центру. В ответ он должен вернуть персональный сертификат.

Как настроить SSL для Apache

Для настройки SSL в Apache выполните следующие действия:

1. Добавьте в каталог /etc/ssl/ персональный сертификат, выданный Удостоверяющим центром, приватный ключ и корневой сертификат вместе с остальными сертификатами цепочки
2. Откройте файл конфигурации Apache любым текстовым редактором, например, vim. В зависимости от ОС сервера файл может находиться по одному из следующих расположений:

• для CentOS: /etc/httpd/conf/httpd.conf;
• для Debian/Ubuntu: /etc/apache2/apache2.conf;

3. Если вы устанавливаете SSL-сертификат на OpenServer, используйте путь к его корневой папке. В конце файла создайте копию блока «VirtualHost». Укажите для блока порт 443 и добавьте внутри следующие строки:

SSLEngine on
SSLCertificateFile /etc/ssl/domain_name.crt
SSLCertificateKeyFile /etc/ssl/private.key
SSLCertificateChainFile /etc/ssl/chain.crt

4. Проверьте конфигурацию Apache до перезапуска командой: apachectl configtest, после чего перезапустите Apache.

Как настроить SSL для Nginx

Для настройки SSL в Nginx выполните следующие действия:

1. Откройте текстовый редактор и добавьте туда содержание персонального сертификата, выданного Удостоверяющим центром и корневого сертификата вместе с остальными сертификатами цепочки. Полученный файл должен иметь вид:

2. Сохраните полученный файл с расширением *.crt в каталог /etc/ssl/. Обратите внимание: один сертификат идёт следом за другим, без пустых строк.
3. Сохраните файл your_domain.key с приватным ключом сертификата в каталог /etc/ssl.
4. Откройте конфигурационный файл Nginx и отредактируйте виртуальный хост вашего сайта, который вы хотите защитить сертификатом. Выполните минимальную для работы настройку, добавив в файл следующие строки:

server {
listen 443 ssl;
server_name your_domain.com;
ssl_certificate /etc/ssl/your_domain.crt;
ssl_certificate_key /etc/ssl/your_domain.key;
}

Где:

• your_domain.com — доменное имя сайта;
• /etc/ssl/your_domain.crt — путь до созданного файла с тремя сертификатами;
• /etc/ssl/your_domain.key — путь до файла с приватным ключом.

Название файлов и каталогов могут быть произвольными.

Дополнительно можно настроить работу сайта по HTTP, тип кэша сервера, таймаут обновления кэша, а также время работы одного keepalive-соединения. Также можно настроить поддерживаемые протоколы и их приоритет (серверный набор или клиентский) и OCSP-ответы для валидации сертификата. Детали приведены в руководстве пользователя Nginx.

5. Чтобы изменения вступили в силу, перезапустите сервер Nginx:

sudo /etc/init.d/nginx restart

Самоподписанные сертификаты

Использование на Windows Server и IIS

Как создать приватный ключ

Создать приватный ключ можно при помощи IIS, создав CSR и завершив его выполнение по инструкции выше.

Как создать корневой самоподписанный сертификат

Для генерации корневого самоподписанного сертификата в IIS 10 выполните следующие операции.

Запустите IIS из командной строки iis.msc или из визуального интерфейса. Выберите в списке Connections свой сервер и кликните по кнопке Server Certificates. На странице Server Certificates кликните в блоке Actions ссылку Create Domain Certificate в блоке Actions.

4. В окне Distinguished Name Properties мастера Create Certificate заполните поле Common name (имя сервера, указываемое в браузере), остальные поля, как при создании CSR, и нажмите кнопку Next:

5. В окне Online Certification Authority мастера укажите в поле Specify Online Certification Authority репозиторий, куда нужно разместить корневой сертификат. В поле Friendly name укажите наименование сертификата, после чего нажмите кнопку Finish:

Как создать SSL-сертификат, подписанный корневым

Для генерации самоподписанного SSL-сертификата в IIS 10 выполните следующие операции:

1. Запустите IIS из командной строки iis.msc или из визуального интерфейса.
2. Выберите в списке Connections свой сервер и кликните по кнопке Server Certificates.
3. На странице Server Certificates кликните в блоке Actions ссылку Create Self-Signed Certificate в блоке Action

4. В окне Create Self-Signed Certificate в поле Friendly name укажите наименование сертификата, в поле Select a certificate store for the new certificate выберите репозиторий, куда нужно разместить создаваемый самоподписанный сертификат, и нажмите кнопку ОK:

Как настроить IIS для самоподписанного сертификата

Настройка IIS для самоподписанного сертификата выполняется так же, как и для сертификата, выпущенного Удостоверяющим центром.

Использование на Linux

Как создать приватный ключ

Создание приватного ключа при помощи команды genrsa и других аналогичных в OpenSSL описано выше.

Как создать корневой самоподписанный сертификат

Для генерации корневого самоподписанного сертификата в OpenSSL выполните следующую команду:

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem

Где:

• key – приватный ключ, созданный ранее;
• out – файл корневого сертификата;
• days – количество дней действия сертификата, начиная с текущих суток

Как создать SSL-сертификат, подписанный корневым

Для генерации самоподписанного SSL-сертификата в OpenSSL выполните следующие действия:

1. Создайте CSR в соответствии с инструкцией выше.
2. Выпустите самоподписанный сертификат:

openssl x509 -req -in org.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out org.crt -days 365 -sha256

Где:

• req – создать запрос на подпись;
• in – файл CSR-запроса;
• CA – файл корневого сертификата;
• CAkey – приватный ключ корневого сертификата;
• out – выходной CRT-файл;
• days – количество дней действия.

Как настроить Apache для самоподписанного сертификата

Настройка Apache для самоподписанного сертификата выполняется так же, как и для сертификата, выпущенного Удостоверяющим центром.

Как настроить Nginx для самоподписанного сертификата

Настройка Nginx для самоподписанного сертификата выполняется так же, как и для сертификата, выпущенного Удостоверяющим центром.

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

На Windows

Для добавления самоподписанного сертификата в доверенные выполните следующие действия:

1. Найдите в оснастке Certificates консоли управления репозиторий доверенных сертификатов, кликните правой кнопкой мыши по нему, в появившемся контекстном меню кликните по пункту меню All Tasks > Import:

2. В окне Welcome to the Certificate Import Wizard мастера Certificate Import Wizard нажмите Next и далее в окне File to Import укажите путь к импортируемому файлу с самоподписанным сертификатом. Для этого введите его вручную или воспользуйтесь системным диалоговым окном поиска файла, после чего нажмите кнопку Next:

3. В окне Private key protection мастера введите пароль, указанный при создании самоподписанного сертификата, установите чекбоксы Mark this key as exportable для разрешения дальнейшего экспорта сертификата с целью резервного копирования, и Include all extended properties, после чего нажмите кнопку Next. Дальнейший экспорт будет работать только в том случае, если приватный ключ будет доступен.

4. В окне Certificate Store мастера поставьте переключатель Place all certificates in the following store выберите репозиторий Trusted Root Certification Authorities, после чего нажмите кнопку Next. В следующем окне Completing the Certificate Import Wizard будет приведён перечень установленных настроек. Нажмите в нём кнопку Finish. Импортированный файл появится в указанном репозитории.

На MacOS

Для добавления самоподписанного сертификата в доверенные выполните следующие действия:

1. Откройте приложение Keychain Access, кликнув по пиктограмме ниже, и перейдите в пункт меню All Items:

2. Найдите с помощью Finder`а файл самоподписанного сертификата (*.pem, *.p12 или другой).
3. Перетащите файл в левую часть окна Keychain Access .

4. Перейдите в пункт меню Certificates, найдите добавленный самоподписанный сертификат и дважды кликните по нему.
5. Кликните по кнопке Trust в выпадающем меню и установите значение поля When using this certificate с System Defaults на Always Trus

На Linux

Для добавления самоподписанного сертификата в доверенные в ОС Linux (Ubuntu, Debian) выполните следующие действия:

1. Скопируйте файл корневого самоподписанного сертификата в каталог /usr/local/share/ca-certificates/. Для этого выполните команду sudo cp foo.crt /usr/local/share/ca-certificates/foo.crt, где foo.crt – файл персонального сертификата.
2. Выполните команду sudo update-ca-certificates

Для добавления самоподписанного сертификата в доверенные в ОС Linux (CentOS 6) выполните следующие действия:

1. Установите корневые сертификаты при помощи команды: yum install ca-certificates.
2. Включите режим динамической конфигурации корневых сертификатов: update-ca-trust force-enable.
3. Добавьте файл сертификата в каталог /etc/pki/ca-trust/source/anchors/: cp foo.crt /etc/pki/ca-trust/source/anchors/.
4. Выполните команду: update-ca-trust extract.

На iOS

Для добавления самоподписанного сертификата в доверенные выполните следующие действия:

1. Установите любой веб-сервер и поместите файл сертификата в корень каталога приложения.
2. Перейдите по URL веб-сервера, после чего файл будет скачан в профиль текущего пользователя.
3. Откройте меню Profiles и нажмите кнопку Install.
4. Перейдите в настройки Settings > General > About-> Certificate trust settings и установите переключатель для сертификата в положение включено.

На Android

Для добавления самоподписанного сертификата в доверенные в выполните следующие действия:

1. Скачайте файл в память устройства.
2. Перейдите в меню Settings > Security > Credential storage и тапните по пункту Install from device storage.

3. Найдите скачанный *.crt и введите в поле Certificate name его наименование. После импорта сертификат будет отображаться в меню Settings > Security > Credential storage > Trusted credentials > User.

Добавление корневого сертификата в доверенные в групповых политиках Windows AD

Для добавления корневого сертификата в доверенные в групповых политиках Windows Active Directory выполните следующие операции.

1. Запустите оснастку управления групповыми из командной строки gpmc.msc.
2. Выберите требуемый домен, кликните правой кнопкой мыши по нему и выберите пункт Create a GPO in this domain and link it here.

3. Укажите наименование групповой политики в появившемся окне и нажмите кнопку ОК.

4. Кликните правой кнопкой мыши по созданной групповой политике и нажмите кнопку Edit…. На появившемся экране перейдите в пункт Computer configuration > Policies > Administrative Templates > Windows Components > Windows Update. Выберите пункт Allow signed content from intranet Microsoft update service location и кликните Edit policy settings.

5. Установите переключатель в положение Enabled и нажмите ОК.

6. Перейдите в раздел Computer Configuration>Windows Settings>Security Settings>Public Key Policies и импортируйте нужный сертификат в доверенные в соответствии с инструкцией выше.
7. Повторите пункт 4 и закройте редактор групповых политик. Политика будет применена через какое-то время. Чтобы применить её незамедлительно, выполните в командной строке gpupdate /force.

Let’s Encrypt

Использование на Windows Server и IIS

Как выпустить сертификат

Для установки сертификата Let’s Encrypt на сервере должен быть установлен ACME-клиент. Для Windows распространены следующие реализации:

• Утилита Windows ACME Simple (WACS) – утилита командной строки для интерактивного выпуска сертификата и привязки его к определенному сайту на вашем веб сервере IIS;
• Модуль Powershell ACMESharp – библиотека Powershell с множеством команд для взаимодействия через ACME API с серверами Let’s Encrypt;
• Certify – графический менеджер SSL-сертификатов для Windows, позволяет интерактивно управлять сертификатами через ACME API.

Чтобы выпустить сертификат Let’s Encrypt с помощью WACS, выполните следующие действия:

1. Скачайте последний релиз клиента WACS со страницы проекта на GitHub https://github.com/PKISharp/win-acme/releases и распакуйте в каталог на сервере.
2. Откройте командную строку и запустите клиент wacs.exe из указанного расположения.
3. Нажмите клавишу N. Это создаст сертификат для IIS.

4. Выберите тип сертификата: DV для одного домена, DV всех доменов в IIS (SAN), доменов соответствующих Wildcard либо ручного списка доменов в IIS.

5. В зависимости от выбора WACS.exe выведет список сайтов, запущенных на сервере IIS, и предложит выбрать сайт, для которого нужно создать и привязать новый SSL-сертификат.
6. После выбора укажите адрес электронной почты, на который будут отправляться уведомления о проблемах с обновлением сертификата сайта и другие оповещения (можно указать несколько адресов через запятую).

Согласитесь с условиями использования, нажав клавишу Y, после чего Windows ACME Simple подключится к серверам Let’s Encrypt и попытается автоматически сгенерировать новый SSL-сертификат для вашего сайта.

Как настроить IIS для Let’s Encrypt сертификата

Утилита WACS сохраняет закрытый ключ сертификата (*.pem), сам сертификат и ряд других файлов в каталог C:\Users\%username%\AppData\Roaming\letsencrypt-win-simple. Затем она в фоновом режиме установит сгенерированный SSL-сертификат Let’s Encrypt и привяжет его к вашему сайту IIS.

Более подробно см. здесь https://www.win-acme.com/manual/getting-started

Использование на Linux

Как выпустить сертификат

Для установки сертификата Let’s Encrypt на сервере должен быть установлен ACME-клиент. Для Linux это утилита Certbot.

Чтобы выпустить сертификат Let’s Encrypt с помощью Certbot, выполните следующие действия:

1. Установите Certbot в соответствии с инструкциями на сайте https://certbot.eff.org/ на сервер.
2. Выполните команду выпуска сертификата: certbot —nginx или certbot —apache. При первом запуске может потребоваться ввод адреса электронной почты, на который будут отправляться уведомления о проблемах с обновлением сертификата сайта и другие оповещения

Certbot проанализирует в конфигурационных файлах веб-сервера директиву ServerName, соответствующую доменному имени, для которого вы запросите сертификат. Если нужно указать несколько доменов или wildcard, то используйте ключ командной строки -d.

Более подробно см. здесь https://certbot.eff.org/instructions

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

Продление сертификатов для Linux и Windows

Платные доверенные

При продлении срока действия сертификата SSL/TLS рекомендуется создавать новый CSR-запрос. Генерирование нового запроса создаст новую уникальную пару ключей (открытый/частный) для обновлённого сертификата.

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

Самоподписанный

Самоподписанные сертификаты продлеваются повторным созданием и настройкой веб-сервера в соответствии с инструкциями, описанными выше.

Let’s Encrypt

На Windows

Windows ACME Simple создаёт новое правило в планировщике заданий Windows под названием win-acme-renew для автоматического продления сертификата. Задание запускается каждый день, а непосредственно продление сертификата выполняется через 60 дней. При продлении планировщик запускает команду:

C:\<путь к каталогу WACS>\wacs.exe --renew --baseuri "https://acme-v02.api.letsencrypt.org"

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

На Linux

Чтобы продлить сертификат через certbot, необходимо выполнить следующую команду:

certbot Renew --force-Renewal

Для указания конкретного домена нужно использовать параметр -d.

Тестирование

Сервисы (SSL Checkers), которые позволяют проверить настойки SSL на публичном сервере

Проверка SSL осуществляется при помощи онлайн-сервисов, предоставляемых Удостоверяющими центрами, а также сторонними разработчиками:

• https://ssltools.вебsecurity.symantec.com/checker/views/certCheck.jsp
• https://www.wormly.com/test_ssl
• http://www.digicert.com/help/
• http://www.sslshopper.com/ssl-checker.html
• https://sslcheck.globalsign.com/en_US
• https://www.ssllabs.com/ssltest/
• https://www.htbridge.com/ssl/
• https://sslanalyzer.comodoca.com/
• https://www.sslchecker.com/sslchecker

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

Проверка всей цепочки сертификатов

Проверка всей цепочки сертификатов осуществляется инструментами SSL Shopper, Symantec SSL Toolbox и SSL Checker. Ссылки приведены выше.

Проверка на iOS (через специальное приложение)

Чтобы проверить сертификаты на устройствах iOS, установите приложение SSL Checker с App Store. С помощью данного приложения можно проверить текущий статус и срок действия SSL-сертификата любого сервера, включая самоподписанные сертификаты. Приложение может обнаруживать изменения в параметрах сертификата и направлять уведомления об этом.

Проверка на Android

Чтобы проверить сертификаты на устройствах под управлением ОС Android, установите приложение SSL Certificate Checker из Google Play. С помощью данного приложения можно проверить текущий статус и атрибуты SSL-сертификата любого сервера, включая цепочку сертификатов.