как узнать sha1 отпечаток ssl сертификата
Как узнать sha1 отпечаток ssl сертификата
Что такое отпечаток сертификата (Certificate thumbprint)
И так про определение хэша и его виды, я вам подробно уже рассказывал, кто не видел эту статью, советую ее посмотреть, будет очень познавательно. Там алгоритмов очень много, нас это сегодня не интересует, нам нужно его значение. Я покажу вам два метода, но уверен, что их гораздо больше.
Узнаем кэш сертификата в браузере
Найдите любой интересующий вас сайт, я выберу свой проект https://basis.myseldon.com/ru. Как видите у него есть сертификат, об этом говорит замочек перед адресом сайта.
Чтобы посмотреть сертификат используемый в нем, вам нужно просто на него щелкнуть, в Internet Explore этого достаточно, но в Google Chrome придется сделать вот таким методом. Далее вы заходите во вкладку «Состав» и находите поле «Отпечаток», именно это значение и будет вам показывать хэш сертификата.
Если вы используете сертификат для подписи и он установлен у вас локально, то откройте оснастку mmc сертификаты и в ветке личное найди нужный, далее все как описано выше.
Через командную строку
Откройте командную строку cmd и введите команду:
Как видите, данный метод еще быстрее, для примера я вам показал вывод командной строки и сертификат открытый в Internet Explore. Надеюсь вам помогла данная информация в поиске значения хэш у сертификата.
Получить отпечаток сертификата с помощью PowerShell
Если вам необходимо получить отпечаток сертификата через PowerShell, то запустите оболочку и введите команду:
У вас будет столбец Thumbprint, это и есть отпечаток сертификата, в моем примере, это сертификат для Windows Admin Center.
Та же можно вывести более детальную информацию по сертификатам и сделать небольшое форматирование выходных данных:
В результате полезное еще видеть столбец NotAfter для понимания срока действия сертификата.
Практическое руководство. Получение отпечатка сертификата
При написании приложения Windows Communication Foundation (WCF), использующего сертификат X. 509 для проверки подлинности, часто бывает необходимо указать утверждения, найденные в сертификате. Например, при использовании перечисления FindByThumbprint в методе SetCertificate необходимо указать утверждение отпечатка. Чтобы найти значение утверждения, необходимо выполнить два действия. Сначала необходимо открыть оснастку сертификатов консоли управления (MMC). (См. раздел как просмотреть сертификаты с помощью оснастки MMC.) Во-вторых, как описано здесь, найдите подходящий сертификат и скопируйте его отпечаток (или другие значения утверждений).
Вы также можете использовать командлет PowerShell New-SelfSignedCertificate, чтобы создать временные сертификаты для использования только во время разработки. Однако по умолчанию такой сертификат не выдается центром сертификации и не может использоваться в производственных целях. Дополнительные сведения см. в разделе инструкции. Создание временных сертификатов для использования во время разработки.
Извлечение отпечатка сертификата
Откройте оснастку «Сертификаты» консоли управления (MMC). (См. раздел How to: View Certificates with the MMC Snap-in).
В левой области окна Корень консоли щелкните узел Сертификаты (локальный компьютер).
Дважды щелкните сертификат.
Найдите в списке поле Отпечаток и щелкните его.
Как просмотреть содержимое ключей и сертификатов SSL
Просмотр содержимого ключей и сертификатов
Мы можем подробно изучить содержимое всех созданных в OpenSSL файлов, а также при необходимости конвертировать их в другие форматы.
В следующих командах используются тестовые файлы со следующими именами:
Обратите внимание на расширения файлов — они могут отличаться от тех, которые используются в других инструкциях. Например, вместо .key и .crt может использоваться расширение .pem. Расширение файла не имеет особого значения кроме как служить подсказкой пользователю, что именно находится в этом файле. Это же самое касается и имён файлов — вы можете выбирать любые имена.
Все эти файлы являются текстовыми:
Там мы увидим примерно следующее:
Если вам эти строки кажутся знакомыми на кодировку Base64, то вы совершенно правы — это она и есть. (Смотрите также «Как быстро узнать и преобразовать кодировку»).
Этот формат, называемый форматом PEM, расшифровывается как Privacy Enhanced Mail.
PEM — это текстовое представление реального двоичного ключа или сертификата в формате DER. Представляет собой двоичного формата DER в кодировке base64 и с дополнительными строками «——BEGIN PRIVATE KEY——», «——BEGIN CERTIFICATE——» и другими в начале файла и строками «——END PRIVATE KEY——», «——END CERTIFICATE——» в конце файла.
Мы можем хранить двоичную версию файла только с кодировкой DER, но наиболее распространенным способом является версия PEM.
Вы можете увидеть структуру приватного следующей командой:
Любой формат ключа на самом деле является контейнером для набора длинных чисел. Все остальные данные можно считать «шумом».
Закрытый ключ содержит: модуль (modulus), частный показатель (privateExponent), открытый показатель (publicExponent), простое число 1 (prime1), простое число 2 (prime2), показатель степени 1 (exponent1), показатель степени 2 (exponent2) и коэффициент (coefficient).
Открытый ключ содержит только модуль (modulus) и открытый показатель (publicExponent).
Вы можете из влечь из файла ключей публичный ключ:
По умолчанию выводится закрытый ключ: с опцией -pubout вместо него будет выведен открытый ключ. Эта опция устанавливается автоматически, если ввод является открытым ключом.
Следующая команда покажет информацию о публичном ключе:
По умолчанию из входного файла считывается закрытый ключ. Используемая в предыдущей команде опция -pubin делает так, что вместо приватного ключа читается открытый ключ.
Можно также добавить опцию -noout — с ней будет выведена та же самая информация, но не будет показана кодированная версия ключа.
С такими же опциями, но уже используя команду req, можно изучить содержимое запроса на подпись сертификата:
При создании SSL сертификата мы создали две пары ключей (корневые и для домена), то есть это файлы rootCA.key и mydomain.com.key, но по своей технической сути они идентичны.
Что касается сертификатов, которых у нас тоже два (rootCA.crt и mydomain.com.crt), то по своей природе они не являются одинаковыми: корневой сертификат является самоподписанным, а сертификат домена подписан приватным корневым ключом.
Информацию о содержимом сертификатов можно посмотреть командой x509 (остальные опции нам уже знакомы):
Самоподписанные сертификаты обычно содержат только самые основные данные сертификатов, как показано в предыдущем примере. Для сравнения, сертификаты, выданные общедоступными центрами сертификации, гораздо интереснее, поскольку они содержат ряд дополнительных полей (с помощью механизма расширений X.509).
Сертификат (цепочку сертификатов) любого сайта вы можете получить следующей командой (замените w-e-b.site на интересующий вас сайт):
Вы увидите сертификаты (один или несколько), найдите по полю CN тот, который вас интересует, например, сертификат домена w-e-b.site:
И скопируйте содержимое начиная с ——BEGIN CERTIFICATE—— и заканчивая ——END CERTIFICATE——. Затем сохраните это в файл.
Вы также можете сохранить сертификат центра сертификации и изучить его:
К примеру, сертификат сайта w-e-b.site я сохранил в файл w-e-b.site.crt, для просмотра информации о нём:
Issuer указывает на организацию, которая выдала (подписала) сертификат:
Validity — срок действия сертификата:
Subject: CN — домен (IP адрес) для которого предназначен сертификат:
Поддомены в группе X509v3 extensions → X509v3 Subject Alternative Name (подробности чуть позже):
Теперь бегло рассмотрим расширения X.509.
Расширение Basic Constraints используется для маркировки сертификатов как принадлежащих ЦС, давая им возможность подписывать другие сертификаты. В сертификатах, отличных от CA, это расширение будет либо пропущено, либо будет установлено значение CA, равное FALSE. Это расширение является критическим, что означает, что все программные сертификаты должны понимать его значение.
Расширения Key Usage (KU) и Extended Key Usage (EKU) ограничивают возможности использования сертификата. Если эти расширения присутствуют, то разрешены только перечисленные варианты использования. Если расширения отсутствуют, ограничений на использование нет. То, что вы видите в этом примере, типично для сертификата веб-сервера, который, например, не позволяет подписывать код:
Расширение CRL Distribution Points перечисляет адреса, по которым можно найти информацию о списке отзыва сертификатов (CRL) ЦС. Эта информация важна в случаях, когда сертификаты необходимо отозвать. CRL — это подписанные CA списки отозванных сертификатов, публикуемые через регулярные промежутки времени (например, семь дней).
Примечание: возможно, вы заметили, что местоположение CRL не использует защищённый сервер, и вам может быть интересно, является ли ссылка небезопасной. Не является. Поскольку каждый CRL подписан центром сертификации, который его выпустил, браузеры могут проверить его целостность. В том же случае, если бы CRL были доступны по TLS (адрес включал бы в себя протокол HTTPS), то браузеры могут столкнуться с проблемой «курицы и яйца», в которой они хотят проверить статус отзыва сертификата, используемого сервером, доставляющим сам CRL!
Расширение Certificate Policies используется для указания политики, в соответствии с которой был выпущен сертификат. Например, именно здесь можно найти индикаторы расширенной проверки (EV). Индикаторы представлены в форме уникальных идентификаторов объектов (OID) и являются уникальными для выдающего ЦС. Кроме того, это расширение часто содержит один или несколько пунктов CPS, которые обычно являются веб-страницами или документами PDF.
Расширение Authority Information Access (AIA) обычно содержит две важные части информации. Во-первых, он перечисляет адрес ответчика CA OCSP, который можно использовать для проверки отзыва сертификатов в режиме реального времени. Расширение также может содержать ссылку, где находится сертификат эмитента (следующий сертификат в цепочке). В наши дни серверные сертификаты редко подписываются непосредственно доверенными корневыми сертификатами, а это означает, что пользователи должны включать в свою конфигурацию один или несколько промежуточных сертификатов. Ошибки легко сделать, и сертификаты будут признаны недействительными. Некоторые клиенты (например, Internet Explorer) будут использовать информацию, представленную в этом расширении для исправления неполной цепочки сертификатов, но многие клиенты этого не сделают.
Расширения Subject Key Identifier и Authority Key Identifier устанавливают уникальные идентификаторы ключа субъекта и ключа авторизации соответственно. Значение, указанное в расширении Authority Key Identifier сертификата, должно соответствовать значению, указанному в расширении Subject Key Identifier в выдающем сертификате. Эта информация очень полезна в процессе построения пути сертификации, когда клиент пытается найти все возможные пути от конечного (серверного) сертификата до доверенного корня. Центры сертификации часто используют один закрытый ключ с несколькими сертификатами, и это поле позволяет программному обеспечению надёжно определять, какой сертификат может быть сопоставлен с каким ключом. В реальном мире многие цепочки сертификатов, предоставляемые серверами, недействительны, но этот факт часто остаётся незамеченным, поскольку браузеры могут находить альтернативные пути доверия.
Наконец, расширение Subject Alternative Name используется для перечисления всех имен хостов, для которых действителен сертификат. Это расширение раньше было необязательным; если его нет, клиенты возвращаются к использованию информации, представленной в Common Name (CN), которое является частью поля «Subject». Если расширение присутствует, то содержимое поля CN игнорируется во время проверки.
Рассмотрим опции команды x509, которые позволяют извлечь разнообразную информацию из сертификатов.
Чтобы показать издателя сертификата используйте опцию -issuer:
Опция -fingerprint вычисляет и выводит дайджест DER-кодированной версии всего сертификата. Это обычно называют «отпечатком». Из-за характера дайджестов сообщений, отпечаток сертификата является уникальным для этого сертификата, и два сертификата с одинаковым отпечатком могут считаться одинаковыми. Для сертификатов обычно не нужно сверять сертификаты по отпечаткам, но это имеет смысл при использовании самоподписанных сертификатов (например, получении сертификата для VNC сессии, когда нет другого способа проверить, что сертификат не был подменён при пересылке). В этом случае можно сверить отпечаток сертификата, например, по телефону или электронной почте.
Для показа отпечатка сертификата:
Чтобы вывести сертификат в виде строки символов в стиле C — char, используйте опцию -C:
Чтобы вывести расширения сертификата в текстовой форме, используйте опцию -ext. Несколько расширений можно перечислить через запятую, например «subjectAltName,subjectKeyIdentifier«. Чтобы посмотреть весь список расширений:
Пример команды для вывода альтернативных имён в домене:
Пример информации об альтернативных именах домена:
Для вывода почтовых адресов, содержащихся в сертификате, используйте опцию -email. Адреса электронной почты могут отсутствовать в сертификате.
Для вывода адресов респондентов OCSP, если они присутствуют в сертификате, укажите опцию -ocsp_uri:
Для показа дат из сертификата имеются следующие опции:
Для вывода имени subject укажите опцию -subject:
Пример вывода имени subject сертификата в форме схемы на терминале, поддерживающем UTF8:
Опция -serial выводит серийный номер:
Чтобы извлечь публичный ключ из сертификата используйте опцию -pubkey:
Для глубокого понимания OpenSSL смотрите также полное руководство: «OpenSSL: принципы работы, создание сертификатов, аудит».
Статья Проверка электронной цифровой подписи Authenticode. Часть 1. Теория
Dragokas
Very kind Developer
Привет!
Я как-то довольно давно заинтересовался темой цифровых подписей, какова их защита, как они устроены изнутри, как с ними работать из-под CryptoAPI. По мере изучения возникало много подводных камней. Наконец, я готов рассказать и вам на доступном языке о принципах шифрования и подписания, практике и готовой реализации проверки подписей.
Содержание:
Часть 1. Кусочек теории.
Dragokas
Very kind Developer
1.1. Что такое электронная цифровая подпись (ЭЦП) и зачем она нужна?
ЭЦП – это информация, с помощью которой можно удостовериться, что:
1. Файл подписан конкретным издателем;
2. Файл не повреждён после того, как его подписали.
Это гарантирует, что файл получен от доверенного (на ваш субъективный взгляд) издателя и не был модифицирован (перепакован, пропатчен, повреждён при скачивании случайно или специально).
Если проверка ЭЦП прошла успешно, то при запуске с повышенными привилегиями, в окне UAC вы увидите слова «Проверенный издатель» и его имя:
А если эта программа запускается без повышения привилегий, то после скачивания с сети при запуске вы получите предупреждение:
А вот в случае с легитимной подписью система не будет отображать этого сообщения для файла, у которого при запуске присутствует поток Zone.Identifier:$DATA.
Также из положительных моментов, такую подпись в перспективе можно будет внести в белые списки производителей антивирусов.
Если вы планируете разрабатывать драйвера для распространения, цифровая подпись будет обязательна.
Также, приложениям, подписанным легитимной ЭЦП, разрешается запуск с уровнем целостности UIAccess при указании соответствующего параметра в манифесте и размещении файла программы в одном из безопасных расположений.
1.2. Надёжность ЭЦП и эксплуатация вредоносным ПО.
1.2.1. Человеческий фактор и приватные ключи.
Известно много случаев, когда издатель получил сертификат законно, но использует его для распространения вредоносных или нежелательных программ. Пример: Lenovo – раз, два.
Некоторые компании по расторопности распространяли программу вместе с приватными ключами. Пример: снова Lenovo. И вот результат. Также периодически бывают случаи кражи сертификатов у хорошо известных производителей. Пример: Foxconn и ПО Duqu2. Поэтому не стоит слепо доверять цифровой подписи. Однако, запуская файл, вы сможете убедиться, что его создал, например, Петя, а не злой сосед Вася . Даже если центр сертификации (CA) выпустит сертификат на имя, схожее с уже существующими, существует механизм отзыва сертификатов. Правда, никто Вам не скажет сколько ПК успеет заразиться за это время.
1.2.2. Уязвимости в структуре ЭЦП.
Следует учитывать, что проверяется целостность только кода (исполняемой части файла), а не всего файла целиком. Некоторые недобросовестные программисты (в т.ч. именитые фирмы – в этических целях я не буду их называть) в целях упрощения / экономии используют один и тот же бинарный образ уже готовой подписи для разных файлов (без переподписания), добавляя свои метаданные прямо в структуру подписи, в ту её часть, что не проверяется. Для обеспечения более строгой проверки структуры подписи существует твик реестра, выпущенный в рамках бюллетеня безопасности Microsoft. Однако, такая защита вызывала больше проблем, чем пользы, даже во время запуска служб Майкрософт. Так что фикс был отозван.
С оглядкой на данный фикс, некоторые особо хитрые разработчики нашли и другие лазейки для обхода проверки с другой стороны (заодно открыв новую дыру в своём ПО). Как результат, известны случаи создания дроппера вредоносного ПО способом пропатчивания файла без повреждения ЭЦП у программ данных конкретных разработчиков.
С этических соображений, подробности и ссылки на источники я не буду публиковать.
1.2.3. Стойкость алгоритма хеша.
Наиболее старый из алгоритмов хеша подписи, который вы всё ещё можете встретить, – это MD5. Он использовался для подписания части системных файлов в ОС Windows 2000 и ранее.
В частности, некоторые исполняемые файлы подвержены атаке SHAttered, которая работает
в 100.000 раз быстрее, чем полный перебор. Чтобы проверить подвержен ли файл с SHA1 быстрому подбору коллизии, можно воспользоваться инструментом sha1collisiondetection, разработанным Marc Stevens (CWI) и Dan Shumow (Microsoft) и доступным на GitHub. Если это подтверждается, достаточно перекомпилировать файл и проверить его снова.
В данный момент для подписания файлов используется в основном только алгоритм SHA2, а сертификаты подписываются только SHA2 (детальнее см. раздел 1.6 «Двойная подпись»).
Время, начиная с которого сертификаты с хешем SHA1 признаются не крипто-стойкими, указано в ветке реестра (на Win 8.1 и выше):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config\Default => WeakSha1ThirdPartyAfterTime (FILETIME)
Для SHA1 – это дата 01.01.2016.
Для MD5 – это дата 01.03.2009.
Подписи файлов, поставленные с использованием этих алгоритмов позже указанной даты, будут считаться недействительными.
Детальнее, см. Microsoft TechNet. Protecting Against Weak Cryptographic Algorithms.
1.3. Что означает, легитимна ли подпись?
Эта подпись должна быть выдана центром сертификации (Certification authority (CA)), чей сертификат находится в хранилище доверенных корневых сертификатов (TRCA), либо вшит в системные файлы, являющиеся частью механизма проверки.
Вы можете увидеть TRCA через оснастку certmgr.msc
Соответственно, одного их этих CA можно увидеть в цепочке доверия в свойствах файла => вкладка «Цифровая подпись» => Сведения => Просмотр сертификата => Путь сертификации:
Проверка подписи выполняется передачей идентификатора политики WINTRUST_ACTION_GENERIC_VERIFY_V2 в функцию WinVerifyTrust(). Эта политика выдвигает такие требования:
1) Все сертификаты вверх по цепочке доверия в подписанном файле должны также находиться и в хранилище доверенных корневых сертификатов.
Пример, когда часть сертификатов не являются доверенными:
2) Конечный сертификат должен иметь разрешение на подписание кода. Это отображено в поле «Назначение сертификата» (EKU).
3) Не вышел срок действия сертификата (за одним исключением*).
*Если на файл наложена подпись сервера штампа времени, то подпись файла будет действительна даже после истечения срока действия сертификата.
Иначе, вы увидите:
Легитимная подпись в свойствах файла выглядит таким образом:
«Как это работает»: знакомство с SSL/TLS
Мы достаточно часто рассказываем о разных технологиях: от систем хранения до резервного копирования. Помимо этого мы делимся собственным опытом оптимизации работы нашего IaaS-провайдера — говорим об управленческих аспектах и возможностях для улучшения usability сервиса.
Сегодня мы решили затронуть тему безопасности и поговорить об SSL. Всем известно, что сертификаты обеспечивают надежное соединение, а мы разберёмся в том, как именно это происходит, и взглянем на используемые протоколы.
SSL (secure sockets layer — уровень защищённых cокетов) представляет собой криптографический протокол для безопасной связи. С версии 3.0 SSL заменили на TLS (transport layer security — безопасность транспортного уровня), но название предыдущей версии прижилось, поэтому сегодня под SSL чаще всего подразумевают TLS.
Цель протокола — обеспечить защищенную передачу данных. При этом для аутентификации используются асимметричные алгоритмы шифрования (пара открытый — закрытый ключ), а для сохранения конфиденциальности — симметричные (секретный ключ). Первый тип шифрования более ресурсоемкий, поэтому его комбинация с симметричным алгоритмом помогает сохранить высокую скорость обработки данных.
Рукопожатие
Когда пользователь заходит на веб-сайт, браузер запрашивает информацию о сертификате у сервера, который высылает копию SSL-сертификата с открытым ключом. Далее, браузер проверяет сертификат, название которого должно совпадать с именем веб-сайта.
Кроме того, проверяется дата действия сертификата и наличие корневого сертификата, выданного надежным центром сертификации. Если браузер доверяет сертификату, то он генерирует предварительный секрет (pre-master secret) сессии на основе открытого ключа, используя максимально высокий уровень шифрования, который поддерживают обе стороны.
Сервер расшифровывает предварительный секрет с помощью своего закрытого ключа, соглашается продолжить коммуникацию и создать общий секрет (master secret), используя определенный вид шифрования. Теперь обе стороны используют симметричный ключ, который действителен только для данной сессии. После ее завершения ключ уничтожается, а при следующем посещении сайта процесс рукопожатия запускается сначала.
Алгоритмы шифрования
Для симметричного шифрования использовались разные алгоритмы. Первым был блочный шифр DES, разработанный компанией IBM. В США его утвердили в качестве стандарта в 70-х годах. В основе алгоритма лежит сеть Фейстеля с 16-ю циклами. Длина ключа составляет 56 бит, а блока данных — 64.
Развитием DES является алгоритм 3DES. Он создавался с целью совершенствования короткого ключа в алгоритме-прародителе. Размер ключа и количество циклов шифрования увеличилось в три раза, что снизило скорость работы, но повысило надежность.
Еще был блочный шифр RC2 с переменной длиной ключа, который работал быстрее DES, а его 128-битный ключ был сопоставим с 3DES по надежности. Потоковый шифр RC4 был намного быстрее блочных и строился на основе генератора псевдослучайных битов. Но сегодня все эти алгоритмы считаются небезопасными или устаревшими.
Самым современным признан стандарт AES, который официально заменил DES в 2002 году. Он основан на блочном алгоритме Rijndael и скорость его работы в 6 раз выше по сравнению с 3DES. Размер блока здесь равен 128 битам, а размер ключа — 128/192/256 битам, а количество раундов шифрования зависит от размера ключа и может составлять 10/12/14 соответственно.
Что касается асимметричного шифрования, то оно чаще всего строится на базе таких алгоритмов, как RSA, DSA или ECC. RSA (назван в честь авторов Rivest, Shamir и Adleman) используется и для шифрования, и для цифровой подписи. Алгоритм основан на сложности факторизации больших чисел и поддерживает все типы SSL-сертификатов.
DSA (Digital Signature Algorithm) используется только для создания цифровой подписи и основан на вычислительной сложности взятия логарифмов в конечных полях. По безопасности и производительности полностью сопоставим с RSA.
ECC (Elliptic Curve Cryptography) определяет пару ключей с помощью точек на кривой и используется только для цифровой подписи. Основным преимуществом алгоритма является более высокий уровень надежности при меньшей длине ключа (256-битный ECC-ключ сопоставим по надежности с 3072-битным RSA-ключом.
Более короткий ключ также влияет на время обработки данных, которое заметно сокращается. Этот факт и то, что алгоритм эффективно обрабатывает большое количество подключений, сделали его удобным инструментом для работы с мобильной связью. В SSL-сертификатах можно использовать сразу несколько методов шифрования для большей защиты.
Хеш и MAC
Цель хеш-алгоритма — преобразовывать все содержимое SSL-сертификата в битовую строку фиксированной длины. Для шифрования значения хеша применяется закрытый ключ центра сертификации, который включается в сертификат как подпись.
Хеш-алгоритм также использует величину, необходимую для проверки целостности передаваемых данных — MAC (message authentication code). MAC использует функцию отображения, чтобы представлять данные сообщения как фиксированное значение длины, а затем хеширует сообщение.
В протоколе TLS применяется HMAC (hashed message authentication code), который использует хеш-алгоритм сразу с общим секретным ключом. Здесь ключ прикрепляется к данным, и для подтверждения их подлинности обе стороны должны использовать одинаковые секретные ключи, что обеспечивает большую безопасность.
Все алгоритмы шифрования сегодня поддерживают алгоритм хеширования SHA2, чаще всего именно SHA-256. SHA-512 имеет похожую структуру, но в нем длина слова равна 64 бита (вместо 32), количество раундов в цикле равно 80 (вместо 64), а сообщение разбивается на блоки по 1024 бита (вместо 512 бит). Раньше для тех же целей применялся алгоритм SHA1 и MD5, но сегодня они считаются уязвимыми.
Разговоры об отказе от SHA1 велись достаточно давно, но в конце февраля алгоритм был официально взломан. Исследователям удалось добиться коллизии хешей, то есть одинакового хеша для двух разных файлов, что доказало небезопасность использования алгоритма для цифровых подписей. Первая попытка была сделана еще в 2015, хотя тогда удалось подобрать только те сообщения, хеш которых совпадал. Сегодня же речь идет о целых документах.
Сертификаты бывают разные
Теперь, когда мы разобрались, что представляет собой протокол SSL/TLS и как происходит соединений на его основе, можно поговорить и о видах сертификатов.
Domain Validation, или сертификаты с проверкой домена, подходят для некоммерческих сайтов, так как они подтверждают только веб-сервер, обслуживающий определенный сайт, на который был осуществлен переход. Этот вид сертификата самый дешевый и популярный, но не может считаться полностью безопасным, так как содержит только информацию о зарегистрированном доменном имени.
Organization Validation, или сертификаты с проверкой организации, являются более надежными, так как подтверждают еще регистрационные данные компании-владельца. Эту информацию юридическое лицо обязано предоставить при покупке сертификата, а удостоверяющий центр может связаться напрямую с компанией для подтверждения этой информации. Сертификат отвечает стандартам RFC и содержит информацию о том, кто его подтвердил, но данные о владельце не отображаются.
Extended Validation, или сертификат с расширенной проверкой, считается самым надежным. Собственно, зеленый замочек или ярлык в браузере означает как раз то, что у сайта есть именно такой сертификат. О том, как разные браузеры информируют пользователей о наличии сертификата или возникающих ошибках можно почитать тут.
Он нужен веб-сайтам, которые проводят финансовые транзакции и требуют высокий уровень конфиденциальности. Однако многие сайты предпочитают перенаправлять пользователей для совершения платежей на внешние ресурсы, подтвержденные сертификатами с расширенной проверкой, при этом используя сертификаты OV, которых вполне хватает для защиты остальных данных пользователей.
Кроме того, сертификаты могут различаться в зависимости от количества доменов, на которые они были выданы. Однодоменные сертификаты (Single Certificate) привязываются к одному домену, который указывается при покупке. Мультидоменные сертификаты (типа Subject Alternative Name, Unified Communications Certificate, Multi Domain Certificate) будут действовать уже для большего числа доменных имен и серверов, которые также определяются при заказе. Однако за включение дополнительных доменов, свыше определенной нормы, потребуется платить отдельно.
Еще существуют поддоменные сертификаты (типа WildCard), которые охватывают все поддомены указанного при регистрации доменного имени. Иногда могут потребоваться сертификаты, которые будут одновременно включать не только несколько доменов, но и поддомены. В таких случаях можно приобрести сертификаты типа Comodo PositiveSSL Multi-Domain Wildcard и Comodo Multi-Domain Wildcard SSL или (лайфхак) обычный мультидоменный сертификат, где в списке доменов указать также и нужные поддоменные имена.
Получить SSL-сертификат можно и самостоятельно: пара ключей для этого генерируется через любой генератор, например, бесплатный OpenSSL. И такой защищенный канал связи вполне получится использовать для внутренних целей: между устройствами своей сети или приложениями. Но вот для использования на веб-сайте сертификат необходимо приобретать официально, чтобы в цепочке подтверждения сертификатов обязательно имелся корневой сертификат, браузеры не показывали сообщений о небезопасном соединении, а пользователи были спокойны за свои данные.