Thumbprint сертификата что это
Thumbprint сертификата что это
Что такое отпечаток сертификата (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).
В левой области окна Корень консоли щелкните узел Сертификаты (локальный компьютер).
Дважды щелкните сертификат.
Найдите в списке поле Отпечаток и щелкните его.
Шпоры по сертификатам X.509
Чудище обло, озорно, огромно, стозевно и лаяй.
Кстати что общего между LDAP, SNMP и X.509 ну кроме того, что им еще не скоро предстоит собрать стадионы фанатов? Их объединяет ASN.1 — мета-язык описания объектов древности. Если бы эти технологии создавали сейчас, в ход бы пошли XML, DTD или какой-нибудь другой ML. Но в то время стандарты создавались титанами, для которых даже SNMP был простым делом.
Словарный запас
Определение X.509 сертификатов есть в архиве ITU-T
Для того, чтобы досконально понять обозначения и синтаксис, придется читать спеки X.680 редакции 2008 г., где есть полное описание ASN.1. В понятиях ASN.1 SEQUENCE обозначает примерно то же самое, что и struct в Си. Это может сбить с толку, ведь по семантике оно должно было соответствовать скорее массиву. И тем не менее.
Стандарт X.690 определяет следующие правила кодирования структур данных, созданных в соответствии с ASN.1: BER (Basic Encoding Rules), CER (Canonical Encoding Rules), DER (Distinguished Encoding Rules). Есть даже XER (XML Encoding Rules), который на практике мне никогда не встречался.
Да, но для чего нужны сертификаты X.509, которые доставляют столько головной боли? Первая и основная функция сертификатов X.509 — служить хранилищем открытого или публичного ключа PKI (public key infrastructure). К этой функции нареканий нет, а вот со второй не все так однозначно.
Вторая функция сертификатов X.509 заключается в том, чтобы предъявитель сего был принят человеком, либо программой в качестве истинного владельца некоего цифрового актива: доменного имени, веб сайта и пр. Это получается по-разному, далеко не все сертификаты имеют высокую ликвидность, если пользоваться финансовой терминологией. Полгода назад Гугл пригрозил компании Симантек, что перестанет доверять их сертификатам из-за того, что те выпустили аж 30,000 неисправных сертификатов.
Номенклатура сертификатов
Давайте рассмотрим, какие сертификаты X.509 встречаются в природе, если рассматривать их по расположению в пищевой цепочке доверия.
По степени крутизны дороговизны и надежности сертификаты делятся на 3 вида: DV, OV и EV.
Редко, кто на это готов раскошелиться. Навскидку Яндекс, StackOverflow.com и Хабр могут жить и без него. Но те, кто готов пойти ради этого на жертвы должны выполнить следующие требования:
По свои свойствам сертификаты бывают следующих типов.
В России понятие КС квалифицированного сертификата определено законодательно в связи с доступом к ГосУслугам. По ссыске Хабрапост с былиной об извлечении персональных данных из КС.
Откуда берутся сертификаты?
Еще совсем недавно было всего 2 способа заполучить X.509 сертификат, но времена меняются и с недавнего времени есть и третий путь.
Для первого сценария достаточно пары команд и чтобы 2 раза не вставать создадим сертификат с алгоритмом эллиптических кривых. Первым шагом нужно создать закрытый ключ. Считается, что шифрование с алгоритмом эллиптических кривых дает больший выхлоп, если измерять в тактах CPU, либо байтах длины ключа. Поддержка ECC не определена однозначно в TLS Openssl имеет огромное количество опций и команд. Man страница не очень полезна, справочник удобнее использовать так:
Следует серия вопросов, чтобы было чем запомнить поля owner и issuer
Конвертируем связку ключей из проприетарного формата в PKCS12.
Смотрим на результат:
LetsEncrypt
Сценарий №1 — найти следующего в связке
Так и есть, SKI сертификат DigiCert имеет то же значение.
Сценарий №2 — используй subjectAltnName, Люк
Откройте файл openssl.cnf и в секции req добавьте следующие линии.
Далее, в секции [ v3_ca ] укажите.
А дальше все как обычно, создаем закрытый ключ и подписываем сертификат.
Статья Проверка электронной цифровой подписи 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) Не вышел срок действия сертификата (за одним исключением*).
*Если на файл наложена подпись сервера штампа времени, то подпись файла будет действительна даже после истечения срока действия сертификата.
Иначе, вы увидите:
Легитимная подпись в свойствах файла выглядит таким образом:
Мониторинг срока действия сертификатов в Windows на NetXMS
Недавно у нас встала задача мониторинга срока действия сертификатов на серверах с Windows. Ну как встала, после того, как сертификаты несколько раз превращались в тыкву, в то самое время, когда ответственный за их продление бородатый коллега находился в отпуске. После этого мы с ним что-то заподозрили решили над этим задуматься. Так как у нас не спеша внедряется система мониторинга NetXMS, она и стала главным и, в принципе, единственным кандидатом на эту задачу.
Результат в итоге был получен в таком виде:
А сам процесс далее.
Поехали. Встроенного счетчика заканчивающегося срока сертификатов в NetXMS нет, поэтому нужно создавать свой и использовать скрипты для обеспечения его данными. Конечно, на Powershell, это же Windows. Скрипт должен прочитать все сертификаты в операционной системе, взять оттуда срок их истечения в днях и передать это число в NetXMS. Через его агента. Вот с него и начнем.
Вариант первый, самый простой. Просто получить количество дней до окончания срока действия сертификата с ближайшей датой.
Чтобы сервер NetXMS узнал о существовании нашего кастомного параметра, он должен получить его от агента. Иначе этот параметр невозможно будет добавить, по причине его отсутствия. Поэтому, в конфигурационный файл агента nxagentd.conf мы добавляем строку внешнего параметра с именем HTTPS.CertificateExpireDateSimple, в которой прописываем запуск скрипта:
В результате чего конфиг агента выглядит примерно так:
После этого нужно сохранить конфиг и перезапустить агента. Можно это сделать из консоли NetXMS: открыть конфиг (Edit agent’s confuguration file), отредактировать, выполнить Save&Apply, в результате чего, собственно, произойдет то же самое. Потом перечитать конфигурацию (Poll > Configuration), если совсем нет сил подождать. После этих действий должна появиться возможность добавить наш кастомный параметр.
В консоли NetXMS идем в Data Collection Configuration подопытного сервера, на котором мы собрались мониторить сертификаты и создаем там новый параметр (в дальнейшем, после настройки, есть смысл перенести его в шаблоны). Выбираем HTTPS.CertificateExpireDateSimple из списка, вписываем Description с понятным именем, тип ставим Integer и настраиваем интервал опроса. Слишком коротким его нет смысла делать, чтобы не забивать базу лишней информацией, слишком длинным неудобно будет ждать при проверке. Для сертификатов я обычно ставлю 600 секунд. На время отладки есть смысл сделать его покороче, 30 секунд, например:
Всё, готово, пока достаточно. Можно проверять… нет, еще рано. Сейчас, естественно, ничего мы не получим. Просто потому, что скрипт еще не написали. Исправляем это упущение. Скрипт будет выдавать просто цифру, количество дней, оставшихся до окончания срока действия сертификата. Самую минимальную из всех имеющихся. Пример скрипта:
723 дня, до истечения срока действия сертификата еще почти два года. Логично, потому что сертификаты на Exchange тестового стенда я перевыписывал совсем недавно.
Это был простой вариант. Наверное, кого-то и такой устроит, но нам хотелось большего. Задачу мы себе поставили получить список всех сертификатов на сервере, поименно, и у каждого видеть количество дней, оставшихся до окончания срока действия сертификата.
Второй вариант, несколько посложнее.
Опять редактируем конфиг агента и там вместо строчки с ExternalParameter пишем две другие:
В ExternalList мы получаем просто список строк. В нашем случае, список строк с именами сертификатов. Список этих строк мы получим скриптом. Имя списка — HTTPS.CertificateNames.
А уже в ExternalParameter мы на вход подаем строки из списка ExternalList, а на выходе получим всё то же количество дней для каждой. Идентификатором служит Thumbprint сертификата. Обратите внимание, что HTTPS.CertificateExpireDate в этом варианте содержит звездочку (*). Это необходимо для того, чтобы он принимал внешние переменные, как раз наш CertificateId.
В Data Collection Configuration сервера создаем новый параметр. В Parameter выбираем наш HTTPS.CertificateExpireDate(*) из списка, и, (внимание!) меняем звездочку на . Этот важный момент позволит создать отдельный счетчик для каждого инстанса (сертификата). Остальное заполняется, как в предыдущем варианте:
Для того, чтобы счетчики было из чего создавать, на вкладке Instance Discovery нужно выбрать Agent List из списка и в поле List Name вписать имя нашего ExternalList из скрипта — HTTPS.CertificateNames.
Почти готово, немного подождать или принудительно сделать Poll > Configuration и Poll > Instance Discovery, если совсем невозможно ждать. В результате получаем все наши сертификаты со сроками действия:
То, что надо? Ну да, только червячок перфекционизма смотрит на этот ненужный Thumbprint в имени счетчика печальными глазами и никак не дает закончить статью. Чтобы его накормить, снова открываем свойства счетчика и на вкладке Instance Discovery в поле «Instance discovery filter script» добавляем написанный на NXSL (внутреннем языке NetXMS) скрипт:
который будет отфильтровывать Thumbprint:
А чтобы его отобразить отфильтрованным, на вкладке General в поле Description меняем CertificateExpireDate:
Всё, наконец-то финиш из КДПВ :
Осталось настроить оповещения, чтобы они приходили на почту, когда срок сертификата подходит к своему логическому концу.
1. Сначала нужно создать шаблон события (Event Template) для активации его при уменьшении значения счетчика до какого-то заданного нами порога. В Event Configuration создаем два новых шаблона с именами, скажем CertificateExpireDate_Threshold_Activate со статусом Warning:
и аналогичный CertificateExpireDate_Threshold_Deactivate со статусом Normal.
2. Дальше идем в свойства счетчика и на вкладке Tresholds настраиваем порог:
где выбираем наши созданные эвенты CertificateExpireDate_Threshold_Activate и CertificateExpireDate_Threshold_Deactivate, ставим количество замеров (Samples) 1 (конкретно для этого счетчика больше ставить смысла нет), значение в 30 (дней), к примеру, и, что важно, настраиваем время повторения эвента. Для сертификатов в продакшене я ставлю раз в сутки (86400 секунд), иначе можно утонуть в оповещениях (что, кстати и случилось один раз, причем так, что переполнился почтовый ящик за выходные). На время отладки есть смысл поставить поменьше, 60 секунд, к примеру.
3. В Action Configuration создаем шаблон письма оповещения, типа такого:
Все эти %m, %S и т.п. — макросы, в которые будут подставлены значения из нашего параметра. Подробнее они описаны в мануале NetXMS.
4. И, наконец, объединяя предыдущие пункты, в Event Processing Policy создаем правило, по которому будет создаваться Alarm и отправляться письмо:
Сохраняем политику, всё, можно тестировать. Поставим порог повыше, для проверки. У меня ближайший сертификат истекает через 723 дня, для проверки поставил 724. В результате получим такой аларм:
и такое оповещение по почте:
Вот теперь точно всё. Можно было бы, конечно, настроить дашборд, построить графики, но для сертификатов это будут несколько бессмысленные и скучные прямые линии, в отличие от графиков загрузки процессора или памяти, например. Но, об этом как-нибудь в другой раз.