Примечание: данный материал публикуется как обязательный для знания IT-специалистами, которые занимаются или только собираются заниматься темой PKI (Public Key Infrastructure).
Большинство системных администраторов считают, что планирование списков отзыва сертификатов (Certificate Revocation List — CRL) и файлов сертификатов самих серверов CA — это элементарная вещь. Но практика показывает, что очень многие из них сильно заблуждаются. Поэтому предлагаю немного повременить с CryptoAPI и поговорить о немного более насущных вещах — рекомендации по планированию публикации списков CRL и сертификатов CA (Certification Authority), которые используются certificate chaining engine для построения и проверок цепочек сертификатов. О том, как работает этот движок можете почитать пост: Certificate Chaining Engine — как это работает.
Как известно, каждый выданный в CA сертификат (кроме самоподписанных сертификатов. Корневой сертификат так же является самоподписанным сертификатом) содержит 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 в выдаваемых сертификатах при таких настройках:
[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
[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 свалится в бесконечный цикл проверки сертификатов.
По умолчанию в Windows Server основные CRL (Base CRL) публикуются раз в неделю и инкрементные CRL (Delta CRL) публикуются раз в сутки. Файлы сертификатов CA обычно обновляются через промежутки равные времени жизни сертификата самого CA (или чаще, если сертификат CA обновляется внепланово). Если сертификаты CA нужно обновлять достаточно редко (раз в несколько лет) и к этому следует готовиться отдельно, то обновление CRL происходит автоматически без вмешательства администратора и здесь требуются особые корректировки о которых мы сейчас и поговорим.
Если посмотреть на CRL, то мы увидим следующее:
Сейчас нас будут интересовать только 3 поля:
Примечение: время в этих полях указывается в формате 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 ключа:
Если вы используете 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 содержат ссылки на 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 следует всем бест-практисам. А вам советую им следовать, тогда меньше вероятность, что вы потом будете гореть в аду.
Изменение путей в уже существующих инфраструктурах вопрос достаточно серьёзный, хоть и прост в реализации. Если вы решились на такой шаг, то следует руководствоваться следующими правилами:
С выходом 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.
Немного вранья - AIA в 2003 не включался в корневой сертификат, там был только CDP ;) .
Сейчас посмотрел на тестовом CA, да, там AIA нет. Тогда вопрос: зачем для 2003 в CAPolicy.inf рекомендуют вписывать пустое значение для AIA? [AuthorityInformationAccess] Empty = true если хватает только сделать empty = true для CDP?
А вот это вопрос к тем, кто такое описание писал;). Возможно, в 2000 это требовалось, а потом просто не стали описание изменять.
Во всяком случае об этом пишут как официальные технеты и весьма компетентные люди, как Brian Komar. Вобщем, факт отсутствия AIA в корневых сертификатах не отменяет смысла написанного.
Спасибо за статью, восполнила оставшиеся пробелы в знаниях. Возник такой вопрос... CA умеет публиковать CRL в удаленную шару. А может ли он публиковать еще и сам корневой сертификат для его включения в AIA (на сомом CA он лежит в папке CertEnroll рядом с CRL файлами)?
> CA умеет публиковать CRL в удаленную шару да, может. Подробности вот тут: http://www.sysadmins.lv/PermaLink,guid,7863aaeb-ca0f-4b51-8406-b9821179edd9.aspx
Для автовыкладки CRL на удаленный вебсервер в настройках CDP указал file://server/share/Company_RCA(CRLNameSuffix)(DeltaCRLAllowed).crl оно работает, CRL полные и разностные кладутся Для выкладки самого корневого сертификата для AIA сразу за C:\WINDOWS\system32\CertSrv\CertEnroll\(ServerDNSName)_(CAName)(CertificateName).crt (публикация в локальную папку на самом сервере CA) добавил строчку file://server/share/(ServerDNSName)_(CAName)(CertificateName).crt и вот туда уже CRT не выкладывается... Куда копать? Мне конечно не труно скопировать руками корневой CRT, он не так уж часто обновляется. Но хотелось бы сделать по Best Practices.
Угловые скобки намеренно заменены на круглые, ибо ваша форма коммента регается на непонятные ошибки, если их встречает в тексте.
если бы вы внимательно прочитали пост по ссылке, то узнали бы, что начиная с 2003 сервера CRT нельзя класть в нестандартную локацию. Т.е. можно, но вручную только. Учитывая достаточно длительный срок действия сертификатов CA, это можно сделать один раз и забыть до обновления сертикатов. з.ы. что до скобок, я знаю. Этой форме много чего не нравится, а почему — не знаю.
Во первых, огромное спасибо за цикл статей! После их прочтения, возникло одно подозрение на потенциальные проблемы тупому следования Вашим рекомендациям, что явно противоречит цели Ваших статей. Отказ от LDAP ссылок, и в меньшей степени уменьшение их приоритета, несет в себе еще один подводный камень, который тут не упомянут. Если в сети LDAP серверов чаще всего двое, и это обычная и рекомендуемая практика, да еще и разворачивающаяся в полпинка, то вот http обычно один, или просто территориально удален, и его временный выход из строя, или банальная недоступность из за аварии коммуникаций, может понести за собой некоторые непредвиденные проблемы. Возможно, имеет смысл, хотя бы упомянуть о такой опасности. Как по мне, так лучше решать проблемы с репликацией AD, чем значительно сложнее решаемые с недоступностью http сервера. В связи с этим, не могли бы Вы расширить Ваши рекомендации и особенно скрипты добавлением опциональных вариантов конфигурации с использованием LDAP? С Вашим пониманием предметной области это будет и не сложно и крайне полезно Вашим читателям не допустить тупых ошибок на моменте проектирования. Заранее большое спасибо!
Спасибо, весьма занимательно. По поводу LDAP вопрос не такой однозначный. С одной стороны, для внутренних клиентов, при условии не совсем уж сильно распределённого леса AD, задержками, как правило, можно пренебречь - ибо доступность обычно важнее. А доступность, как правильно подметил коллега Mikhail, при использовании LDAP обеспечить и проще и дешевле. С другой стороны, нет ничего хорошего, если для внешних клиентов в CRL фигурирует часть контекста именования моего леса. И хрен та с ним, с десятью секундами задержки - проблемы негров шерифа не столь сильно занимают. Отсюда с неизбежностью возникает хотелка: Для внешних сервисов публиковать CRL только по URL, а вот для внутренних - по LDAP и URL. Полагаю, не сильно ошибаюсь, если скажу, что подавляющее число компаний имеют достаточно статический набор внешних ресурсов. Причем, настолько статический, что за весь жизненный цикл инфраструктуры PKI число запросов на операции по выдачи/обновлению сертификатов для них можно пересчитать по пальцам. Может быть с ногами. Внутренние меняются куда как чаще. И вот теперь я могу сформулировать вопрос: насколько жизненным является такой процесс обслуживания CA: - В нормальном режиме у меня выдаётся в качестве CDP LDAP и URL - Если мне необходимо выдать сертификат для внешнего сервиса, я перенастраиваю CA на публикацию только URL, выдаю сертификат и возвращаю взад LDAP/URL Потому как держать отдельный CA для выдачи сертификатов внешним сервисам раз в пятилетку весьма накладно. Или, возможно, есть какой-то ещё, неведомый мне, более прямой способ решения поставленной задачи? Заранее спасибо.
самый прямой способ — иметь 2 CA: один для внутренних клиентов только и второй для внешних.
Безусловно, идеологически да, самый праямой. Однако, повторюсь, накладный способ. Поэтому интересует то, что я написал жизнеспособно, или оно в принципе работать не будет?
Не думаю, что это будет работать в реальной жизни. Потому что во время переключения CA на другие ссылки, доменные клиенты могут зайти в гости за сертификатом и они получат сертификат без LDAP.
Ну мне ничто не мешает на время выдачи таких сертификатов перевести CA в режим ручной выдачи сертификатов. Сформулирую вопрос иначе и более обще: какие настройки CA нельзя менять во время его жизненного цикла? Про имя я в курсе.
Ответ простой — любые настройки не следует менять. Всё остальное — на свой страх и риск.
Comments: