Certificate 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).
В левой области окна Корень консоли щелкните узел Сертификаты (локальный компьютер).
Дважды щелкните сертификат.
Найдите в списке поле Отпечаток и щелкните его.
Get-Exchange Certificate
Синтаксис
Описание
По умолчанию этот командлет возвращает в представлении сводного списка такие свойства сертификата:
Если вы добавите | Format-List в команду, командлет вернет дополнительные свойства сертификата:
Если вы добавите | Format-List * в команду, командлет вернет дополнительные свойства сертификата:
Для его запуска необходимо получить соответствующие разрешения. В этой статье перечислены все параметры командлета. Но некоторые из них могут быть вам не доступны, если они не включены в назначенные разрешения. Сведения о необходимых разрешениях для запуска командлетов и использования параметров в организации см. в статье Find the permissions required to run any Exchange cmdlet.
Примеры
Пример 1
В этом примере возвращается сводный список всех сертификатов Exchange и ожидающих запросов на сертификаты на сервере с именем Mailbox01.
Пример 2
В этом примере возвращаются подробные сведения об указанном сертификате.
Пример 3
В этом примере возвращаются все доступные сведения об указанном сертификате.
Пример 4
В этом примере проиллюстрирован выбор сертификата Exchange для имени домена mail.contoso.com. Соединитель отправки или соединитель получения выбирает используемый сертификат на основе полного доменного имени соединителя. При наличии нескольких сертификатов с одинаковым полным доменным именем выбранный службой Exchange сертификат можно просмотреть, указав полное доменное имя в параметре DomainName. Первый возвращенный сертификат является сертификатом, выбранным службой Exchange.
Параметры
Параметр DomainController указывает контроллер домена, который используется этим командлетом для чтения или записи данных в Active Directory. Вы определяете контроллер домена по его полному доменному имени (FQDN). Например, dc01.contoso.com.
Параметр DomainController не поддерживается пограничными транспортными серверами. Пограничный транспортный сервер использует локальный экземпляр службы Active Directory облегченного доступа к каталогам (AD LDS) для чтения и записи данных.
| Type: | Fqdn |
| Position: | Named |
| Default value: | None |
| Accept pipeline input: | False |
| Accept wildcard characters: | False |
| Applies to: | Exchange Server 2010, Exchange Server 2013, Exchange Server 2016, Exchange Server 2019 |
Параметр DomainName фильтрует результаты по значениям полного доменного имени или имени сервера в поле Subject Name (Имя субъекта) или Subject Alternative Name (Альтернативное имя субъекта). Вы можете указать несколько значений, разделив их запятыми.
| Type: | MultiValuedProperty |
| Position: | Named |
| Default value: | None |
| Accept pipeline input: | False |
| Accept wildcard characters: | False |
| Applies to: | Exchange Server 2010, Exchange Server 2013, Exchange Server 2016, Exchange Server 2019 |
Параметр Identity определяет сертификат, который необходимо просмотреть. Допустимые значения:
Этот параметр нельзя использовать вместе с параметром Server.
В качестве позиционного параметра для этого командлета выступает параметр Thumbprint, а не параметр Identity. Поэтому, когда указывается только значение отпечатка, команда использует это значение для параметра Thumbprint.
| Type: | ExchangeCertificateIdParameter |
| Position: | 1 |
| Default value: | None |
| Accept pipeline input: | False |
| Accept wildcard characters: | False |
| Applies to: | Exchange Server 2013, Exchange Server 2016, Exchange Server 2019 |
Этот параметр устарел и больше не используется.
| Type: | X509Certificate2 |
| Position: | Named |
| Default value: | None |
| Accept pipeline input: | True |
| Accept wildcard characters: | False |
| Applies to: | Exchange Server 2010, Exchange Server 2013, Exchange Server 2016, Exchange Server 2019 |
Параметр Server задает сервер Exchange, на котором следует выполнить эту команду. Можно использовать любое значение, однозначно определяющее сервер. Примеры:
Устаревшее различающееся имя Exchange
Этот параметр нельзя использовать с параметром Identity, но можно использовать с параметром Thumbprint или без других параметров.
| Type: | ServerIdParameter |
| Position: | Named |
| Default value: | None |
| Accept pipeline input: | False |
| Accept wildcard characters: | False |
| Applies to: | Exchange Server 2010, Exchange Server 2013, Exchange Server 2016, Exchange Server 2019 |
Параметр Thumbprint указывает значение отпечатка сертификата, который нужно просмотреть.
В качестве позиционного параметра для этого командлета выступает параметр Thumbprint, а не параметр Identity. Поэтому, когда указывается только значение отпечатка, команда использует это значение для параметра Thumbprint.
| Type: | String |
| Position: | 1 |
| Default value: | None |
| Accept pipeline input: | True |
| Accept wildcard characters: | False |
| Applies to: | Exchange Server 2010, Exchange Server 2013, Exchange Server 2016, Exchange Server 2019 |
Входные данные
Типы входных данных, поддерживаемые этим командлетом, см. в статье Типы входных и выходных данных для командлетов. Если поле «Типы входных данных» для командлета пустое, этот командлет не поддерживает ввода данных.
Выходные данные
Типы возвращаемых данных, или типы выходных данных, которые поддерживаются этим командлетом, см. в статье Типы входных и выходных данных для командлетов. Если поле «Типы выходных данных» пустое, командлет не возвращает данные.
Мониторинг срока действия сертификатов в 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. В результате получим такой аларм:
и такое оповещение по почте:
Вот теперь точно всё. Можно было бы, конечно, настроить дашборд, построить графики, но для сертификатов это будут несколько бессмысленные и скучные прямые линии, в отличие от графиков загрузки процессора или памяти, например. Но, об этом как-нибудь в другой раз.
Morgan Simonsen’s Blog
Introduction
I got an interesting question about X.509 certificate thumbprints today from a colleague. Specifically, he wanted to know if you could renew a certificate and keep the thumbprint. The answer is no, unfortunately. So I thought I would explain why you can’t.
Certificate storage
The X.509 standard was first issued in 1988 and is described in several RFCs. It specifies, among other things, public key certificates, what we commonly refer to as X.509 certificates. X.509 certificates, in turn, currently come in three versions, v1, v2 and v3. The v3 certificates are described in RFC 5280. For the remainder of this post the terms certificate, public key certificate and X.509 certificate are used interchangeably.
X.509 certificates, as well as many other things in the X.509 standard, are described using Abstract Syntax Notation One (ASN.1). ASN.1 is a standard used to exchange information between systems independently of the systems’ encoding techniques. ASN.1 have several encoding rules:
Here is a screenshot of a DER encoded certificate opened in a HEX editor:
Here is the same cert encoded as Base64 also opened in a HEX editor:
Finally here is the same certificate in ASN.1 human readable form (this isn’t the whole cert):
So what does all this mean?
The RFC 5280 X.509 certificate definition
In RFC 5280 the basic syntax of a certificate (using ASN.1) defines three required fields:
| Field | Definition from RFC 5280 |
| tbsCertificate | The sequence TBSCertificate contains information associated with the subject of the certificate and the CA that issued it. Every TBSCertificate contains the names of the subject and issuer, a public key associated with the subject, a validity period, a version number, and a serial number; some MAY contain optional unique identifier fields. |
| signatureAlgorithm | The signatureAlgorithm field contains the identifier for the cryptographic algorithm used by the CA to sign this certificate. |
| signatureValue | The signatureValue field contains a digital signature computed upon the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded tbsCertificate is used as the input to the signature function. This signature value is encoded as a BIT STRING and included in the signature field. |
The tbsCertificate field is by far the largest containing also any extensions the certificate may have like key usage, alternate names etc. RFC 5280 lists all the possible extensions. signatureAlgorithm contains only one piece of data; the hashing algorithm used by the signing authority to sign this particular certificate. signatureValue contains the signature itself, calculated with the hashing algorithm from signatureAlgorithm.
The signature
To produce the certificate signature the signing authority takes the tbsCertificate field in ANS.1 DER encoded form (binary data) and applies the hashing algorithm to it. Inside the tbsCertificate field are some important fields. Specifically the subject name (CN), the hashing algorithm the signing authority used to sign the certificate and the subject’s public key. By signing all these fields the signing authority certifies that the subject in question does in fact own the public key in the certificate. It is a requirement that the signature field within the tbsCertificate field match the signatureAlgorithm field in the certificate. The important distinction here is that it is only the signature field inside the tbsCertificate field that is included in the signature, not the signatureAlgorithm field.
The Windows Cryptographic API
When a certain implementation uses the certificate it calculates and resolves a lot of information not included in the certificate itself. These are things like hash values of various fields and OIDs used to describe e.g. signing algorithms. Certificate Revocation checking is also usually performed and chaining and validation. One example of this behavior is the Windows CryptoAPI Cryptographic Shell Handler. This is the component that shows you a picture like the one below when you double click a certificate from Windows Explorer.
Legend
 | Actual fields in the certificate |
 | Extensions in the certificate |
 | Computed fields not actually part of the certificate data |
The certutuil.exe command line utility goes into even greater detail if you inspect (dump) a certificate:
X509 Certificate:
Version: 3
Serial Number: 6e9235460edbb5944d59f9f1a8f1cfe6
Signature Algorithm:
Algorithm ObjectId: 1.3.14.3.2.29 sha1RSA (shaRSA)
Algorithm Parameters:
05 00
Issuer:
CN=Morgan Simonsen
Name Hash(sha1): 935093f16909002acd98626df485fa22b41d9dfd
Name Hash(md5): c32bdd1ad8eaf126fd96b2f7f23f2b9f
NotBefore: 16.04.2013 10:57
NotAfter: 01.01.2040 01:59
Subject:
CN=Morgan Simonsen
Name Hash(sha1): 935093f16909002acd98626df485fa22b41d9dfd
Name Hash(md5): c32bdd1ad8eaf126fd96b2f7f23f2b9f
Public Key Algorithm:
Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA (RSA_SIGN)
Algorithm Parameters:
05 00
Public Key Length: 2048 bits
Public Key: UnusedBits = 0
0000 30 82 01 0a 02 82 01 01 00 ac ed c3 1d 11 7f 63
0010 db 25 50 2e 9a c6 c1 f5 b7 23 c8 a0 71 a4 6e d6
0020 c8 29 17 8f 76 b6 8c 88 33 bf c9 0e 3d c8 0d 87
0030 11 60 e4 f0 77 ae e5 b4 47 6f b1 35 98 d3 44 d0
0040 52 c7 60 2e 7f e9 6c 3c 61 c2 36 3d a7 f5 32 88
0050 de 3c c4 79 62 91 b0 4b 24 78 a2 2e 6a 29 a9 ee
0060 0e 7a d8 0d 9e 12 7b b2 53 d1 17 8c 01 dc eb fb
0070 18 4d c0 ae df 61 7e 2b dd 15 b5 65 b3 bc b9 25
0080 58 c9 ed 9e ef 9f 26 9b 79 c3 8e 13 92 9e 62 f3
0090 fe 8d ab 33 b4 40 a1 7b 0e b1 71 56 b4 9d 7b cb
00a0 61 9d 70 1d 9d b4 49 c9 46 42 fc 64 44 67 eb 8b
00b0 ea 7c 29 31 cb 4c 32 12 91 6c dd 04 59 07 51 6a
00c0 e6 40 fa ea 4e b2 ae 64 21 2e 6b 00 99 f0 7c 26
00d0 6e ad 6c 15 18 36 dc 81 61 e9 ce 28 7f f8 89 82
00e0 ee ed c5 ee 54 ee aa cd 01 72 75 71 59 fd fc cd
00f0 4d 53 3e 22 71 47 7f 24 e5 51 28 36 12 09 6b 0d
0100 af c9 37 9b e0 d1 00 67 11 02 03 01 00 01
Certificate Extensions: 1
2.5.29.1: Flags = 0, Length = 44
Authority Key Identifier
KeyID=b4 44 ec b5 97 5f 54 f8 ee e8 7b d0 1e c9 81 92
Certificate Issuer:
CN=Morgan Simonsen
Certificate SerialNumber=6e 92 35 46 0e db b5 94 4d 59 f9 f1 a8 f1 cf e6
The Thumbprint
As you can see from the output of the Crypto Shell Extension and Certutil.exe the thumbprint is a computed field, i.e. not a part of the certificate data itself. In the GUI these are called Properties. In the shell extension the thumbprint is called thumbprint and in the Certutil output it is called Cert hash. From this we can surmise that the thumbprint is some kind of hash or one way function (OWF), whose friendly name is thumbprint. (The fact that the shell extension actually has a field called Thumbprint algorithm also helps.) Certutil is also kind enough to compute both a SHA1 and an MD5 hash for us, while the GUI will only do SHA1. As far as I can tell Windows always uses SHA1 to calculate the thumbprint hash, regardless of which signature algorithm is used in the certificate itself.
So what is the thumbprint a hash of? Turns out it is actually the whole certificate, i.e. the binary data representing the three required fields (tbsCertificate, signatureAlgorithm and signature). You can verify this by using a tool that can generate hashes directly from the certificate binary DER file in the file system. In the screenshot below I have used the HashCheck Shell Extension. This tool has a nice feature where you can paste a hash you have obtained from somewhere and see if it matches any of the computed hashes for the file. Here I have copied the thumbprint hash value from Certutil and pasted into the tool:
Since the thumbprint is a hash of the certificate in binary DER encoding this will not work if your certificate is stored in any other format than DER.
Conclusion
So now we have the answer to why you cannot request a new certificate, or renew an existing one, with the same thumbprint. Changing anything in the certificate data will produce a completely different hash result and thus a completely different thumbprint.
The thumbprints purpose is actually to make it easy to locate a particular certificate in the certificate store of a system. Let’s say you have a webserver that needs a certificate. Instead of specifying a certificate by subject name, validity or anything else you just supply the thumbprint to the webserver.
More information
To write this post I created a self signed certificate with my name as the subject. The command I used was this:
You can download all the various versions of the certificate from this post from the following link if you want to look in more detail and compare with what I have written.
