Vadims Podans's blog - Security | PKI | Chaining Engine

Certificate chaining engine и certificate revocation checking — FAQ

Camelot — Thu, 21 Jan 2010 20:20:06 GMT

Предлагаю немного отвлечься от autoenrollment и поговорить о часто задаваемым вопросам, которые относятся к проблемам certificate chaining engine. Данный FAQ основывается на вопросах, которые часто задаются на форумах TechNet.

Q: За что отвечают расширения CRL Distribution Points (CDP) и Authority Information Access (AIA) в цифровых сертификатах?

A: Расширение Authority Information Access всегда содержит ссылки на сертификат Certification Authority (CA), который издал рассматриваемый сертификат. Например, у вас есть сервер CA, который издаёт пользователям сертификаты. Каждый такой сертификат будет содержать ссылку на скачивание сертификата этого самого CA. Это необходимо для построения цепочки сертификатов. Как известно, любая иерархия PKI включает себя как минимум один корневой CA (Root CA) и может содержать несколько уровней промежуточных CA. Используя расширение AIA конечного сертификата, клиент скачивает сертификат издающего CA, который в расширении AIA так же содержит ссылки на скачивание сертификата вышестоящего CA. Этот процесс происходит до тех пор, пока цепочка не закончится самоподписанным сертификатом и который уже не содержит расширения AIA. Поскольку корневой сертификат самоподписанный, он является конечной точкой цепочки. По корневому сертификату определяется доверие цепочке. Чтобы доверять такой цепочке, корневой сертификат, на котором эта цепочка заканчивается, должен быть установлен в контейнере Trusted Root CAs в оснастке Certificates консоли MMC.
Расширение CRL Distribution Point содержит ссылки на файлы CRL, которые периодически публикует сервер CA, который издал рассматриваемый сертификат. Этот файл содержит серийные номера и прочую информацию о сертификатах, которые были отозваны. Сертификаты могут быть отозваны, когда есть подозрения или уже констатирован факт получения несанкционированного доступа к закрытому ключу третьим лицом. Закрытый ключ должен быть доступен только тому пользователю или компьютеру, которому выдан данный сертификат. Если третье лицо получило доступ к закрытому ключу, это лицо может воспользоваться им для получения конфиденциальной информации или выдавать себя за легитимного пользователя. В таких случаях администратор CA может отозвать такой сертификат. В таком случае если сертификат содержится в файле CRL, предъявителю данного сертификата никакого доверия не будет. Следует понимать, что CDP/AIA рассматриваемого сертификата содержат ссылки на файлы вышестоящего CA. Даже если владельцем рассматриваемого сертификата является сервер CA (Intermediate CA), ссылки будут указывать на файлы вышестоящего CA.
Более подробно вопрос рассмотрен по ссылке: Certificate Chaining Engine — как это работает.

Q: Нужны ли расширения CDP и AIA в сертификатах корневых CA?

A: Нет. Как уже было сказано, CDP и AIA содержат ссылки на файлы вышестоящего CA, а корневой сертификат является высшей точкой в иерархии и выше корневого CA ничего быть не может. Поэтому данные расширения бесполезны для сертификатов корневых CA и обычно просто отсутствуют.
Более подробно вопрос рассмотрен здесь: Certificate chaining engine (CCE) и отзыв корневых сертификатов

Q: На каком сервере CA я могу отозвать определённый сертификат?

A: каждый сервер CA поддерживает свой список CRL в который может включать только те сертификаты, которые были выданы именно этим CA. Это означает, что сертификат отозвать может только CA, который указан в поле Issuer рассматриваемого сертификата.

Q: Стоит ли использовать Certificate Hold в качестве причины отзыва сертификата? Если да, то в каких случаях?

A: Причина отзыва как Certificate Hold обладает одной особенностью — его можно извлечь обратно из CRL файла, после чего он перестанет считаться отозванным. Данная причина задумана для случаев когда сотрудник уходит в отпуск и такой отзыв позволит избежать использование отозванного сертификата на этот период. Однако, данную причину не следует никогда использовать. Это связано с тем, что после извлечения сертификата из CRL вы не можете узнать был ли он отозван в какой-то период времени. Например, вы отозвали сертификат с причиной Certificate Hold и через некоторое время передумали и извлекли сертификат из CRL. В последствии вы получаете документ, подписанный этим сертификатом именно в период фактического нахождения сертификата в CRL. Фактически получается, что документ был подписан в тот момент, когда сертификат был отозван. Поскольку он был потом извлечён из CRL, вы больше не можете доказать, что сертификат был отозван на момент подписания документа. По этой причине вы не должны использовать данную причину отзыва.

Q: При установке сертификата на сервер иногда получаю ошибку: The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613). Что это может означать и как эту ошибку исправить?

A: Данная ошибка указывает на то, что системе не удалось проверить сертификат на отзыв. Иными словами, система извлекла ссылку из CDP расширения сертификата и по этой ссылке не удалось скачать CRL файл. В данном случае вы должны обратиться к администратору сервера CA, чтобы тот обеспечил доступность файла по ссылкам в CDP расширении. Если же вы сами исполняете эти обязанности, то вы должны самостоятельно решить этот вопрос — настроить точки публикации CRL файлов. В качестве временного решения (например, вы опубликовали CRL только в Active Directory и у вас несколько доменов в лесу, причиной этого может быть репликация AD. В таком случае вы можете скачать CRL файл локально на компьютер (любым удобным способом) и выполнить команду: certutil –addstore –f Root <path\file.crl>
где <path\file.crl> — путь к файлу CRL.

Q: При открытии файла сертификата я вижу следующее сообщение: Windows does not have enough information to verify this certificate. Что это означает и как с этим бороться?

A: Данное сообщение говорит о том, что системе не удалось найти сертификат вышестоящего CA. Как уже было отмечено, этот сертификат можно скачать по ссылке (ссылкам) в расширении AIA, но по всей видимости они нерабочие. Вы можете попробовать вручную скачать файл по этим ссылкам и вероятней всего вам это не удастся. Для решения этой проблемы вы должны опубликовать физический файл в соответствующие места: папка веб-сервера (для протокола HTTP) или контейнер AIA в Active Directory (для протокола LDAP). Если файл сертификата CA публикуется только в AD и у вас лес с несколькими доменами, данная ошибка может быть кратковременно вызвана задержками репликации. В таком случае для временного решения вы можете скачать файл на локальную машину (любым удобным для вас способом) и выполнить одну из двух команд:
certutil –addstore –f SubCA <path\file.crt> — если вышестоящий CA не является корневым
certutil –addstore –f Root <path\file.crt> — если вышестоящий CA является корневым.
где <path\file.crt> — путь к файлу CER/CRT.

Q: Я отозвал сертификат, опубликовал новый CRL, однако при запуске файла сертификата я не вижу ошибок, что сертификат отозван. Почему?

A: Когда вы запускаете файл сертификата (просматриваете его содержимое), проверка на отзыв не происходит. Система только строит цепочку, но ни один сертификат на отзыв не проверяется. Это by design. Для проверки статуса сертификата вы можете воспользоваться следующими командами:
certutil –url <path\file.cer> — этой командой вызывается удобный графический интерфейс, в котором вы можете выяснить статус отзыва сертификата.
certutil –verify –urlfetch <path\file.cer> — данная команда выведет очень подробный текстовый лог проверки. Рекомендуется для использования профессионалами, которые в состоянии проанализировать этот лог.
где <path\file.cer> — путь к файлу проверяемого сертификата.

Q: Я отозвал сертификат, опубликовал новые CRL, однако certutil показывает, что сертификат не отозван. Как так?

A: Это вызвано тем, что CRL'ы, как и ответы от OCSP Responder кешируются в оперативной памяти и жёстком диске. Для обновления кеша в памяти, следует перезапустить приложение, которое проверяет статус сертификата. А на самом диске CRL кешируется на срок действия конкретного CRL. Это значит, что клиент будет использовать данный кешированный CRL до срока указанного в поле Next update конкретного CRL файла. Кеширование используется для экономии ресурсов и пропускной способности сети. Но вы можете очистить кеш CRL (при этом удалятся все кешированные CRL), вы можете воспользоваться следующей командой:
certutil -setreg chain\ChainCacheResyncFiletime @now
после этого обязательно следует выполнить следующую команду:
certutil –delreg chain\ChainCacheResyncFiletime
Данные команды поддерживаются системами начиная с Windows XP SP3. Предыдущие системы не поддерживают очистку кеша CRL.

Q: Какие протоколы разрешены для расширений CDP/AIA?

A: Для Windows систем доступны только следующие протоколы:
HTTP:// — только для публикации в расширение сертификата.
LDAP:// — для публикации физических файлов и для публикации ссылки в расширение сертификата.
FILE:// — только для публикации физических файлов в сетевой папке (например, на веб-сервере). Хотя Windows Server 2003 и предыдущие системы позволяли такие ссылки в расширениях CDP/AIA, начиная с Windows Vista/Windows Server 2008 они больше не допускаются и не используются.
C:\path — только для публикации физических файлов в файловой системе локального компьютера.
Более подробно можно прочитать по ссылке: CRL Distribution Points и Authority Information Access

Q: есть ли какие-то best practices по планированию расширений CDP/AIA?

A: да, существют определённые best practices по настройке расширений CDP/AIA на сервере CA. И вот как они выглядят в общем виде:
1) не следует использовать ссылки вида LDAP:// если ваши сертификаты могут использоваться вне пределах вашего леса AD. Это вызвано тем, что скачивать файлы по таким ссылкам могут только клиенты текущего леса, остальные клиенты будут получать ошибки по этим ссылкам. Целесообразно использовать более универсальные протоколы как HTTP. Данный протокол поддерживается множеством систем, в том числе и мобильными системами (смартфоны) и пользователями других операционных систем. При использовании HTTP рассмотрите возможность высокой доступности этих веб-серверов, как NLB-кластер или использования двух различных веб-серверов. В таком случае вы должны будете указать ссылки на скачивание файла для каждого веб-сервера.
2) используйте веб-сервера, которые доступны как изнутри сети, так и из интернета (если сертификаты могут использоваться пользователями интернета, например SSL-сертификаты) по одному и тому же URL.
3) при планировании ссылок, которые будут публиковаться в расширениях CDP/AIA сертификатов следует учитывать их очерёдность. Если вы решили использовать 2 независимых веб-сервера, первым указывайте тот, который будет являться основным. Это обусловлено тем, что клиент скачивает файлы по ссылкам в порядке их следования. Первая ссылка будет использоваться в первую очередь. Для ссылок публикации физического файла очерёдность не имеет значения.
4) для HTTP ссылок никогда не используйте SSL (т.е. HTTPS ссылки), поскольку это вызовет бесконечную проверку сертификатов, в результате чего вы никогда не скачаете нужный файл.
Более подробно можно прочитать по ссылкам: CRL Distribution Points и Authority Information Access, OCSP или CRL?

Q: Какие версии ОС Windows поддерживают нативного клиента OCSP?

A: Только ОС начиная с Windows Vista/Windows Server 2008 включают в себя клиента OCSP. Предыдущие системы никогда не поддерживали и не будут поддерживать клиента OCSP. Для них придётся приобретать отдельный программный продукт сторонних компаний.

Q: Я хочу использовать OCSP Responder как для внутренней, так и для внешней сети (интернета). На какое имя должен выдаваться сертификат OCSPResponseSigning?

A: на самом деле клиенту всё равно на какое имя выдаётся данный сертификат. Главное — сертификат должен отвечать следующим условиям:
1) должен быть выдан тем же CA для которого OCSP Responder осуществлял проверку статуса сертификата.
2) в Application Policies (Extended Key Usage) должен быть указан: OCSP Signing
3) в сертификате должно присутствовать расширение: OCSP No Revocation Checking
4) срок действия сертификата должен быть действующий.

Q: Мы в компании перешли на Windows Vista/Windows 7 и развернули OCSP Responder. Однако в сети уже выпущено огромное количество сертификатов, которые не содержат ссылок на OCSP Responder. Надо ли перевыпускать все сертификаты для включения в них ссылки на OCSP?

A: нет, вам не нужно перевыпускать все сертификаты, которые уже используются. Вы можете для доменных клиентов настроить групповую политику так, чтобы они получили адрес вашего OCSP Responder и которым они будут пользоваться при проверке сертификатов. В качестве руководства по настройке этой политики можете воспользоваться вот этой ссылкой: Appendix A: Managing OCSP Settings with Group Policy

Что бы почитать?

PowerShell Powered - http://www.sysadmins.lv

Certificate chaining engine (CCE) и отзыв корневых сертификатов

Camelot — Sun, 08 Nov 2009 17:20:10 GMT

Disclaimer: данный материал публикуется исключительно в учебных целях и его НЕ следует повторять! Любые действия описанные в данной статье вы можете делать ТОЛЬКО на свой страх и риск.

Мы с вами уже достаточно много обсудили про certificate chaining engine и расширения CDP в сертификатах и связанные с ними вопросы:

Но я решил немного расширить сознание по этому вопросу и рассмотреть ситуацию с отозванным корневым (который является и самоподписанным) сертификатом. Для экспериментов использовались CA под управлением Windows Server 2003 и Windows Server 2008 R2 (в обоих случаях поведение было идентичное). Штатно (из консоли certsrv.msc) у нас нет возможности отозвать корневой сертификат CA, но мы можем технически это сделать с использованием CryptoAPI COM интерфейсов. Сразу после отзыва корневого сертификата в свойствах CA мы увидим вот такую картинку:

и вот такое сообщение в журнале событий:

Log Name:      Application
Source:        Microsoft-Windows-CertificationAuthority
Date:          2009.11.08. 17:35:44
Event ID:      51
Task Category: None
Level:         Error
Keywords:      Classic
User:          SYSTEM
Computer:      RootCA
Description:
A certificate in the chain for CA certificate 0 for Adatum CA has been revoked. The certificate is revoked. 0x80092010 (-2146885616).

Всё, приехали, что дальше? А дальше мы рассмотрим актуальность наличия CDP в корневых сертификатах, при помощи которых мы можем посмотреть CRL рассматриваемого CA (это корневой CA, поэтому в его CDP могут быть ссылки только на его собственный CRL), как это делают некоторые публичные коммерческие CA (например, StartCom). Когда корневой сертификат отозван, мы продолжаем его не наблюдать в консоли certsrv.msc, но в БД это хорошо видно:

Request Status Code: 0x0 (WIN32: 0) -- The operation completed successfully.
Request Disposition: 0xf (15) -- CA Cert
Request Disposition Message: "Revoked by ADATUM\Administrator"
Request Submission Date: 2009.11.07. 22:41
Request Resolution Date: 2009.11.07. 22:41
Revocation Date: 2009.11.08. 17:35:43
Effective Revocation Date: 2009.11.08. 17:35:43
Revocation Reason: 0x0 -- Reason: Unspecified

Но мы же можем попробовать опубликовать новый CRL? Ответ — нет, не можете. Поскольку CRL подписывается закрытым ключом CA, то перед подписью CRL производится проверка валидности этого ключа для подписи CRL. Т.к. на данном этапе CA уже знает, что сертификат отозван, то ключ блокируется для подписи новых CRL, т.к. они будут считаться поддельными. Это будет первый аргумент в пользу отсутствия CDP в корневых сертификатах. Если CRL подписан отозванным ключом, то этот CRL должен игнорироваться по очевидным причинам.

Однако, тут есть одна интересная вещь — пока служба CertSvc не перезапущена, мы можем энролить новые сертификаты. Т.е. в этом промежутке клиенты могут нагенерить запросы и получить в ответ сертификаты. Это действительно проблема, потому что сертификаты так же подписываются закрытым ключом CA. И, по всей видимости, CA лишь с некоторой периодичностью проверяет валидность закрытого ключа для данной операции. Хотя, в случае с CRL эта проверка производится каждый раз перед подписью. После остановки службы CertSvc наш CA отключается навсегда:

Log Name:      Application
Source:        Microsoft-Windows-CertificationAuthority
Date:          2009.11.08. 17:42:21
Event ID:      100
Task Category: None
Level:         Error
Keywords:      Classic
User:          SYSTEM
Computer:      RootCA
Description:
Active Directory Certificate Services did not start: Could not load or verify the current CA certificate. Adatum CA The certificate is revoked. 0x80092010 (-2146885616).

А дальше становится ещё интересней. Методика работы CCE описана в RFC3280. Для администраторов PKI описываемый там материал нужно знать обязательно. Параграф 6 описывает процедуру построения цепочки сертификатов:

§ 6.1.

When the trust anchor is provided in the form of a self-signed
certificate, this self-signed certificate is not included as part of
the prospective certification path

Это означает, что самоподписанный сертификат (корневой таковым и является) исключается из проспективной цепочки сертификатов. А проверка CRL допускается только для этой проспективной цепочки.

§ 6.1.1.

The trusted anchor information is trusted because it was delivered
to the path processing procedure by some trustworthy out-of-band
procedure.

§ 9.

The certification path validation algorithm depends on the certain
knowledge of the public keys (and other information) about one or
more trusted CAs. The decision to trust a CA is an important
decision as it ultimately determines the trust afforded a
certificate.

Иными словами RFC предусматривает безоговорочное доверие конкретному корневому сертификату, когда доверие осуществляется каким-то механизмом (в Windows это наличие сертификата в Trusted Root CAs). И в § 6.1.3 говорится, что из цепочки (проспективной) удаляются все самоподписанные сертификаты, следовательно произвести проверку CRL можно только для сертификатов, которые в цепочке находятся на уровень ниже, чем самоподписанный сертификат. Это означает только одну вещь: если CCE является RFC3280-compliant, то он должен игнорировать расширение CDP в самоподписанном сертификате. Учитывая, что Windows CA технически не позволяет поместить свой сертификат в свой CRL, то скорее всего реализация CCE в CryptoAPI будет дейтсвовать адекватно и во всех случаях игнорировать это расширение. Поэтому даже при гипотетической возможности помещения отозванного корневого сертификата в его собственный CRL мы проигнорируем такой CRL и не узнаем, что корневой сертификат ВНЕЗАПНО был отозван.

Это была реклама VeriSign.

PowerShell Powered - http://www.sysadmins.lv

CRL Distribution Points и Authority Information Access

Camelot — Sun, 01 Nov 2009 15:53:06 GMT

Примечание: данный материал публикуется как обязательный для знания IT-специалистами, которые занимаются или только собираются заниматься темой PKI (Public Key Infrastructure).

Большинство системных администраторов считают, что планирование списков отзыва сертификатов (Certificate Revocation List — CRL) и файлов сертификатов самих серверов CA — это элементарная вещь. Но практика показывает, что очень многие из них сильно заблуждаются. Поэтому предлагаю немного повременить с CryptoAPI и поговорить о немного более насущных вещах — рекомендации по планированию публикации списков CRL и сертификатов CA (Certification Authority), которые используются certificate chaining engine для построения и проверок цепочек сертификатов. О том, как работает этот движок можете почитать пост: Certificate Chaining Engine — как это работает.

Куда и как публиковать файлы CRL и CRT?

Как известно, каждый выданный в CA сертификат (кроме самоподписанных сертификатов. Корневой сертификат так же является самоподписанным сертификатом) содержит 2 расширения:

В расширении «CRL Distribution Points (CDP)» хранятся ссылки на CRL издавшего конкретный сертификат CA;
В расширении «Authority Information Access (AIA)» хранятся ссылки на сертификат CA, издавшего конкретный сертификат. А для сертификатов, выданных CA под управлением Windows Server 2008 и выше — могут содержаться ссылки на OCSP Responder (см. OCSP (часть 1) и OCSP (часть 2))

Эти ссылки берутся не из воздуха, а из настроек CA. Вот как они выглядят для дефолтной инсталляции Certificate Services:

В принципе, эти настройки годятся для нормальной работы certificate chaining engine в небольших сетях с одним лесом и доменом без сайтов (или с сайтами, соединённых быстрыми каналами). Если сеть состоит из нескольких доменов (или лесов с настроенным Cross-forest enrollment) и сайтами, соединённых не очень быстрыми каналами, то эти настройки уже могут приводить к сбоям построения и проверок цепочек сертификатов. Я не буду рассказывать, что означают галочки, т.к. с ними вы можете ознакомиться в статьях CRL Publishing Properties и AIA Publishing Properties, а приступлю сразу к разбору путей.

Первый путь указывает путь файловой системы, куда физически публикуются файлы CRL и CRT. Следующая ссылка (LDAP://{LDAP path}) указывает, точку публикации CRL и CRT в Active Directory. Так же эти пути будут прописаны во всех выдаваемых сертификатах. Третья ссылка (HTTP://{URL}) указывает URL, по которому клиенты могут скачать файл через HTTP и этот URL будет включён в расширение CDP/AIA всех выдаваемых сертификатов. Последняя ссылка ничего не делает и добавлена в целях дополнительной точки публикации файлов CRL/CRT в сетевой папке. Почему эти настройки не оптимальны для больших сетей?

Вот как будут выглядеть расширения CDP и AIA в выдаваемых сертификатах при таких настройках:

CDP

[1]CRL Distribution Point
     Distribution Point Name:
          Full Name:
URL=ldap:///CN=Contoso%20CA,CN=DC1,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=contoso,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint
               URL=http://dc1.contoso.com/CertEnroll/Contoso%20CA.crl

AIA

[1]Authority Info Access
     Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
     Alternative Name:
URL=ldap:///CN=Contoso%20CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=contoso,DC=com?cACertificate?base?objectClass=certificationAuthority
[2]Authority Info Access
     Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
     Alternative Name:
          URL=http://dc1.contoso.com/CertEnroll/DC1.contoso.com_Contoso%20CA.crt

Как вы видите, ссылки в расширениях расположены в том же порядке, что и в настройках CA.

Это важно знать, поскольку certificate chaining engine (сокращённо назовём его CCE) будет проверять ссылки в том порядке, в котором они приведены в расширениях сертификата. Т.е. сперва будет пробовать скачать файл из Active Directory в течении 10 секунд. Если за 10 секунд файл не скачается, CCE будет пытаться скачать указанный файл по следующей ссылке (HTTP). При этом времени на это будет отводиться в 2 раза меньше (т.е. 5 секунд), чем в предыдущей попытке. И так будет происходить с каждой последующей ссылкой, пока не будет добыт файл, закончатся ссылки или отвалится по таймауту. На обработку каждого расширения для CCE выделяется ровно 20 секунд.

Уже на данном этапе видно, что любой недоменный клиент (будь то смартфон, изолированная рабочая станция в интернете, etc.) при попытке скачать файл может терять до 10 секунд на обработку первой ссылки, которая всегда завершится неудачей. Следовательно, первой ссылкой в CDP/AIA должна быть ссылка, которая использует универсальный для всех протокол (это должен быть HTTP), не смотря на то, что в домене, где расположен CA доступ через LDAP будет чуточку быстрее.

Второй момент заключается в репликации объектов AD. После того как CRL/CRT были опубликованы в Active Directory, клиенты об этом узнают не сразу, т.к. здесь вступает фактор репликации AD. Поскольку все объекты PKI публикуются в AD в разделе forest naming context, то эти данные реплицируются не только в прелелах текущего домена, но и всего леса. Поэтому задержки в появлении новых файлов у клиентов могут быть очень значительными и достигать нескольких часов. Задержки могут составлять время до двух полных циклов полной репликации в лесу. А если у вас используется cross-forest enrollment, то там ситуация будет ещё хуже, поскольку это ещё будет зависить от периодичности репликации объектов PKI между лесами (AD не поддерживает репликацию между лесами и репликация объектов PKI выполняется вручную) и уже может достигать нескольких суток. По этой причине рекомендуется либо вовсе отказаться от публикации CRL/CRT в AD и включения этих ссылок в сертификаты, либо располагать следом за более доступными протоколами.

С HTTP тоже не всё так идеально, как это может показаться с первого взгляда. Совсем не обязательно, чтобы сервер CA выполнял и роль веб-сервера (хотя, только для внутреннего использования это допустимо с определёнными оговорками). Будет лучше даже если файлы CRL/CRT будут копироваться как на внутренний, так и на внешний веб-серверы. В идеале эти файлы должны копироваться как минимум на 1-2 внутренних и 1-2 внешних веб-сервера для обеспечения высокой доступности. В таких случаях уже используется 4-я ссылка в настройках CA, которая должна указываь на шару DFS, чтобы файлы автоматически распространялись по веб-серверам. И вот здесь мы снова сталкиваемся с латентностью репликации DFS между серверами. Если все схемы публикации CRL/CRT подвержены латентности репликации, то как с этим бороться, чтобы файлы были всегда в актуальном состоянии?

Примечание: хоть CCE поддерживает скачивание CRL и CRT с HTTPS ссылок, делать это категорически нельзя, иначе CCE свалится в бесконечный цикл проверки сертификатов.

Периодичность публикации и обновления файлов CRL и CRT

По умолчанию в Windows Server основные CRL (Base CRL) публикуются раз в неделю и инкрементные CRL (Delta CRL) публикуются раз в сутки. Файлы сертификатов CA обычно обновляются через промежутки равные времени жизни сертификата самого CA (или чаще, если сертификат CA обновляется внепланово). Если сертификаты CA нужно обновлять достаточно редко (раз в несколько лет) и к этому следует готовиться отдельно, то обновление CRL происходит автоматически без вмешательства администратора и здесь требуются особые корректировки о которых мы сейчас и поговорим.

Если посмотреть на CRL, то мы увидим следующее:

Сейчас нас будут интересовать только 3 поля:

Effective Date — указывает дату и время с которого данный CRL считается действительным и оно по умолчанию на 10 минут меньше, чем фактическое время, чтобы покрыть издержки рассинхронизации времени между сервером и клиентом;
Next Update — указывает дату и время, когда заканчивается срок действия конкретного CRL и он считается недействительным;
Next CRL Publish — указывает дату и время публикации следующего списка CRL.

Примечение: время в этих полях указывается в формате UTC без учёта временных зон.

Обычно время Next Update и Next CRL Publish одинаково. Но у меня, как вы видите на картинках, Next Update равен 8 дням (дефолтный срок действия CRL), а вот Next CRL Publish равен 7 дням после начала действия CRL. Т.е. CRL обновляется каждые 7 дней, но срок действия равен 8 дням (период публикации CRL + время overlap). Это сделано как раз для покрытия расходов времени (издержки репликации) распространения списков отозванных сертификатов от сервера CA до точек, откуда клиенты будут скачивать CRL. Как это делается?

Для этого в реестре на сервере CA по пути HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\CA Name существует 4 ключа:

CRLOverlapUnits — указывает время до истечения срока действия текущего основного CRL, за которое будет публиковаться новый основной CRL.
CRLOverlapPeriod — указывает единицу измерения этого времени для основного CRL
CRLDeltaOverlapUnits — указывает время до истечения срока действия текущего инкрементального (если используется) CRL, за которое будет публиковаться новый инкрементальный CRL
CRLDeltaPeriodPeriod — указывает единицу измерения этого времени для инкрементального CRL.

Если вы используете LDAP ссылки в расширениях CDP/AIA сертификатов и/или у вас есть латентность репликации файлов между веб-серверами, то вы должны отрегулировать это время, которое должно быть не менее, чем максимальное время репликации каталога AD во всём лесу или DFS как для основных, так и для инкрементальных CRL (если они у вас используются). Данную операцию можно автоматизировать утилитой certutil:

certutil –setreg ca\CRLOverlapUnits 1
certutil –setreg ca\CRLOverlapPeriod "days"
certutil –setreg ca\CRLDeltaOverlapUnits 8
certutil –setreg ca\CRLDeltaOverlapPeriod "hours"
net stop certsvc & net start certsvc

Примечание: CRLOverlap не может быть больше периодичности публикации BaseCRL, а CRLDeltaOverlap не может быть больше 12 часов.

в результате новые основные CRL будут публиковаться за сутки до истечения времени действия предыдущего основного CRL и новые инкрементальные CRL будут публиковаться за 8 часов до истечения предыдущего. Этим самым вы сможете гарантировать, что клиенты всегда получат актуальные CRL'ы. Более детальные сведения о порядке подсчёта временных интервалов публикации CRL и срока их действия можно ознакомиться здесь: How EffectiveDate (thisupdate), NextUpdate and NextCRLPublish are calculated

Общая периодичность публикации самих файлов CRL зависит от количества отзываемых сертификатов за некоторый промежуток времени (обычно измеряется в неделях). Если сертификаты отзываются десятками в неделю, то есть смысл сократить периодичность публикации основных CRL до 2 раз в неделю и Delta CRL до 2-х раз в сутки. Если сертификаты отзываются редко (реже, чем раз в неделю), то периодичность публикации Base CRL можно увеличить до 2-4 недель, а от Delta CRL можно даже отказаться или публиковать раз в неделю. Но это касается только Issuing или Online CA. Для Offline CA рекомендации будут чуть другие. Поскольку Offline CA выдают сертификаты только другим CA и большую часть времени выключены, для них следует отключить публикацию Delta CRL (установив параметр CRLDeltaPeriodUnits в ноль), а основные CRL публиковать раз в 3-12 месяцев. Хоть это и Offline CA, но на него так же распространяются требования по корректировке времени публикации и срока действия CRL.

CDP и AIA в корневых сертификатах

Как уже отмечалось, расширения CDP и AIA содержат ссылки на CRL/CRT издавшего конкретный сертификат CA, то с корневыми сертификатами будет немного иначе. Если быть точнее, то в корневых сертификатах этих расширений быть не должно совсем. Почему? Windows Server 2003 по умолчанию добавлял эти расширения в самоподписанный сертификат, когда CA конфигурировался как корневой CA. В нём AIA содержал ссылки по которым можно было скачать этот же сертификат. Очень прикольно .

А CDP — не менее прикольно. Корневые сертификаты всегдя являются конечной точкой самой цепочки и доверия этой цепочки сертификатов. К корневым сертификатам доверие всегда устанавливается явное путём помещения сертификата в контейнер Trusted Root CAs (а ко всем остальным сертификатам устанавливается неявное доверие через цепочку сертификатов). Следовательно отменить доверие корневому сертификату CA можно только одним способом — удалить сам сертификат из контейнера Trusted Root CAs и никак иначе. Вторая проблема заключается в том, что все CRL подписываются закрытым ключом самого CA. А теперь предположим, что CA отозвал свой сертификат и поместил его в CRL. Клиент скачивает CRL и видит, что сертификат CA отозван. Можно предположить, что это всё и никакой проблемы здесь нет. Однако, получается, что CRL подписан отозванным сертификатом и мы не можем доверять этому CRL как и считать сертификат CA отозванным. Именно поэтому начиная с Windows Server 2008 при установке корневого CA, эти расширения по умолчанию уже не включены в корневой сертификат. А для Windows Server 2003 приходилось лепить костыли в файле CAPolicy.inf:

[AuthorityInformationAccess]
Empty = true
[CRLDistributionPoint]
Empty = true

Как показывает практика, очень много администраторов игнорируют такие вещи и делают всё простым Next-Next, за что они должны гореть в аду. Но не только простые Windows-админстраторы, а луноходы (фаны линукса) тоже должны там гореть. Как живой пример бардака в сертификатах приведу компанию StartCom, которая в сентябре 2009 получила право выдавать EV (Extended Validation) сертификаты и вот их корневой сертификат: http://www.startssl.com/sfsca.crt

Мало того, что у них в корневом сертификате есть расширение CDP, но и с ссылками на CRL у них в цепочке тоже бардак мутный. Есть подозрение, что это сделано для поддержки какой-то ветки линукса (для совместимости или просто как костыль), но вот такой он опенсорс. Так что не каждый публичный и коммерческий CA следует всем бест-практисам. А вам советую им следовать, тогда меньше вероятность, что вы потом будете гореть в аду.

Изменения в существующих инфраструктурах

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

пути публикации физических файлов можно располагать в произвольном порядке;
новые ссылки к файлам, по которым клиенты будут их скачивать должны располагаться первыми, т.е. с более высоким приоритетом (кроме случаев, когда вы добавляете ссылки только для обеспечения более высокой доступности файлов. Тогда новые ссылки можно просто добавить в хвост уже существующим);
если вы собираетесь уйти от существующих ссылок на CRL/CRT, то в для них следует отключить опцию публикации ссылок в сертификатах. Однако, до окончания действия сертификата CA вы будете обязаны их поддерживать в рабочем состоянии, т.к. они содержатся в уже выданных сертификатах. А новые ссылки появятся только в сертификатах, которые были выпущены после изменения CDP/AIA.
если у вас корневой сертификат уже содержит расширения CDP/AIA, то вы не можете их оттуда убрать до момента обновления корневого сертификата. При обновлении корневого сертификата на Windows Server 2003, вам потребуется создать CAPolicy.inf файл, прописать нужные настройки (например, как уже указано выше с пустыми CDP и AIA). Более подробно про файл CAPolicy.inf можно прочитать по ссылке: http://technet.microsoft.com/en-us/library/cc728279(WS.10).aspx

Новые технологии

С выходом Windows Server 2008 Enterprise Edition вы можете внедрить в своей сети Online Responder для снижения нагрузки на серверы публикации CRL (хоть пути к OCSP публикуются в расширении AIA, к файлам CRT это никакого отношения не имеет). Но даже внедрение OCSP не решает этих проблем, поскольку реализация OCSP в Windows Server основана на регулярном чтении CRL и, следовательно, зависит от латентности репликации AD и/или DFS, а так же этим сервисом могут пользоваться только клиенты начиная с Windows Vista. Хочу отметить один приятный момент. Если изменения ссылок на CRL/CRT скажутся только на новых сертификатах (уже выпущенные сертификаты ничего не будут знать о новых путях в CDP/AIA), то интегрировать OCSP внутри домена/леса с уже существующей инфраструктурой PKI достаточно легко. Все уже выданные сертификаты могут быть проверены на отзыв с использованием OCSP: Managing OCSP Settings with Group Policy.

Заключение

В данном посте я обозначил ключевые моменты в структуированном (как мне кажется) виде, которые следует знать при планировании публикации файлов CRL/CRT и ссылок на них. Как вы видите, внедрение новых технологий пока что не освобождает от знания и соблюдения рекомендаций публикации CRL/CRT в вашей инфраструктуре PKI. Я считаю этот материал достаточным для начального и среднего уровня знаний по теме revocation и chain building и для более детального изучения всего этого процесса уже следует обратиться сюда: Certificate Revocation Checking in Windows Vista and Windows Server 2008.

PowerShell Powered - http://www.sysadmins.lv

Certificate chaining engine в PowerShell (часть 2)

Camelot — Mon, 19 Oct 2009 18:52:44 GMT

Примечание: данный материал публикуется на правах ТЗ (ТЗ — Тайное Знание) и обязателен для знания администраторам PKI.

В предыдущей части (Certificate chaining engine в PowerShell) мы рассмотрели реализацию certificate chaining engine в .NET в виде класса X509Chain. Но этот рассказ был бы неполным, если мы не поговорили про CAPICOM.Chain. Хоть Microsoft рекомендует использовать .NET, а не CAPICOM для решения данной задачи, я считаю необходимым осветить этот вопрос. Для начала начнём с реализации CAPICOM в PowerShell. По непонятным мне пока причинам мне не удалось завести его в PowerShell на системах Windows Vista и выше, поэтому примеры буду приводить на Windows Server 2003.

PS G:\> $chain = New-Object -ComObject "CAPICOM.Chain"
PS G:\> $chain

Certificates
------------



PS G:\> $chain | gm -MemberType methods


   TypeName: System.__ComObject#{ca65d842-2110-4073-aee3-d0aa5f56c421}

Name                MemberType Definition
----                ---------- ----------
ApplicationPolicies Method     IOIDs ApplicationPolicies ()
Build               Method     bool Build (ICertificate)
CertificatePolicies Method     IOIDs CertificatePolicies ()
ExtendedErrorInfo   Method     string ExtendedErrorInfo (int)


PS G:\>

Так же, как и в .NET у нас есть метод Build(), который запускает certificate chaining engine для указанного сертификата. Но это COM объект и X509Certificate2 объекты не принимает. Поэтому мы средствами этого же CAPICOM получим нужный объект сертификата:

PS G:\> $store = New-Object -ComObject "CAPICOM.Store"
PS G:\> $store.Open(2,"my",128)
PS G:\> $cert = @()
PS G:\> $store.Certificates | %{$cert += $_}
PS G:\> $cert = $cert[1]
PS G:\> $cert


Version       : 3
SerialNumber  : 167D6D32000000000011
SubjectName   : CN=Administrator, CN=Users, DC=sysadmins, DC=lv
IssuerName    : CN=sysadmins-LV-CA, DC=sysadmins, DC=lv
ValidFromDate : 2009.08.07. 16:09:56
ValidToDate   : 2010.08.07. 16:09:56
Thumbprint    : 1FA71B51BCE461BEE24B11AA9EF855ED00DFDFD4
Archived      : False
PrivateKey    :



PS G:\>

Вот такой объект сертификата мы получили. Вот его и пропустим через метод Build():

PS G:\> $chain.Build($cert)
False
PS G:\> $chain.Status()
32
PS G:\> $chain.Certificates


Version       : 3
SerialNumber  : 167D6D32000000000011
SubjectName   : CN=Administrator, CN=Users, DC=sysadmins, DC=lv
IssuerName    : CN=sysadmins-LV-CA, DC=sysadmins, DC=lv
ValidFromDate : 2009.08.07. 16:09:56
ValidToDate   : 2010.08.07. 16:09:56
Thumbprint    : 1FA71B51BCE461BEE24B11AA9EF855ED00DFDFD4
Archived      : False
PrivateKey    :

Version       : 3
SerialNumber  : 3DFFAF914D613282427BD591C1FB586D
SubjectName   : CN=sysadmins-LV-CA, DC=sysadmins, DC=lv
IssuerName    : CN=sysadmins-LV-CA, DC=sysadmins, DC=lv
ValidFromDate : 2009.08.06. 10:21:01
ValidToDate   : 2014.08.06. 10:30:54
Thumbprint    : E82ACC45841280DDEAB9F7847418FA26354457A7
Archived      : False
PrivateKey    :



PS G:\> $chain.ApplicationPolicies()

                                   Name FriendlyName                            Value
                                   ---- ------------                            -----
                                    123 Smart Card Logon                        1.3.6.1.4.1.311.20.2.2
                                    101 Client Authentication                   1.3.6.1.5.5.7.3.2


PS G:\>

Метод вернул False, т.е. наш сертификат не прошёл проверку. Свойство Certificates содержит все сертификаты в текущей цепочке. А метод ApplicationPolicies() показал Application Policies (в прошлом EKU). Ну и метод Status() вернул код ошибки. Все коды ошибок расписаны в описании самого метода. Т.е. ошибка 32 по табличке означает:

CAPICOM_TRUST_IS_UNTRUSTED_ROOT (&H00000020) — The certificate or certificate chain is based on an untrusted root.

Особо углубляться дальше я смысла не вижу, поскольку используя эти примеры можно поупражняться в других задачах с использованием CAPICOM. А вместо этого, мы разберём кое-какие неочевидные, но очень важные вещи.

Когда вышел Remote Desktop Connection 7.0 (который поставляется вместе с Windows 7), Александр Станкевич (MVP: Enterprise Security) заметил очень плохую особенность с ним, а именно — рандомно пропал доступ к терминальным серверам, которые используют SSL для терминальных подключений. В ходе множества проверок было констатировано:

цепочка завершалась на доверенном корневом сертификате (через просмотр сертификата);
CDP/AIA пути были валидные и CRL не были просрочены;
остальные параметры были сконфигурированы верно.

RDP клиент мотивировал отказ в подключении следюущим: «RDP клиент не смог проверить сертификат на отзыв». Причём подключение с предыдущих версий RDC, а так же подключение к TS Web Access через IE было успешным. Как выяснилось на днях, причина была в том, что в новом RDC был изменён алгоритм certificate chaining engine и новая версия RDC больше не доверяла корневым сертификатам в пользовательском хранилище. Переустановка корневого сертификата в компьютерное хранилище решала проблему RDC 7. Но, как я говорил, в Windows 7/2008 R2 было изменено поведение certificate chaining engine в реализации X509Chain. Продемонстрирую небольшую табличку, которая покажет доверие пользовательским корневым сертификатам в CAPICOM и .NET реализациях certificate chaining engine для различных операционных систем:

	X509Chain (.NET)	CAPICOM.Chain (CryptoAPI)
Windows XP
Windows Server 2003
Windows Vista
Windows Server 2008
Windows 7
Windows Server 2008 R2

Таблица доверия пользовательскким корневым сертификатам различными движками построения цепочки сертификатов

Следует учитывать, что различные приложения могут использовать свой движок для построения цепочек сертификатов, как RDC 7.0 и PKIView.msc использует CAPICOM, а PowerShell — X509Chain. Однако, у меня есть уверенность, что существует ещё одна реализация этого движка, которую использует Internet Explorer. Это только мои догадки, но они основаны на том, что Internet Explorer (кроме Windows 7 и выше) использует пользовательский контейнер для проверки SSL веб-сайтов, т.е. по симптомам похоже на X509Chain. Однако, этот класс появился только в .Net Framework 2.0, которого, к примеру в оригинальной инсталляции Windows XP/2003 не было. Либо, как вариант, есть возможность настраивать этот момент в каждой реализации движка построения цепочек, но я пока не нашёл как. Это пока всё, что у меня есть по этому поводу.

PowerShell Powered - http://www.sysadmins.lv

Certificate chaining engine в PowerShell

Camelot — Sat, 17 Oct 2009 20:51:59 GMT

Я предлагаю снова поговорить о certificate chaining engine, о котором мы уже говорили в посте Certificate Chaining Engine — как это работает но в рамках его реализации в .NET и PowerShell. В Windows есть несколько реализаций этого chaining engine. Самые популярные:

CAPICOM — вещь несколько стрёмная и её лучше избегать. Тем более мне не удалось завести его в Vista/Windows 7. Реализация в .NET в виде X509Chain ничуть не хуже, но, в то же время, проще. Итак, предлагаю начать с создания этого объекта с помощью New-Object:

[↓] [vPodans] $chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
[↓] [vPodans] $chain

                 ChainContext ChainPolicy                   ChainStatus                   ChainElements
                 ------------ -----------                   -----------                   -------------
                            0 System.Security.Cryptograp... {}                            {}


[↓] [vPodans] $chain | gm -membertype methods


   TypeName: System.Security.Cryptography.X509Certificates.X509Chain

Name        MemberType Definition
----        ---------- ----------
Build       Method     bool Build(System.Security.Cryptography.X509Certificates.X509Certificate2 certificate)
Equals      Method     bool Equals(System.Object obj)
GetHashCode Method     int GetHashCode()
GetType     Method     type GetType()
Reset       Method     System.Void Reset()
ToString    Method     string ToString()


[↓] [vPodans]

Здесь видно, что метод, который будет строить и проверять цепочку будет называться Build() и в качестве аргумента этот метод принимает только объекты x509Certificate2, а возвращать объект типа Boolean — True/False. Объекты такого типа можно найти в провайдере Certififcates (просто выполнить dir cert:\store\container) или импортировать из файла — Импорт сертификатов в PowerShell. Но сначала мы посмотрим, что здесь можнол настроить. А настроить можно ChainPolicy, представляющий собой объект X509ChainPolicy. Эта политика позволяет задавать порядок проверки отзыва сертификатов, соответствие сертификата каким-то certificate policy, наличие определённых application policy (в прошлом известен нам как EKU — Extended Key Usage) и некритичность каких-то ошибок. Мы всё разбирать не будем, а только основное:

[↓] [vPodans] $chain.ChainPolicy


ApplicationPolicy   : {}
CertificatePolicy   : {}
RevocationMode      : Online
RevocationFlag      : ExcludeRoot
VerificationFlags   : NoFlag
VerificationTime    : 17.10.2009 20:35:17
UrlRetrievalTimeout : 00:00:00
ExtraStore          : {}



[↓] [vPodans]

Первое, что может быть интересным — Revocation Mode, который задаёт режим проверки отзыва и может иметь 3 вполне понятных значения, которые перечислены в X509RevocationMode:

[↓] [vPodans] [System.Enum]::GetNames([system.security.cryptography.x509certificates.x509revocationmode])
NoCheck
Online
Offline

Тут очень просто:

NoCheck — проверяет цепочку сертификатов без проверки на отзыв любых сертификатов в цепочке;
Online — проверяет сертификаты в цепочке скачивая новые списки CRL из свойства CDP сертификата, игнорируя локальный кеш CRL (используется по умолчанию, как это видно в просмотре свойств ChainPolicy)
Offline — проверяет сертификаты на отзыв с использованием кешированного CRL (если есть).

Если проверяем сертификаты на отзыв, то мы можем выбрать что именно будем проверять и этот выбор перечислен в X509RevocationFlag:

[↓] [vPodans] [System.Enum]::GetNames([system.security.cryptography.x509certificates.x509revocationflag])
EndCertificateOnly
EntireChain
ExcludeRoot

и здесь тоже всё достаточно понятно:

EndCertificateOnly — проверяет на отзыв только сам проверяемый сертификат. Остальные сертификаты в цепочке не проверяются;
EntireChain — проверяет на отзыв абсолютно все сертификаты в цепочке включая корневой сертификат. Правила хорошего тона диктуют нам не включать в корневой сертификат CA поля CDP и AIA, поскольку это лишено смысла и в большинстве случаев с этим флагом вы будете получать невалидную цепочку;
ExcludeRoot — проверяет на отзыв все сертификаты в цепочке, кроме корневого сертификата, что есть религионзно правильно и этот флаг установлен по умолчанию.

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

[↓] [vPodans] [System.Enum]::GetNames([system.security.cryptography.x509certificates.x509verificationflags])
NoFlag
IgnoreNotTimeValid
IgnoreCtlNotTimeValid
IgnoreNotTimeNested
IgnoreInvalidBasicConstraints
AllowUnknownCertificateAuthority
IgnoreWrongUsage
IgnoreInvalidName
IgnoreInvalidPolicy
IgnoreEndRevocationUnknown
IgnoreCtlSignerRevocationUnknown
IgnoreCertificateAuthorityRevocationUnknown
IgnoreRootRevocationUnknown
AllFlags

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

Примечание: эти флаги показывают что будет исключено из проверки, а не наоборот. По умолчанию проверяется всё (установлен NoFlag).

Как можно задавать эти флаги и режимы, если есть такая потребность? Можно пойти двумя способами — правильным и неправильным, хотя оба рабочие:

[↓] [vPodans] # правильный метод:
[↓] [vPodans] $revflag = [System.Security.Cryptography.X509Certificates.X509RevocationFlag]::EndCertificateOnly
[↓] [vPodans] $chain.ChainPolicy.RevocationFlag = $revflag
[↓] [vPodans] $chain.ChainPolicy


ApplicationPolicy   : {}
CertificatePolicy   : {}
RevocationMode      : Online
RevocationFlag      : EndCertificateOnly
VerificationFlags   : NoFlag
VerificationTime    : 17.10.2009 20:35:17
UrlRetrievalTimeout : 00:00:00
ExtraStore          : {}



[↓] [vPodans] # неправильный метод, но мне он нравится
[↓] [vPodans] $chain.ChainPolicy.RevocationFlag = "excluderoot"
[↓] [vPodans] $chain.ChainPolicy


ApplicationPolicy   : {}
CertificatePolicy   : {}
RevocationMode      : Online
RevocationFlag      : ExcludeRoot
VerificationFlags   : NoFlag
VerificationTime    : 17.10.2009 20:35:17
UrlRetrievalTimeout : 00:00:00
ExtraStore          : {}



[↓] [vPodans]

В принципе, все эти enumeration можно просто указывать в виде строки, а PowerShell уже сам подобъёт его под нужный тип.

Примечание: флаги проверки на отзыв можно указывать только по одному, а флаги исключений можно перечислять через запятую. Это видно по названию класса: если класс указан в единственном числе (X509RevocationFlag), то и значение можно указать только одно, а если во множественном числе (X509VerificationFlags), то их можно указать несколько через запятую.

В принципе, можно делать проверку:

[↓] [vPodans] $valid = (dir cert:\currentuser\my)[1]
[↓] [vPodans] $invalid = (dir cert:\currentuser\my)[0]
[↓] [vPodans] $chain.Build($valid)
True
[↓] [vPodans] $chain.ChainElements | select -expand certificate

Thumbprint                                Subject
----------                                -------
986D375362652FE9E39BA4D042A6B8BA75745998  CN=Administrator, CN=Users, DC=sysadmins, DC=lv
E82ACC45841280DDEAB9F7847418FA26354457A7  CN=sysadmins-LV-CA, DC=sysadmins, DC=lv


[↓] [vPodans]

Я из локального хранилища взял заведомо хороший сертификат и плохой (разумеется, это сертификат с сайта БиЛайн ). Метод Build() вернул True, что означает успешную проверку всей цепочки моего сертификата до доверенного корня. А вот что случилось с сертификатом билайна:

[↓] [vPodans] $chain.reset()
[↓] [vPodans] $chain.Build($invalid)
False
[↓] [vPodans] $chain.ChainElements | select -expand certificate

Thumbprint                                Subject
----------                                -------
EB74DA32E865C78FCB853DDA5FE45962098E1B3B  CN=trust.beeline.ru, OU=DIT, O=Vimpelcom, L=Moscow, S=Moscow, C=RU


[↓] [vPodans] $chain.ChainStatus

                                                     Status StatusInformation
                                                     ------ -----------------
                                               PartialChain Sertificesanas kedi nevareja veidot pie uzticamas saknes...
                                    RevocationStatusUnknown Atsauksanas funkcija nevareja parbaudit sertifikata atsa...
                                          OfflineRevocation Atsauksanas funkcija nevareja parbaudit atsauksanu, jo a...


[↓] [vPodans] $chain.ChainStatus | %{$_.statusinformation.trim()}
Sertificesanas kedi nevareja veidot pie uzticamas saknes iestades.
Atsauksanas funkcija nevareja parbaudit sertifikata atsauksanu.
Atsauksanas funkcija nevareja parbaudit atsauksanu, jo atsauksanas serveris bija bezsaiste.
[↓] [vPodans]

Поскольку при каждой проверке сертификаты в ChainElements накапливаются, то после каждой проверки следует очищать объект методом Reset(). Как и следовало ожидать, сертификат билайна вернул False, показывая, что цепочка у этого сертификата имеет проблемы. В случае неуспешной проверки, будет заполняться свойство ChainStatus. Данное свойство содержит все ошибки, которые были костатированы при проверке цепочки. Для меня пока непонятным стал факт, что ошибки он написал на латышском языке, хотя я его об этом не просил. Откуда он это взял — непонятно, но он сказал, что не смог построить цепочку до доверенного корня и функция проверки отзыва провалилась по всем статьям, поскольку пути в CDP сертификата нерабочие.

Примечание: обязательно следует учитывать тот факт, что при построении цепочки сертификатов и проверке доверия класс X509Chain в Windows 7 и Windows Server 2008 R2 работает в контексте LocalSystem и всегда игнорирует пользовательские контейнеры Trusted Root Certification Authorities. Поэтому если корень цепочки не заканчивается на одном из сертификатов Trusted Root CAs хранилища LocalMachine, то цепочка будет считаться недоверенной. Для предыдущих ОС цепочка может заканчиваться на пользовательском хранилище Current User.

В принципе это всё, что вам следует знать про реализацию certificate chaining engine в .NET и его использование в PowerShell. В качестве бонуса прилагаю скрипт для проверки цепочки сертификатов:

#####################################################################
# Test-Certificate.ps1
# Version 1.0
#
# Passes certificate through certificate chaining engine
#
# Vadims Podans (c) 2009
# http://www.sysadmins.lv/
#####################################################################
#requires –Version 2.0

function Test-Certificate {
[CmdletBinding()]
    param(
        [Parameter(Mandatory = $true, ValueFromPipeline = $true, Position = 0)]
        $Certificate,
        [System.Security.SecureString]$Password,
        [ValidateSet("NoCheck", "Online", "Offline")]
        [string]$CRLMode = "Online",
        [ValidateSet("EndCertificateOnly", "EntireChain", "ExcludeRoot")]
        [string]$CRLFlag = "ExcludeRoot",
        [ValidateSet("AllFlags", "AllowUnknownCertificateAuthority", "NoFlag", "IgnoreNotTimeValid",
            "IgnoreCtlNotTimeValid", "IgnoreNotTimeNested", "IgnoreInvalidBasicConstraints",
            "IgnoreWrongUsage", "IgnoreInvalidName", "IgnoreInvalidPolicy", "IgnoreEndRevocationUnknown",
            "IgnoreCtlSignerRevocationUnknown", "IgnoreCertificateAuthorityRevocationUnknown",
            "IgnoreRootRevocationUnknown")]
        [string[]]$VerificationFlags = "NoFlag"
    )
    
    begin {
        # создаём объекты X509Certificate2 и X509chain ещё до поступлениея первого объекта сертификата
        $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
        $chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
        # в X509Chain записываем параметры проверки сертификатов. Как критерии
        # отзыва, так и исключения из проверки
        $chain.ChainPolicy.RevocationFlag = $CRLFlag
        $chain.ChainPolicy.RevocationMode = $CRLMode
        $chain.ChainPolicy.VerificationFlags = $VerificationFlags
        # мини-функция для предоставления понятного вывода на экран о статусе проверки
        # и ошибках в цепочке, если они есть.
        function _getstatus_ ($status, $chain, $cert) {
            if ($status) {
                Write-Host Current certificate $cert.SerialNumber chain and revocation status is valid -ForegroundColor Green
            } else {
                Write-Warning "Current certificate $($cert.SerialNumber) chain is invalid due of the following errors:"
                $chain.ChainStatus | %{Write-Host $_.StatusInformation.trim() -ForegroundColor Red}
            }
        }
    }
    
    process {
        # если аргумент сертификата уже является объектом X509Certificate2, то
        # сразу строим цепочку и получаем статус цепочки вызывая мини-функцию
        if ($_ -is [System.Security.Cryptography.X509Certificates.X509Certificate2]) {
            $status = $chain.Build($_)
            _getstatus_ $status $chain $_
        } else {
        # если аргумент не является объектом X509Certificate2, то это будет путь к файлу
        # если указанный путь не существует, то ругаемся и выходим
            if (!(Test-Path $Certificate)) {Write-Warning "Specified path is invalid"; return}
            else {
            # если путь существует, то проверяем, что это путь файловой системы.
            # если это не так, то ругаемся и выходим
                if ((Resolve-Path $Certificate).Provider.Name -ne "FileSystem") {
                    Write-Warning "Spicifed path is not recognized as filesystem path. Try again"; return
                } else {
                # если предварительные проверки прошли успешно, то выбираем объект файла
                    $Certificate = gi $(Resolve-Path $Certificate)
                # и на основании расширения файла через Switch преобразуем файл в
                # X509Certificate2 объект или объекты
                    switch -regex ($Certificate.Extension) {
                    "\.CER|\.DER|\.CRT" {$cert.Import($Certificate.FullName)}
                    "\.PFX" {
                        if (!$Password) {$Password = Read-Host "Enter password for PFX file $certificate" -AsSecureString}
                        # тут пришлось указать контекст хранилища, куда предполагается сохранить сертификат.
                        # на самом деле мы никуда не будем сохранять объект сертификата, это было сделано
                        # по причине отсутствия подходящего конструктора метода Import(), чтобы
                        # можно было указать только путь к файлу и пароль от PFX
                            $cert.Import($Certificate.FullName, $password, "UserKeySet")
                        }
                    "\.P7B|\.SST" {
                        $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection
                        $cert.Import([system.IO.File]::ReadAllBytes($file.FullName))
                        }
                    default {Write-Warning "Looks like your specified file is not a certificate file"; return}
                    }
                    # полученный объект или объекты сертификатов пропускаем через метод Build() и вызываем
                    # мини-функцию расшифровки статуса проверки
                    $cert | %{
                        $status = $chain.Build($_)
                        _getstatus_ $status $chain $_
                    }
                    # после каждой итерации очищаем объекты сертификата и цепочки
                    $cert.Reset()
                    $chain.Reset()
                }
            }
        }
    }
}

Данный скрипт может принимать аргументы в виде уже готовых объектов X509Certificate2 или с указанием пути к файлу сертификата, например:

dir cert:\currentuser\my | Test-Certificate
Test-Certificate .\mycert.cer

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

PowerShell Powered - http://www.sysadmins.lv

Certificate Chaining Engine — как это работает

Camelot — Wed, 16 Sep 2009 20:39:21 GMT

Введение

На самом деле эта тема тесно переплетается с фундаментальными основами PKI, как доверие сертификатов, защита от подделки цифровых подписей сертификатов, отзыв сертификатов и т.д. Иными словами, сама модель PKI лежит на Certificate Chaining Engine (механизм построения цепочек сертификатов). Миллионы людей в мире видят результат работы этого механизма ежедневно, но не знают, как он работает. Им это, в принципе, и не надо, а вот IT-специалистам по PKI это знать просто необходимо.

Одной из основ PKI является модель доверия центрам сертификации (Certification Authority или просто CA). Прежде чем мы начнём доверять сертификату мы должны явно доверять корневому сертификату CA и так же явно или косвенно (по правилу одностороннего транзитивного доверия) доверять всем промежуточным CA в цепочке. Корневые сертификаты устанавливаются в систему вручную путём добавляения сертификата CA в секцию Trusted Root CAs. Если корневой сертификат CA есть в этом списке, то мы доверяем всем сертификатам, которые выдал этот CA и любые подчинённые CA (Intermediate CA).

В качестве наиболее доступного и понятного примера можно рассмотреть SSL веб-сайт. Если мы зайдём на https://www.dreamspark.com, то мы увидим что с SSL сертификатом этого сайта всё в порядке. Если же мы зайдём на https://cert.startcom.org, то мы наоборот увидим грозное предупреждение, что с SSL сертификатом этого сайта что-то не так. Это как раз и есть результат работы Chaining Engine. А вот что он сделал на самом деле — вот об этом мы сейчас и поговорим.

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

Давайте сначала посмотрим на путь сертификатов (цепочки сертификатов) обоих веб-сайтов:

В первом случае цепочка сертификатов заканчивается на сертификате VeriSign, которому мы доверяем явно. Вы можете убедиться в этом нажав кнопку View Certificate, чтобы посмотреть его внутренности и найти этот же сертификат в оснастке certmgr.msc –> Trusted Root CAs. Однако, вы видите, что не корневой CA выдал сертификат сайту, а подчинённый (Intermediate CA). Это доказывает то, что если мы доверяем корню, то и явно или косвенно доверяем всем сертификатам этого CA или любым его прямым или косвенным промежуточным CA. Если говорить простым языком, то в сертификатах используется одностороннее транзитивное доверие сертификатам CA. Чуть позже будет рассказано как строится эта цепочка. Во втором случае мы видим, что корневой сертификат CA не находится у нас в Trusted Root CAs и, следовательно, мы не доверяем ни одному сертификату, который издал этот CA или любой другой его подчинённый CA. И, так же как и в первом случае, сертификат самому веб-сайту выдал подчинённый CA. На самом деле этот момент является одной из наиболее частых ошибок системных администраторов, которые организовывают доступ к ресурсам с использованием цифровых сертификатов.

Но нас теперь интересует другой вопрос — а откуда же взялись все эти сертификаты в цепочке? Chaining engine как правило использует только 3 метода построения цепочки:

по полю AIA (Authority Information Access) каждого сертификата
с использованием файла цепочки сертификатов в формате pkcs7
поиск подходящих сертификатов в локальном хранилище (с использованием exact, key, name matches, о которых будет рассказно ниже)

Примечание: в сертификате любое поле содержащее слово Authority будет означать какие-то сведения о сертификате вышестоящего CA. Например, Authority Key Identifier — комбинация серийного номера, поля Subject или хеша открытого ключа вышестоящего CA. А любое поле содержащее слово Subject — означает то же самое, но применительно к конкретно этому сертификату.

Давайте посмотрим поле AIA первого сертификата:

[1]Authority Info Access
     Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
     Alternative Name:
          URL=http://www.microsoft.com/pki/mscorp/Microsoft%20Secure%20Server%20Authority(5).crt

В этом поле содержится ссылка на сертификат того CA, который непосредственно издал и подписал этот сертификат. Если нажать по этой ссылке, то вы скачаете сертификат центра сертификации Microsoft Secure Server Authority. В этом сертификате тоже будет поле AIA, по ссылке из которого скачается сертификат вышестоящего CA — Microsoft Internet Authority. И так проверка проводится далее до тех пор, пока цепочка не оборвётся или не закончится каким-либо корневым CA (корневой CA характеризуется самоподписанным сертификатом, т.е. сертификат выдан самому себе). Если вы посмотрите сертификат Microsoft Internet Authority, то вы в нём не обнаружите поля AIA. И вот здесь мы сталкиваемся со вторым методом добычи сертификатов в цепочке – файл сертификатов формата pkcs7.

Бывают случаи, когда цепочка сертификатов не может быть построена и она обрывается на пути. Типичный пример такого обрыва (когда цепочка не может быть построена до корня с использованием любого вышеуказанного метода) можно посмотреть на сайте БиЛайна: https://trust.beeline.ru

если посмотреть поле AIA этого сертификата, то мы увидим там 2 пути до CA, который издал этот сертификат. Но оба эти пути нерабочие совсем (кстати говоря, пути в CDP там тоже нерабочие. Причём, во всех сертификатах! Вот такой он БиЛайн ). Но цепочка сертификатов в этом случае всё равно построилась за счёт сертификатов в pkcs7 формате. Хотя корневой сертификат в этом pkcs7 просто отсутствует, поэтому мы даже не можем собрать корневой сертификат. Неработающие CDP/AIA — ещё одна из наиболее частых ошибок реализации инфраструктуры PKI, в результате которой по сути PKI является неработоспособной.

Оффтоп: если на этой странице нажать Продолжить, то на новой странице будет ссылка на корневой сертификат, а так же на CRL. CRL БиЛайна доставил очень сильно. Вы посмотрите срок годности этого CRL

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

Однако, это только половина дела. Мы просто построили цепочку сертификатов, но не более того. Поскольку сертификаты могут быть скачаны в pkcs7 формате, а по ссылкам AIA просто подменить сертификаты, chaining engine делает полнуюю проверку доверия каждого сертификата в цепочке, чтобы исключить возможность подмены сертификатов, а так же достраивает цепочку (если этого не удалось сделать с помощью AIA и pkcs7 используя локальное хранилище сертификатов). Соответствие сертификатов внутри цепочки может происходить по нескольким правилам (в порядке приоритета):

Exact Match
Key Match
Name MAtch

Для этого chaining engine использует следующие поля сертификатов:

Authority Key Identfier (AKI) — может содержать комбинацию поля Subject и Serial Number сертификата вышестоящего CA или хеш открытого ключа вышестоящего CA (но бывает, что это поле совсем отсутствует).
Issuer – данное поле используется только если AKI отсутствует в сертификате и это поле должно быть эквивалентно полю Subject вышестоящего CA. По этому полю определяется имя CA, котороый издал этот сертификат.
Subject в сертификате вышестоящего CA. Данное поле должно быть эквивалентно полю Issuer в издаваемых сертификатах.
Serial Number сертификата вышестоящего CA.
Subject Key Identifier (SKI) — может содержать комбинацию поля Subject и Serial Number текущего сертификата или хеш открытого ключа текущего сертификата.

Exact match

Данный метод определения правильности построения цепочки является наиболее точным и такая цепочка почти никогда не будет заканчиваться более чем одним корневым сертификатом, поскольку требует совпадения 2-х полей вышестоящего сертификата – Subject и серийного номера с полем AKI проверяемого сертификата. Давайте посмотрим пример такой проверки в сертификате сайта https://cert.startcom.org. Поле AKI содержит следующую информацию:

KeyID=a1 e1 9e 45 25 79 4d 06 d9 02 17 92 82 d5 30 89 72 25 14 a0
Certificate Issuer:
     Directory Address:
          CN=StartCom Certification Authority
          OU=Secure Digital Certificate Signing
          O=StartCom Ltd.
          C=IL
Certificate SerialNumber=17

Поле KeyID не используется. Здесь мы видим сведения о поле Subject и серийный номер вышестоящего CA. Если посмотреть сертификат этого CA, то его серийный номер и поле Subject будут идентичными тем, которые записаны в поле AKI издаваемых ими сертификатов. Используя эти данные chaining engine может найти нужный сертификат в локальном хранилище (если такой сертификат там есть), для восполнения недостающих звеньев цепочки. Если же будет обнаружено хоть одно несоответствие между этими полями, то цепочка мгновенно обрывается и любому сертификату в этой цепочке (начиная от сертификата с несоответствующими полями и вниз до конечного сертификата выданного потребителю) будет отказано в доверии.

Key Match

Это наиболее распространённый тип проверки цепочки, т.к. зачастую поле AKI у сертификатов содержит только KeyID, который является лишь хешом открытого ключа вышестоящего CA. Например сертификат с https://www.dreamspark.com:

KeyID=14 55 c4 39 e0 3d 2e d1 55 2e 48 96 b0 d8 7e 14 22 06 93 bc

Этот хеш должен быть идентичным хешу, который записан в поле Subject Key Identifier вышестоящего CA. В этом вы можете убедиться просмотрев сертификат CA, который выдал сертификат для dreamspark.com. В случае несоответствия этого поля, любому сертификату вниз по цепочке будет отказано.

Заметка: при этом, возможна достаточно интересная ситуация, когда цепочка может заканчиваться несколькими корнями. Это может происходить если корневой сертификат CA был обновлён с использованием текущей пары открытого и закрытого ключа. Поскольку KeyID — всего лишь хеш открытого ключа, то при смене корневого сертификата CA, хеш не изменится и, следовательно, chaining engine может рандомно строить цепочку до старого или до нового корневого сертификата CA.

Name match

Но поле AKI не обязательно должно присутствовать в сертификате. Его может не быть совсем и тогда остаётся только один способ проверки целостности цепочки — сравнение поля Issuer текущего сертификата и поля Subject вышестоящего сертификата. Это самый крайний и наименее надёжный (хотя это достаточно относительно) метод проверки цепочки. Так же, как и предыдущий пример, данный метод может заканчиваться несколькими корневыми сертификатами, если сертификат CA был обновлён с использованием текущей пары открытого и закрытого ключей. Но этого не произойдёт, если при обновлении сертификата CA будут использоваться новая пара ключей. Хоть хеши и серийные номера издающих CA не проверяются, то подделка сертификатов в вашем случае закончится провалом. А об этом читайте заключительный раздел.

Не забываем про подписи

На самом деле может показаться, что обмануть chaining engine достаточно легко — надо лишь подсунуть нужные поддельные сертификаты. Но в действительности это не так. Помимо всего прочего следует помнить, что каждый сертификат подписан цифровой подписью издающего CA. Если вы ещё не знаете, что такое цифровая подпись, то пора бы и узнать. Когда CA составляет сертификат, то он высчитывает конечный хеш (с использованием алгоритма указанного в поле Signature algorithm) этого сертификата и шифрует его своим закрытым ключом и пристыковывает подпись к сертификату. При проверке сертификата chaining engine удаляет цифровую подпись из сертификата и подсчитывает сам хеш файла сертификата. Далее берёт открытый ключ у издающего CA и сравнивает полученный хеш с тем, что содержится в подписи. Следовательно, если вам удастся обмануть все 3 метода проверки цепочки путём подмены сертификатов, то вы сломаетесь на проверке цифровой подписи, т.к. здесь уже задействуется закрытый ключ легального CA. Вот как это может выглядеть:

На картинке слева вы видите, что chaining engine построил цепочку до доверенного корня, поскольку мой сертификат содержал нужные поля для работы метода Name match. Но сертификат был выдан не тем CA, который виден в цепочке, а поддельным CA. Хоть мой поддельный CA внешне не отличим от легитимного CA, но у него нету самого важного — правильного закрытого ключа, чтобы подписать сертификат. Ведь при проверке подписи используется открытый ключ легитимного CA и, следовательно, подпись не может быть проверена.

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

PowerShell Powered - http://www.sysadmins.lv