- Что происходит по истечении срока действия ssl-сертификата?
- Планирование имён цс
- Состав списков отзыва
- Каким образом в электронный сертификат вписать свои имя и фамилию? – виктория сухорукова, секретарь сонко
- Планирование аппаратных требований
- Описание политик
- Общие вопросы планирования
- Как обеспечить безопасность онлайн-сеанса
- Extended validation
- Шаг 1. предварительные изыскания и проверка гипотезы
- Как работают ssl-сертификаты?
- Шаг 3. разработка парсера x.509 сертификата на с#
- Программирование политик
- Что такое ssl-сертификат?
- Как получить ssl-сертификат
- Можно ли использовать ssl-сертификат на нескольких серверах?
- Какой ssl-сертификат выбрать?
- Подведение итогов
- Зачем нужен ssl-сертификат
- Сертификаты, подтверждающие организацию (ov ssl)
- Построение диаграммы pki
- Самоподписные ssl-сертификаты
- Wildcard-сертификаты
- Об авторе
- Organization validation
- Каким сайтам нужен ssl?
- Безопасность данных
Что происходит по истечении срока действия ssl-сертификата?
Срок действия SSL-сертификатов истекает, он не длится вечно. Центр сертификации / Форум браузеров, который де-факто выступает в качестве регулирующего органа для индустрии SSL, заявляет, что срок действия SSL-сертификатов не должен превышать 27 месяцев.
Срок действия SSL-сертификатов истекает, поскольку, как и при любой другой форме аутентификации, информацию необходимо периодически перепроверять и убеждаться в ее актуальности. В интернете все очень быстро меняется, покупаются и продаются компании и веб-сайты.
Раньше SSL-сертификаты могли выдаваться на срок до пяти лет, который впоследствии был сокращен до трех лет, а в последнее время до двух лет плюс возможность использовать дополнительные три месяца. В 2020 году Google, Apple и Mozilla объявили, что будут применять годовые SSL-сертификаты, несмотря на то, что это предложение было отклонено Центрами сертификации / Форумом браузеров.
Когда срок действия SSL-сертификата истекает, соответствующий сайт становится недоступным. Когда пользователь открывает веб-сайт в браузере, в течение нескольких миллисекунд проверяется действительность SSL-сертификата (в рамках подтверждения SSL-соединения).
У пользователей есть возможность продолжить, однако не рекомендуется делать это, учитывая связанные риски кибербезопасности, в том числе вероятность столкнуться с вредоносными программами. Это существенно влияет на показатель отказов при посещении веб-сайта, поскольку пользователи быстро покидают его.
Осведомленность о сроке истечения SSL-сертификатов является проблемой для крупных предприятий. В то время как малые и средние предприятия имеют один или несколько SSL-сертификатов, крупные предприятия, работающие на различных рынках и имеющие множество веб-сайтов и сетей, имеют также множество SSL-сертификатов.
Поэтому причиной того, что компания допустила истечение срока действия своего SSL-сертификата, обычно является недосмотр, а не отсутствие компетентности. Лучший способ для крупных компаний поддерживать осведомленность об истечении срока действия SSL-сертификатов – использовать платформу управления сертификатами.
На рынке представлены различные продукты, которые можно найти с помощью онлайн-поиска. Это позволит компаниям просматривать цифровые сертификаты и управлять ими в рамках всей инфраструктуры. При использовании такой платформы важно регулярно входить в систему и проверять, когда необходимо продлить обновления.
Если срок действия сертификата истечет, сертификат станет недействительным, и выполнять безопасные транзакции на веб-сайте станет невозможно. Центр сертификации предложит обновить SSL-сертификат до истечения срока его действия.
Все центры сертификации и службы SSL, используемые для получения SSL-сертификатов, отправляют уведомления об истечении срока действия сертификата с заданной периодичностью, обычно начиная с 90 дней до окончания срока действия сертификата. Постарайтесь, чтобы эти уведомления отправлялись на несколько адресов электронной почты, а не одному человеку, который к моменту отправки уведомления может покинуть компанию или перейти на другую должность. Убедитесь, что соответствующие сотрудники компании включены в список рассылки и своевременно получат уведомление.
Планирование имён цс
Имя ЦС – это имя, которое будет отображено в поле
Subject
конкретного ЦС. Не путать с именем хоста, на котором работает служба сертификатов. Полное имя ЦС будет состоять из двух компонентов, самого имени (атрибут CN или Common Name) и опционального суффикса в формате X.500. По умолчанию ADCS назначает имя в следующем формате:
Для Standalone CA: <ComputerName>-CA
Для Enterprise CA: <DomainShortName>-<ComputerName>-CA, <X500DomainSuffix>
Хорошо это или плохо? Технически, вы можете выбрать любое имя, функционально оно ни на что влиять не будет. Есть мнение, что имя вашего ЦС является в некотором роде визитной карточкой вашей PKI, отражая ваше отношение к деталям, которые не имеют непосредственного отношения к функциональности, но обеспечивают достаточный уровень информативности и открытости. Поэтому при выборе полного имени сертификата следует руководствоваться несколькими рекомендациями:
Предположим, что вы подбираете имя для корневого ЦС компании Contoso Pharmaceuticals Ltd., которая находите в городе Рига, Латвия и управление обеспечивается отделом информационных технологий. В этом случае имя ЦС может иметь следующий вид:
CN=Contoso Pharm Root Certification Authority, OU=Division Of IT (DoIT), O=Contoso Pharmaceuticals Ltd., L=Riga, C=LVСледует помнить, что атрибут Country поддерживает только двухбуквенный индекс страны. Например, LV, GB, RU, US и т.д. В качестве дополнительных примеров, можете обратиться к сертификатам ЦС коммерческих провайдеров, как VeriSign/Symantec, DigiCert и т.д.
Для подчинённого ЦС это имя будет похожим, за исключением того, что слово Root в имени будет заменено на Subordinate или Issuing. В случае трёхуровневой иерархии, где явно выделяется ЦС политик, слово Root будет заменено на Policy. Как я выше отмечал, в вашей компании могут применяться другие правила, и вы можете их внедрить в имена ЦС, на функциональность это влиять не будет. При этом следует избегать:
- Чрезмерно длинных имён в атрибуте CN (не более 50 символов). При длине атрибута CN свыше 51 символа, оно будет укорочено с пристыковкой хэша отброшенного фрагмента имени в конец имени. Это называется процессом «санитизации» имени, который описан в §3.1.1.4.1.1 протокола [MS-WCCE]. Т.е. может случиться так, что при слишком длинном имени слово оборвётся на середине и будет иметь неприглядный вид.
- Использовать буквы, которые не входят в состав латинского алфавита, т.е. никакой криллицы или диактрических букв (например, ā, ž, Ü, ẞ). ADCS поддерживает только однобайтовые кодировки для атрибута CN и для ограниченного набора символов. Неподдерживаемые символы будут преобразованы в другую кодировку и станут нечитаемыми. Полный список запрещённых символов представлен в §3.1.1.4.1.1.2 протокола [MS-WCCE]. Здесь работает принцип «лучшее – враг хорошему», поэтому имена должны быть достаточно лаконичными и информативными.
Состав списков отзыва
Перед планированием состава и срока действия списков отзыва необходимо понять назначение списков отзыва и оптимальные параметры в зависимости от условий их эксплуатации. Как известно, каждый ЦС периодически публикует списки отзывов, которые включают списки всех отозванных конкретным ЦС сертификатов.
Даже при наличии высокоскоростных подключений трафик списков отзыва будет существенным по размеру, т.к. все потребители сертификатов нуждаются в актуальной версии списка отзыва. Для уменьшения трафика списков отзыва предусматривают публикацию двух типов CRL:
базовый (Base CRL) и дифференциальные (Delta CRL). Базовый список включает полный список отзыва. Дифференциальный список включает в себя только список отозванных сертификатов, которые были отозваны с момента последней публикации базового CRL. Это позволяет вам публиковать базовый список реже и на более длительный срок, а для ускорения времени реакции клиентов на отозванные сертификаты в промежутке выпускать несколько короткоживущих дифференциальных CRL.
Подбор параметров зависит от несколько факторов. Например, планируемый объём издаваемых сертификатов и планируемый объём отзыва. Рассмотрим типовые сценарии.
Корневой ЦС
Корневой ЦС выписывает сертификаты только промежуточным ЦС, количество которых обычно в пределах десятка. Срок действия промежуточных ЦС сопоставим со сроком жизни сертификата корневого ЦС. Также предполагается, что риск отзыва нижестоящих ЦС весьма низкий, поскольку они управляются обученным персоналом и в отношении них обеспечиваются надлежащие меры безопасности.
Справка: как посчитать планируемый размер файла CRL исходя из объёмов отзыва? Типичный пустой CRL занимает примерно 600-800 байт. Каждая запись об отозванном сертификате занимает 88 байт. Исходя из этих значений можно высчитать размер CRL в зависимости от количества отозванных сертификатов.
Отсюда следует, что на протяжении всей жизни корневого ЦС список отзыва будет в пределах 1кб и смысла в дифференциальном CRL нет.
Издающий ЦС
Для издающего ЦС картина меняется. Объём издаваемых сертификатов уже высок, он может составлять тысячи и миллионы штук. Потребителями являются пользователи и устройства, которые обладают высоким риском отзыва, поскольку они не находятся под постоянным контролем квалифицированного персонала, и невозможно обеспечить надлежащие меры.
Как следствие, список отзыва может достигать серьёзных размеров. Например, если заложить 10% риск отзыва, то на миллион изданных сертификатов приходится порядка 100к отозванных. 100к записей по 88 байт будет составлять немногим меньше 10мб. Очень часто обновлять файл на 10мб не очень практично, целесообразней его публиковать реже, а в интервале между публикациями основного CRL распространять несколько облегчённых дифференциальных Delta CRL. Т.е. если для корневого ЦС достаточно только базового списка отзыва, то для ЦС, выпускающих сертификаты конечным потребителям, следует применять и дельты.
Каким образом в электронный сертификат вписать свои имя и фамилию? – виктория сухорукова, секретарь сонко

В последнее время мы всё чаще попадаем в ситуацию, когда, по итогам участия в каком-либо онлайн мероприятии, получаем электронный сертификат или диплом, в котором не указаны наши имя и фамилия.
Большинство таких документов рассылаются по электронной почте либо иным способом и представляют собой файл, одного из графических форматов, содержащий красивый бланк с печатью, на котором написано, что это за документ, например, сертификат участника, кто и когда его выдал, печать и подпись организации и иную информацию за исключением имени и фамилии получателя.
Современные технологии позволяют исправить этот недочёт при помощи графического редактора либо программы, предназначенной для создания и редактирования презентаций.
Наиболее простой, на наш взгляд, способ внесения нужной информации – воспользоваться графическим редактором «Paint», который поставляется с любой версией операционной системы Windows для персонального компьютера.
– Перед тем, как начать манипуляции с файлом, сделайте его резервную копию;
– В меню Пуск, чаще всего в папке Стандартные, отыщите программу Paint и запустите её;
– Кликните по кнопке «Файл» и, в появившемся меню, выберите пункт «Открыть»;
– Выберите файл с сертификатом и откройте его;
– Удерживая клавишу CTRL, вращайте колесо мышки так, чтобы та область, куда необходимо впечатать ваши данные, занимала достаточно комфортную позицию на экране компьютера;
– На панели инструментов, нажмите кнопку «Текст»;
– Подведите курсор к полю, куда необходимо вписать имя и фамилию, либо иную информацию, и, однократно, нажмите левую кнопку мыши;
– На экране появится прямоугольная область, в которую, при помощи клавиатуры ПК, напечатайте необходимые данные;
– Прежде, чем начать ввод текста, используя стрелки, находящиеся по углам и по середине каждой из сторон появившегося фрейма, при помощи мышки, растяните его так, чтобы границы совпадали с краями того места, куда нужно вписать информацию;
– После ввода данных, выделите их, и отрегулируйте отступы, размер шрифта, его начертание и цвет так, чтобы они эстетично смотрелись в документе.
Обратите внимание на то, что как только вы кликнули мышкой за пределами фрейма, предназначенного для ввода текста, все изменения будут сохранены автоматически и, для их удаления, придётся начать процесс заполнения, сначала.
Планирование аппаратных требований
Службы сертификатов AD CS в целом нетребовательны к аппаратным ресурсам (на фоне других серверных служб). Основная нагрузка ложится на центральный процессор для выполнения криптографических операций (хэширование, шифрование и подпись). Кроме того, есть определённая нагрузка на диски для работы базы данных сертификатов (AD CS использует JET Database Engine). Это в теории.
На практике аппаратных ресурсов даже бюджетных линеек серверов будет более чем достаточно для функционирования служб сертификатов, поскольку реальные потребности весьма малы на фоне требований ОС к аппаратным ресурсам. В эпоху Windows Server 2003 была написана статья Evaluating CA Capacity, Performance, and Scalability (ссылка на архивную копию, т.к. оригинал удалён с сайта TechNet), освещающую общие моменты, которые нужно учитывать при планировании аппаратных ресурсов.
В 2021 году, Windows PKI Team провела тесты производительности с использованием более современного оборудования (образца 2007 года) под управлением Windows Server 2008. С результатами можно ознакомиться в их блоге: Windows CA Performance Numbers.
Данные в этих статьях, говорят о том, что сервер AD CS на аппаратном сервере выпуска 2007 года позволяет выпускать порядка 150 сертификатов в секунду. Реальная же потребность в скорости выдачи сертификатов на порядки ниже. Поэтому для ЦС общего назначения советую ориентироваться на рекомендуемые аппаратные требования к самой ОС.
Здесь следует отметить, что в конфигурации для корневого ЦС будет отсутствовать (или должен быть отключен) сетевой интерфейс (поскольку он не будет подключен к сети) и присутствовать хотя бы один интерфейс для съёмных носителей.
Описание политик
Политики выдачи просто характеризуют в общих чертах набор процедур и процессов, выполняемых при выдаче тех или иных сертификатов. Следует понимать, что в программном коде никак не проверяется, соблюдались эти процедуры на самом деле или нет. Если на уровне кода невозможно проверить их выполнение, то зачем они? На этот вопрос есть два ответа.
Первый заключается в том, что ряд ИТ-процессов невозможно отследить на программном уровне. Они проверяются на соответствие принятым правилам аудитом, который проводится людьми. Чаще всего в качестве аудиторов выступают сторонние организации, имеющие компетенцию в рассматриваемых вопросах.
Это касается и политик выдачи сертификатов. В частности, при создании доверия (на уровне PKI и сертификатов) между организациями, они предоставляют документы, описывающие процессы и заказывают сторонний аудит для проверки того, что эти процессы соблюдаются.
Второй ответ вытекает из первого: описание политик выдачи сертификатов в конечном итоге станет документацией на всю PKI и будет иметь своё фирменное название – Certificate Practice Statement или CPS (к сожалению, не нашёл подходящего термина на русском языке, поэтому буду использовать англоязычную аббревиатуру).
Для унификации описания политик выдачи существует рекомендованный (но не обязательный) шаблон, описанный в RFC 3647. По сути, этот документ является фреймворком по написанию политик и освещает всевозможные аспекты работы PKI. Совершенно не обязательно описывать все имеющиеся разделы в документе. Можно документировать только то, что применимо к вашей ситуации, или добавлять что-то своё.
В общем случае CPS будет состоять из двух частей:
- Описание иерархий PKI, общих для всех процедур и положений, которые будут общими для всех конкретных политик выдачи.
- Описание положения специфичные для конкретной политики выдачи. В зависимости от размерности PKI, её особенностей, на каждую политику может составляться отдельный CPS, но чаще всего это сводится к составлению единого документа, который будет описывать всё.
Общие вопросы планирования
Для успешного внедрения любого технического решения необходимо тщательное планирование. Внедрение PKI не является исключением. Более того, если в определённых случаях ошибки изначального планирования могут быть исправлены относительно быстро и легко, то в PKI это однозначно не так.
Например, срок действия сертификатов CA составляет порядка 10-20 лет. Одна из причин такого долгого срока жизни в том, что перевыпуск этих сертификатов является несколько трудоёмкой операцией и могут потребовать изменений на большом количестве клиентов.
Усугубляется это тем, что изменения потребуются и на клиентах, к которым вы можете не иметь доступа. Другой момент заключается в том, что при внесении некоторых изменений в архитектуру PKI вам потребуется поддерживать текущую конфигурацию на всё время жизни уже изданных сертификатов.
Иными словами, для новых сертификатов будет действовать новая конфигурация, но параллельно с ней необходимо будет поддерживать и предыдущую конфигурацию, чтобы уже изданные сертификаты могли корректно работать. Это тоже добавляет сложности в поддержке PKI в работоспособном состоянии.
Учитывая указанные моменты, к планированию PKI следует подходить самым серьёзным образом. И только тогда PKI будет успешно выполнять свои функции в обеспечении цифровой безопасности в течении продолжительного срока.
Многоступенчатый процесс планирования опирается на логическую диаграмму выбранной модели. На каждой ступени элементы диаграммы разворачиваются (детализуется) и для него формализуются связи, задачи и требования. При необходимости детализация продолжается до тех пор, когда будет получена полностью формализованная система. В этой статье демонстрируется пример такого подхода к планированию.
Как обеспечить безопасность онлайн-сеанса
Личные данные и платежные реквизиты можно указывать только на веб-сайтах, защищенных сертификатами с расширенной проверкой или сертификатами, подтверждающие организацию. Сертификаты, подтверждающие домен, не подходят для сайтов электронной коммерции.
Сайты, защищенные сертификатами с расширенной проверкой или сертификатами, подтверждающими организацию, можно определить, посмотрев на адресную строку. Для сайтов, защищенных сертификатами с расширенной проверкой, название организации отображается в адресной строке.
Ознакомьтесь с политикой конфиденциальности веб-сайта. Это позволяет понять, как будут использоваться ваши данные. Законопослушные компании обычно прозрачно описывают сбор и действия с данными.
Обратите внимание на сигналы и индикаторы, вызывающие доверие к веб-сайту.
Наряду с SSL-сертификатами, это могут быть логотипы или значки, показывающие репутацию и соответствие веб-сайта определенным стандартам безопасности. Другие признаки, по которым можно оценить сайт, включают проверку физического адреса и номера телефона, ознакомление с политикой возврата товаров и средств, проверку правдоподобности цен – ведь бесплатный сыр может оказаться в мышеловке.
Extended validation
SSL-сертификаты с расширенным уровнем проверки являются самыми надёжными, но и самыми дорогими. Хорошо подойдут для крупной и серьезной организации, для которой важны престиж и безопасность.
Сертификат уровня EV:
- предлагает самый высокий уровень защиты и наивысший уровень доверия среди других SSL-сертификатов
- выдаётся только юридическим лицам;
- для регистрации необходимы следующие дополнительные документы: свидетельство о постановке на учёт в налоговом органе, уведомление о регистрации юридического лица, извещение о регистрации в качестве страхователя и другие;
- поддерживает кириллические домены;
- выпускается в течение 3-10 дней.
- обойдётся примерно от 10 000 до 100 000 рублей в год.
Также после документальной проверки провайдер может позвонить по официально заявленному телефону организации, совершив тем самым дополнительный этап проверки. Зато после прохождения всего этого документооборота ваш сайт будет обладать самым высоким уровнем доверия, о чём будет свидетельствовать зелёная панелька с названием компании в адресной строке.
По ней пользователи и смогут определить высокий бизнес статус компании, а при нажатии на панель узнать полные сведения об организации. Сертификаты этого типа служат отличной защитой от фишинга: из-за строгих требований верификации, злоумышленники не смогут пройти все этапы проверки, в результате чего “липовые” EV-сертификаты встречаются в крайне редких случаях.
Шаг 1. предварительные изыскания и проверка гипотезы
Нет, серьезно, это правда, что в сертификате X.509 есть СНИЛС? Для проверки найдем образец — просим помощи у Яндекса по запросу «реестр выданных квалифицированных сертификатов», на первой же странице выдачи находим
, скачиваем первый попавшийся сертификат (под номером 10842) —
Открываем сертификат с помощью стандартного средства просмотра OC Windows и находим в описании субъекта подозрительно похожую строку с объектным идентификатором 1.2.643.100.3, состоящую из 11 цифр.
Лирическое отступление
О том, что такое объектный идентификатор (OID) вообще, лучше всего почитать здесь. Как используются объектные идентификаторы в описании структуры сертификатов X.509 — смотрим Руководство по выживанию — TLS/SSL и сертификаты SSL (X.509).
Открываем сертификат в виртуальной машине с установленным криптопровайдером КриптоПРО CSP, который наверняка знает отечественную специфику, и подтверждаем догадку.
Итак, поставленная задача потенциально выполнима, СНИЛС в квалифицированном сертификате есть. Идем дальше.
Как работают ssl-сертификаты?
Использование SSL гарантирует, что данные, передаваемые между пользователями и веб-сайтами или между двумя системами, невозможно прочитать сторонним лицам или системам. SSL использует алгоритмы для шифрования передаваемых данных, что не позволяет злоумышленникам считать их при передаче через зашифрованное соединение.
Процесс работает следующим образом:
- Браузер или сервер пытается подключиться к веб-сайту (веб-серверу), защищенному с помощью SSL.
- Браузер или сервер запрашивает идентификацию у веб-сервера.
- В ответ веб-сервер отправляет браузеру или серверу копию своего SSL-сертификата.
- Браузер или сервер проверяет, является ли этот SSL-сертификат доверенным. Если это так, он сообщает об этом веб-серверу.
- Затем веб-сервер возвращает подтверждение с цифровой подписью и начинает сеанс, зашифрованный с использованием SSL.
- Зашифрованные данные используются совместно браузером или сервером и веб-сервером.
Этот процесс иногда называют подтверждением SSL-соединения. Хотя по описанию этот процесс выглядит длительным, в реальности он занимает миллисекунды.
Шаг 3. разработка парсера x.509 сертификата на с#
Так сложилось, что разработка у нас ведется на C#, поэтому и пример парсера будет на C#, ничего личного и никакого холивара.
Для простоты формализуем задачу следующим образом. Дано: файл квалифицированного сертификата в системе ограничений CER (Canonical encoding rules). Требуется: разобрать (распарсить) сертификат и извлечь значения ИНН, СНИЛС и ОГРН из поля субъекта (Subject).
Для первых набросков обращаемся к возможностям пространства имен System.Security.Cryptography.X509Certificates:
using System.IO;
using System.Security.Cryptography.X509Certificates;
using System.Diagnostics;
namespace X509Parser
{
class Program
{
static void Main(string[] args)
{
string fileName = @"c:Komarov_Aleksey_Petrovich_2021-03-31_a2ba20c4.cer";
X509Certificate cert = new X509Certificate(File.ReadAllBytes(fileName));
Debug.Print("Серийный номер: {0}", cert.GetSerialNumberString());
Debug.Print("Дата окончания действия квалифицированного сертификата: {0}", cert.GetExpirationDateString());
Debug.Print("Субъект: {0}", cert.Subject);
}
}
}На выходе получаем:
Программирование политик
В процессе составления CPS будет определена одна или несколько уникальных политик выдачи (как минимум одна будет обязательно). Каждая политика выдачи должна иметь уникальный идентификатор и указатель на CPS (гиперссылка или текстовая строка).
Идентификаторы политик должны быть представлены в формате ITU-T и ISO. В своё время я написал небольшую вводную статью про объектные идентификаторы: Что в OID’е тебе моём? В ней есть информация о том, как получить в IANA (Internet Assigned Numbers Authority) свою ветку идентификаторов.
Далее вы назначаете конкретные политики выдачи для ЦС, которые будут их поддерживать. Например, у вас может быть несколько издающих ЦС, каждый из которых будет поддерживать только определённые политики. Список поддерживаемых политик будет содержаться в расширении Certificate Policies сертификата ЦС, а также в сертификатах конечных потребителей.
Что такое ssl-сертификат?
SSL-сертификат – это цифровой сертификат, удостоверяющий подлинность веб-сайта и позволяющий использовать зашифрованное соединение. Аббревиатура SSL означает Secure Sockets Layer – протокол безопасности, создающий зашифрованное соединение между веб-сервером и веб-браузером.
Компаниям и организациям необходимо добавлять SSL-сертификаты на веб-сайты для защиты онлайн-транзакций и обеспечения конфиденциальности и безопасности клиентских данных.
SSL обеспечивает безопасность интернет-соединений и не позволяет злоумышленникам считывать или изменять информацию, передаваемую между двумя системами. Если в адресной строке рядом с веб-адресом отображается значок замка, значит этот веб-сайт защищен с помощью SSL.
С момента создания протокола SSL около 25 лет назад, он был доступен в нескольких версиях. При использовании каждой из этих версий в определенный момент возникали проблемы безопасности. Затем появилась обновленная переименованная версия протокола – TLS (Transport Layer Security), которая используется до сих пор. Однако аббревиатура SSL прижилась, поэтому новая версия протокола по-прежнему часто называется старым именем.
Как получить ssl-сертификат
SSL-сертификат можно получить непосредственно в центре сертификации. Центры сертификации, иногда также называемые сертифицирующими организациями, ежегодно выдают миллионы SSL-сертификатов. Они играют важную роль в работе интернета и обеспечивают прозрачное и надежное взаимодействие в сети.
Стоимость SSL-сертификата может доходить до сотен долларов, в зависимости от требуемого уровня безопасности. После выбора типа сертификата можно найти издателей сертификатов, предлагающих SSL-сертификаты нужного уровня.
Получение SSL-сертификата включает следующие шаги:
После получения сертификата его необходимо настроить на вашем веб-хосте или серверах, если вы обеспечиваете хостинг веб-сайта самостоятельно.
Скорость получения сертификата зависит от типа сертификата и поставщика сертификатов. Для завершения каждого уровня проверки требуется разное время. Простой SSL-сертификат, подтверждающий домен, может быть выпущен в течение нескольких минут после заказа, а получение сертификата с расширенной проверкой может занять целую неделю.
Можно ли использовать ssl-сертификат на нескольких серверах?
Один SSL-сертификат можно использовать для нескольких доменов на одном сервере. В зависимости от поставщика, можно также использовать один SSL-сертификат на нескольких серверах. Это позволяют мультидоменные SSL-сертификаты, описанные выше.
Как следует из названия, мультидоменные SSL-сертификаты работают с несколькими доменами. Количество доменов остается на усмотрение конкретного центра сертификации. Мультидоменный SSL-сертификат отличается от однодоменного SSL-сертификата, который, как следует из названия, предназначен для защиты одного домена.
Мультидоменные SSL-сертификаты также называются SAN-сертификатами. SAN означает альтернативное имя субъекта. Каждый мультидоменный сертификат имеет дополнительные поля (например, альтернативные имена субъектов), которые можно использовать для перечисления дополнительных доменов, чтобы на них распространялся один сертификат.
Сертификаты унифицированных коммуникаций (UCC) и Wildcard-сертификаты также можно применять на нескольких доменах и, в последнем случае, на неограниченном количестве поддоменов.
Какой ssl-сертификат выбрать?
Итак, мы определились с тем, что SSL-сертификаты различаются между собой не только брендом и ценой. Сегодняшний ассортимент предложений предусматривает широкий круг задач, для которых может потребоваться SSL.
Например, если вы просто хотите уберечь пользователей вашего веб-сайта от навязчивых предупреждений браузера о посещении непроверенного сайта, будет достаточно за несколько минут получить простой DV (Domain Validation) сертификат. Если же вы используете свою интернет-площадку для операций, требующих повышенного уровня безопасности данных компании и клиентов — стоит задуматься об EV (Extended Validation) сертификате.
Для выбора оптимального сертификата для определённого сайта нужно изучить, что предлагают центры сертификации, обращая внимание на следующие аспекты:
- насколько SSL совместим с основными браузерами;
- на каком уровне происходит защита данных пользователей;
- насколько масштабная проверка организации проводится;
- есть ли печать доверия.
Подведение итогов
Итак, подытоживая проделанную работу, мы:
- Разобрались со структурой квалифицированных сертификатов X.509, которые попадают в сферу действия ФЗ «Об электронной подписи».
- Узнали, что Приказ ФСБ РФ № 795 определяет дополнительные атрибуты — ИНН, СНИЛС, ОГРН и другие. Здесь же указываются соответствующие объектные идентификаторы (OID).
- Разработали парсер сертификатов X.509 на C# с возможностью извлечения полей и их атрибутов с заданными объектными идентификаторами. Библиотека BouncyCastle добавила решению простоты.
В расчетах по времени произошла ошибка — вместо запланированных нескольких часов пришлось разбираться весь день. И еще два дня на подготовку исследования для Хабра.
Спасибо за внимание!
Зачем нужен ssl-сертификат
SSL-сертификаты сайтов требуются для обеспечения безопасности данных пользователей, подтверждения прав собственности на сайт, предотвращения создание поддельной версии сайта злоумышленниками и обеспечения доверия со стороны пользователей.
Если использование веб-сайта предполагает вход в систему, ввод личных данных, таких как номера кредитных карт, или просмотр конфиденциальной информации, такой как данные медицинской страховки, или финансовой информации, то важно сохранить конфиденциальность этих данных.
Сертификаты, подтверждающие организацию (ov ssl)
Этот тип SSL-сертификатов имеет такой же уровень доверия, что и сертификаты с расширенной проверкой, поскольку для его получения владелец веб-сайта должен пройти основательную проверку. Для этого типа сертификатов информация о владельце веб-сайта также отображается в адресной строке, что позволяет отличить его от вредоносных сайтов.
SSL-сертификаты, подтверждающие организацию, обычно являются вторыми по стоимости (после SSL-сертификатов с расширенной проверкой). Их основная цель – зашифровать конфиденциальные данные пользователей при транзакциях. Коммерческие или общедоступные веб-сайты должны устанавливать сертификаты, подтверждающие организацию, чтобы гарантировать конфиденциальность информации о клиентах.
Построение диаграммы pki
Как я уже говорил, всё начинается с логической диаграммы выбранной модели. Логическая диаграмма отображает все компоненты PKI и она должна быть переложена на физическую топологию. В случае применения двухуровневой модели PKI такая диаграмма может иметь следующий вид:
На диаграмме представлены следующие компоненты и их логические связи:
Физическая топология будет несколько отличаться и иметь следующий вид:
В физической топологии в явном виде выделено, что сервер отзыва доступен для всех клиентов, как внутри, так и снаружи сети, благодаря чему клиенты могут проверять сертификаты в любом месте.
Самоподписные ssl-сертификаты
Получение SSL- сертификата, разумеется, стоит денег, при этом действует он ограниченное количество времени. Поэтому многие используют так называемые самоподписные SSL-сертификаты. Сгенерировать их можно с помощью панели управления хостингом прямо на веб-сервере, причём сделать это можно совершенно бесплатно. Однако, далеко не всегда целесообразно использовать самоподписной сертификат.
Любой браузер проверяет, выдан ли сертификат известным ему центром сертификации, и если нет (а это и есть случай самоподписного сертификата), то выдаёт на него ошибку и выводит на экран большую табличку с надписью “Сертификат безопасности сайта не является доверенным!”.
Wildcard-сертификаты
Wildcard-сертификаты (сертификаты с подстановочными символами) позволяют защитить базовый домен и неограниченное количество поддоменов с помощью одного сертификата. Если имеется несколько поддоменов, которые нужно защитить, приобретение Wildcard-сертификата будет намного дешевле, чем приобретение отдельных SSL-сертификатов для каждого поддомена.
Wildcard-сертификаты содержат звездочку (*) как часть общего имени. Звездочка указывается вместо любого допустимого поддомена в составе одного базового домена. Например, один Wildcard-сертификат для веб-сайта можно использовать для защиты следующих страниц:
Об авторе
Вадим Поданс
— специалист в области автоматизации PowerShell и Public Key Infrastructure, Microsoft MVP: Cloud and Datacenter Management с 2009 года и автор модуля PowerShell PKI. На протяжении 9 лет в своём блоге освещает различные вопросы эксплуатации и автоматизации PKI на предприятии. Статьи Вадима о PKI и PowerShell можно найти на его
Organization validation
OV-сертификат подтверждает бизнес-статус организации и вызывает куда больше доверия пользователей, чем DV-сертификат. Данный тип сертификата хорошо подойдёт для онлайн-магазина и другого небольшого интернет-бизнеса.
Сертификат уровня защиты OV:
- обеспечивает средний уровень защиты;
- выдаётся только юридическим лицам;
- для регистрации необходимо предоставить копии документов организации, счёт телефонной компании с указанным названием организации и номером телефона её владельца;
- выпускается в течение 1-5 дней;
- обойдётся примерно от 4 000 рублей до 50 000 рублей в год.
Каким сайтам нужен ssl?
SSL-сертификат необходимо подключать к сайтам, которые работают с финансами и персональными данными пользователей. Это интернет-магазины, банки, платёжные системы, социальные сети, почтовые сервисы и любые другие проекты.
SSL-сертификат лучше ставить с самого начала, чтобы иметь более высокие позиции в поисковых системах. Если всё же изначально не использовался сертификат, то переехать можно быстро, а вот поисковики могут увидеть это только спустя пару месяцев. Тем более сегодня поставить SSL можно и бесплатно.
Безопасность данных
Конечно же, стоит начать с этого пункта, ведь в этом заключается основная цель использования SSL-сертификатов. Если вы работаете с персональными данными пользователей, вам просто необходимо их шифровать при передаче к серверу. Само по себе использование сертификата не лекарство от всех бед, злоумышленники могут перехватить данные ещё до момента передачи их на сервер на заражённом компьютере или устройстве посетителя сайта. Однако использование протокола шифрования — значительный вклад в снижение уязвимости сайта.
