Настройка CDP / AIA расширений в Certification Authority
Свойства публикации CRL и их соответствие опциям в оснастке certsrv.msc
| Hex | Dec | Имя | Название на странице Extensions |
| 1 | 1 | CSURL_SERVERPUBLISH | Publish CRL s to this location |
| 2 | 2 | CSURL_ADDTOCERTCDP | Include in the CDP extension of issued certificates |
| 4 | 4 | CSURL_ADDTOFRESHESTCRL | Include in CRL s. Clients use this to find Delta CRL locations. |
| 8 | 8 | CSURL_ADDTOCRLCDP | Include in all CRL s. Specifies where to publish in the Active Directory when publishing manually. |
| 10 | 16 | CSURL_PUBLISHRETRY | |
| 20 | 32 | CSURL_ADDTOCERTOCSP | |
| 40 | 64 | CSURL_SERVERPUBLISHDELTA | Publish Delta CRL s to this location |
| 80 | 128 | CSURL_ADDTOIDP | Include in the IDP extension of issued CRL s |
| Hex | Dec | Имя | Название на странице Extensions |
| 1 | 1 | CSURL_SERVERPUBLISH | |
| 2 | 2 | CSURL_ADDTOCERTCDP | Include in the AIA extension of issued certificates |
| 4 | 4 | CSURL_ADDTOFRESHESTCRL | |
| 8 | 8 | CSURL_ADDTOCRLCDP | |
| 10 | 16 | CSURL_PUBLISHRETRY | |
| 20 | 32 | CSURL_ADDTOCERTOCSP | Include in the online certificate status protocol (OCSP ) extension |
| 40 | 64 | CSURL_SERVERPUBLISHDELTA | |
| 80 | 128 | CSURL_ADDTOIDP |
Переменные используемые в ссылках CRL Distribution Point (CDP ) / Authority Information Access (AIA ) расширений
| В certutil | Token name в редакторе расширений CDP / AIA | Возможность использования |
| %1 | <ServerDNSName> | CDP / AIA |
| %2 | <ServerShortName> | CDP / AIA |
| %3 | <CaName> | CDP / AIA |
| %4 | <CertificateName> | CDP / AIA |
| %6 | <ConfigurationContainer> | CDP / AIA |
| %7 | <CATruncatedName> | CDP / AIA |
| %8 | <CRLNameSuffix> | CDP |
| %9 | <DeltaCRLAllowed> | CDP |
| %10 | <CDPObjectClass> | CDP |
| %11 | <CAObjectClass> | CDP / AIA |
Примечание: обратите внимание, что если certutil.exe будет вызываться из командного файла, то символ процента необходимо экранировать еще одним символом %. Например, вместо %1 в bat/cmd файле необходимо будет написать %%1.
Значения по умолчанию для расширений CRL Distribution Point (CDP ) / Authority Information Access (AIA )
Внесение изменений при помощи certutil
Пример внесения изменений в CDP из командного файла:
certutil -setreg CA\CRLPublicationURLs «65:C:\Windows\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n79:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n6:http://%%1/CertEnroll/%%3%%8%%9.crl\n0:file://%%1/CertEnroll/%%3%%8%%9.crl»
Пример разбора конфигурационной строки
Разберем конфигурационную строчку для CDP расширения:
«65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n79:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10\n6:http://%1/CertEnroll/%3%8%9.crl\n0:file://%1/CertEnroll/%3%8%9.crl»
Она состоит из 4х строк разделенных символами \n:
| Свойства | Ссылка | |
| 0 | 65 | C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl |
| 1 | 79 | ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10 |
| 2 | 6 | http://%1/CertEnroll/%3%8%9.crl |
| 3 | 0 | file://%1/CertEnroll/%3%8%9.crl |
Свойства это сумма значений выбранных свойств в таблицах 1 и 2. Макроподстановки в ссылках выполняются по правилам из таблицы 3.
/AlexxHost/
Вы попали на блог, целиком и полностью посвященный продуктам компании Microsoft. В основном речь будет идти про системы корпоративных коммуникаций на базе Exchange Server.
среда, 25 мая 2011 г.
Проект внедрения PKI – конфигурирование серверов
В про шлой части — Проект внедрения PKI – базовая инфраструктура, мы разобрались с вспомогательными составляющими нашей инфраструктуры PKI. Далее давайте посмотрим непосредственно на конфигурирование серверов.
Начнем с корневого СА:
Конфигурирование Root CA
Серверу необходимо присвоить следующее DNS-Имя:
vm-ca-root.alexxhost.ru
Данные для установки корневого сервера CA:
- Role Services – Certification Authority ;
- Setup Type — Enterprise;
- CA Type— Root CA;
- Private key – Create a new private key ;
- Cryptography:
- Криптопровайдер — RSA#Microsoft Software Key Storage Provider;
- Длина ключа — 2048 бит;
- Алгоритм подписи — SHA1;
- Common Name —Root-CA;
- Distinguished name suffix – O=AlexxHost,C=RU;
- Срок действия Base CRL —90 дней;
- Отключаем публикацию Delta CRL;
- Продлеваем срок жизни CRL для клиентов на 2 недели:
- Срок действия издаваемых сертификатов — 10 лет;
- Включаем полный аудит для сервера CA
- Расширения CDP (CRL Distribution Point) и AIA (Authority Information Access) будут настроены в соответствии с пунктом Конфигурирование расширенийCDP/AIA.
- Запрет выдачи сертификатам всем кроме издающих СА:
- Check box – Publish CRLs to this location
- Check box – Publish Delta CRLs to this location
- Check box – Publish CRLs to this location
- Check box – Include in the CDP extensions of issued certificates
- Check box – Include in CRLS. Clients use this to find Delta CRL Locations
- Check box – Include in the AIA extension of issued certificates
- Role Services – Certification Authority ;
- Setup Type — Enterprise;
- CA Type— Subordinate CA;
- Private key – Create a new private key ;
- Cryptography:
- Криптопровайдер — RSA#Microsoft Software Key Storage Provider;
- Длина ключа — 2048 бит;
- Алгоритм подписи — SHA1;
- Common Name —Issuing-CA-1;
- Distinguished name suffix – O=AlexxHost,C=RU;
- Root-CA
- Срок действия Base CRL —5 дней;
- Срок действия Delta CRL – 12 часов;
- Продлеваем срок жизни CRL для клиентов на 1 день:
- Срок действия издаваемых сертификатов — 5 лет (по умолчанию 2);
- Включаем полный аудит для сервера CA
- Расширения CDP (CRL Distribution Point) и AIA (Authority Information Access) будут настроены в соответствии с пунктом Конфигурирование расширенийCDP/AIA.
- Check box – Publish CRLs to this location
- Check box – Publish Delta CRLs to this location
- Check box – Publish CRLs to this location
- Check box – Publish Delta CRLs to this location (неставитьдляROOT-CA)
- Check box – Include in the CDP extensions of issued certificates
- Check box – Include in CRLS. Clients use this to find Delta CRL Locations
- Check box – Include in the AIA extension of issued certificates
- В расширении «CRL Distribution Points (CDP)» хранятся ссылки на CRL издавшего конкретный сертификат CA;
- В расширении «Authority Information Access (AIA)» хранятся ссылки на сертификат CA, издавшего конкретный сертификат. А для сертификатов, выданных CA под управлением Windows Server 2008 и выше — могут содержаться ссылки на OCSP Responder (см. OCSP (часть 1) и OCSP (часть 2))
- CDP
- AIA
- Effective Date — указывает дату и время с которого данный CRL считается действительным и оно по умолчанию на 10 минут меньше, чем фактическое время, чтобы покрыть издержки рассинхронизации времени между сервером и клиентом;
- Next Update — указывает дату и время, когда заканчивается срок действия конкретного CRL и он считается недействительным;
- Next CRL Publish — указывает дату и время публикации следующего списка CRL.
- CRLOverlapUnits — указывает время до истечения срока действия текущего основного CRL, за которое будет публиковаться новый основной CRL.
- CRLOverlapPeriod — указывает единицу измерения этого времени для основного CRL
- CRLDeltaOverlapUnits — указывает время до истечения срока действия текущего инкрементального (если используется) CRL, за которое будет публиковаться новый инкрементальный CRL
- CRLDeltaPeriodPeriod — указывает единицу измерения этого времени для инкрементального CRL.
- пути публикации физических файлов можно располагать в произвольном порядке;
- новые ссылки к файлам, по которым клиенты будут их скачивать должны располагаться первыми, т.е. с более высоким приоритетом (кроме случаев, когда вы добавляете ссылки только для обеспечения более высокой доступности файлов. Тогда новые ссылки можно просто добавить в хвост уже существующим);
- если вы собираетесь уйти от существующих ссылок на 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
- Проверяем устройства в сети, которые можно подключить к настроенному кластеру:
- Из предыдущего вывода берём MAC-адрес и добавляем удалённый коммутатор SW10 в CDP cluster.
- Всё. Теперь можем подключиться к удалённому коммутатору командой SW1#rcommand 1 . И попадаем на удалённый коммутатор SW10# . Теперь можно делать любые настройки, что могут потребоваться.
- Role Services – Certification Authority ;
- Setup Type — Enterprise;
- CA Type— Root CA;
- Private key – Create a new private key ;
- Cryptography:
- Криптопровайдер — RSA#Microsoft Software Key Storage Provider;
- Длина ключа — 2048 бит;
- Алгоритм подписи — SHA1;
- Common Name —Root-CA;
- Distinguished name suffix – O=AlexxHost,C=RU;
- Срок действия Base CRL —90 дней;
- Отключаем публикацию Delta CRL;
- Продлеваем срок жизни CRL для клиентов на 2 недели:
- Срок действия издаваемых сертификатов — 10 лет;
- Включаем полный аудит для сервера CA
- Расширения CDP (CRL Distribution Point) и AIA (Authority Information Access) будут настроены в соответствии с пунктом Конфигурирование расширенийCDP/AIA.
- Запрет выдачи сертификатам всем кроме издающих СА:
- Check box – Publish CRLs to this location
- Check box – Publish Delta CRLs to this location
- Check box – Publish CRLs to this location
- Check box – Include in the CDP extensions of issued certificates
- Check box – Include in CRLS. Clients use this to find Delta CRL Locations
- Check box – Include in the AIA extension of issued certificates
- Role Services – Certification Authority ;
- Setup Type — Enterprise;
- CA Type— Subordinate CA;
- Private key – Create a new private key ;
- Cryptography:
- Криптопровайдер — RSA#Microsoft Software Key Storage Provider;
- Длина ключа — 2048 бит;
- Алгоритм подписи — SHA1;
- Common Name —Issuing-CA-1;
- Distinguished name suffix – O=AlexxHost,C=RU;
- Root-CA
- Срок действия Base CRL —5 дней;
- Срок действия Delta CRL – 12 часов;
- Продлеваем срок жизни CRL для клиентов на 1 день:
- Срок действия издаваемых сертификатов — 5 лет (по умолчанию 2);
- Включаем полный аудит для сервера CA
- Расширения CDP (CRL Distribution Point) и AIA (Authority Information Access) будут настроены в соответствии с пунктом Конфигурирование расширенийCDP/AIA.
- Check box – Publish CRLs to this location
- Check box – Publish Delta CRLs to this location
- Check box – Publish CRLs to this location
- Check box – Publish Delta CRLs to this location (неставитьдляROOT-CA)
- Check box – Include in the CDP extensions of issued certificates
- Check box – Include in CRLS. Clients use this to find Delta CRL Locations
- Check box – Include in the AIA extension of issued certificates
Post-install configuration
После установки роли СА на сервер необходимо сделать дополнительные настройки:
certutil -setreg CA\CRLPeriodUnits 5
certutil -setreg CA\CRLPeriod "Days"certutil -setreg CA\CRLDeltaPeriodUnits 12
certutil -setreg CA\CRLDeltaPeriod "Hours"certutil -setreg CA\CRLOverlapPeriod "Days"
certutil -setreg CA\CRLOverlapUnits 1certutil -setreg CA\ValidityPeriodUnits 5
certutil -setreg CA\ValidityPeriod "Years"Примечание: Данные параметр может быть изменены и через реестр в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\
certutil -setreg CA\AuditFilter 127
Конфигурирование расширений CDP/AIA:
Настройки CDP/AIA производятся в свойствах СА (правой кнопкой мыши на имени СА – Properties) на вкладке Extensions.
Настройки CDP:
Удаляем все LDAP-ссылки;
Настройки AIA:
Удаляем все LDAP-ссылки;
Галочки должны быть убраны. (Остаётся без изменений)
Публиковать CRT в нестандартные локации невозможно, поэтому их необходимо переименовать и переместить из папки C:\WINDOWS\system32\CertSrv\CertEnroll вручную в папку \\S-Web-01\pki
Заключение
На этом все, чем я хотел поделиться с вами в рамках данного проекта. Напоследок ещё раз хочу предупредить, что не стоит воспринимать данную статью как информацию в последней инстанции!
Для более детального изучения темы PKI предлагаю ознакомиться со следующими материалами:
-
, здесь вы найдете ответы на очень многие вопросы; от Руслана Карманова – для тех кто хочет знать всё, или почти всё.
19 комментариев:
Добрый день!
Спасибо за подробный и интересный доклад.
А как быть если корневой и издающий настроены.
Сертификат корневого добавлен в trust.
Но потом возникла необходимость поменять настройки CDP и AIA на корневом и издающем. И по старым путям доверие не прследить будет, а сертификаты уже выданы. CA используется только во внутреннем домене.Спасибо.Вам нужно сохранить доступ к старым местам, куда сейчас указывают CDP и AIA, после чего добавить на СА новые точки распространения, при этом оставит публикацию и в старые в том числе, но в новые сертификаты включать только новые точки распространения.
Спасибо,большое!
Еще вопрос,может подскажите,где копать. Ситуация такая: CA — Windows 2003 Standart Edition. Один,без корневого. PKI только во внутреннем домене. Иногда пользователи через VPN заходят на терминалки, потом на свои машины доменные. Скертификаты у них не просроченные, но CA выпускает им еще сертификат, у них становится несколько и они не могут читать свою старую шифрованную почту. Пиходится искать из закоытый ключ, там где они логигинились последний раз. Можно этого избежать? Или как быстро админу восстановить закрытый ключ? Спасибо, большое.Добрый день!
Спасибо за статью. Сделал все по ней,работает.
При установке Root CA установил срок жизни сертификата 5 лет. Потом поменял в реестре параметр на 10, выпустил еще один, 1-й стал 10 лет, появился 2-й,тоже -10 лет. Поменял в реестре на 20 лет. Выпустил 3-й, но он все равно-10лет.Поменял на 15 лет, выпустил 4-й, все равно -10.
Можно сделать, чтобы было 20 лет? Спасибо.Странная ситуация. Должно без проблем меняться. На сколько я знаю, ограничения по возрасту сертификата нет.
Вы сервис перезапускали? NET stop certsvc
NET start certsvcДобрый день!
Да, при выпуске сертификата нового, CA предупреждал,что служба будет перезапущена.
Ситуация такая: при установке RootCA был выбран срок сертификата 5 лет. Он потом выдал сертификат на 5 лет выдающему. Выдающий выдал несколько сертификатов серверам на 1 год. Потом стала задача увеличить срок корневому и выдающему. Но чтобы выданные сертификаты жили. На корневом поменяли в реестре на 10 лет,выдали. Появился под номером 1, сроком с 2012 до 2022. Потом решили сделать на обоих 20 лет. Поменяли в реестре ,выпустили на корневом, появился под номером 2 ,но все равно до 2022. Выпустили еще несколько,результат один до 2022. На CA dв выданныхсертификатах стоит Cross. Можно не переустанавливая УЦ все таки сделать на 20 лет? Спасибо.Здравствуйте!
А можно сделать,чтобы при запросе на пользовательский сертификат через веб-интерфейс CA
Выдавался сертификат из расширенного шаблона версии 2. Где стоит больший срок и другие полезные вещи.
Сейчас, что бы не делалось, при запросе сертификата пользователя (не через расширенную форму) всегда берется шаблон по умолчанию версии 1. Где срок 1 год и ничего поменять нельзя. Спасибо.При запросе через веб-форму, вам предоставляется возможность выбрать шаблон, по которому генерировать сертификат. У вас в этом выпадающем списке есть нужный шаблон?
Здравствуйте!
Эту проблему я рещил, в файле certrqst.inc исправил имя шаблона. Теперь другая проблема. У пользователя AD , у которого нет ящика почтового, при запросе на сертификат пишет:
политика выдачи сертификата отвергла запрос адрес электронной почты нельзя вставит в имя субъекта. Где поправить надо? Спасибо.Тут два варианта:
1. Указываем e-mail адрес в свойствах учетки в АД (на первой вкладке)
2. Правим шаблон сертификата — указываем на базе чего генерировать основное имя.Спасибо,все получилось.
И последнее. Когда на веб-интерфейсе на компьютере откуда запрашивал сертификат заходишь в просмотр состояния запроса на сертификат, то их иногда там несколько штук. А на УЦ в запросах нет таких. Так и должно быть? Когда нажимаешь на какой-нибудь, пишет,что был отвергнут или уже выдан по нему, и после этого пропадает.Так быть не должно. Сложно сказать почему у вас так происходит.
Добрый день!
Помогите, пожалуйста.
Я настроил на CA 2008 enterprise Issue-Архивацию и восстановление ключей.При ручной подаче запроса на Сертификат пользователя, который использует расширенный шаблон , с включенной опцией- Архивировать закрытый ключ
CA выдает ошибку: В запросе отсутствует требуемый закрытый ключ для архивирования сервером 0Х80094804 (-2146875388)
Если же выбрать расширенную форму запроса и выбрать тот же шаблон из списка, не меняя ничего в нем, то сертификат выдается и ключ архивируется.
В чем может быть проблема? Чтобы при запросе сертификата пользователя использовался нужный мне шаблон, я менял в файле C:\Windows\System32\CertSrv\certqpt.inc
со стандартного User на свой User 2003. Больше ничего не делал.
Спасибо.Здравствуйте!
Подскажите,а как поменять порядок шаблонов, в расширенной форме запроса?
Спасибо.Никогда не задумывался на тему того, по какому принципу они сортируются. Не подскажу ответа на этот вопрос. А если не секрет, то зачем вам изменять порядок сортировки шаблонов?
Добрый день!
Не подскажите, как называется оснастка для удаленного управления CA 2008 и оснастка с графическим интерфейсом для восстановления закрытых ключей и где их скачать?
Спасибо.Подскажите. Для издающего центра (который Issusing) не могу найти пути C:\Windows\System32\CertSrv\, папки CertSrv просто не существует, а оттуда мне нужно забрать crt файлик. Что необходимо сделать что бы там появился сертификат?
Возможно в настройках СА в CRL Distribution Point у вас указано другое место хранения сертификатов? (file://. )
если кто-то прочитает этот комментарий.. автор пытается настроить Enterprise сервер в качестве корневого, ОК наверное в его проекте это может иметь место. рекомендуемый же сценарий во всех инфраструктурах где есть есть корневой-подчиненный серверы — это использование в качестве корневого севера Standalone.
Post-install configuration
После установки роли СА на сервер необходимо сделать дополнительные настройки:
certutil -setreg CA\CRLPeriodUnits 90
certutil -setreg CA\CRLPeriod "Days"certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Days"certutil -setreg CA\CRLOverlapPeriod "Weeks"
certutil -setreg CA\CRLOverlapUnits 2certutil -setreg CA\ValidityPeriodUnits 10
certutil -setreg CA\ValidityPeriod "Years"Примечание: Данные параметр может быть изменены и через реестр в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\
certutil -setreg CA\AuditFilter 127
Удаляем все шаблоны из списка доступных для выдачи, кроме Subordinate Certification Authority.
Конфигурирование расширений CDP/AIA:
Настройки CDP/AIA производятся в свойствах СА (правой кнопкой мыши на имени СА – Properties) на вкладке Extensions.
Настройки CRL Distribution Point:
Удаляем все LDAP-ссылки;
Настройки AIA:
Удаляем все LDAP-ссылки;
Галочки должны быть убраны. (Остаётся без изменений)
Публиковать CRT в нестандартные локации невозможно, поэтому их необходимо переименовать и переместить из папки C:\WINDOWS\system32\CertSrv\CertEnroll вручную в папку \\S-Web-01\pki
На этом закончим конфигурирование Root CA и перейдем к настройке выдающих СА:
Issuing CA
Серверу необходимо присвоить следующее DNS-Имя:
Issuing-CA-1.alexxhost.ru
Данные для установки корневого сервера CA:
Post-install configuration
После установки роли СА на сервер необходимо сделать дополнительные настройки:
certutil -setreg CA\CRLPeriodUnits 5
certutil -setreg CA\CRLPeriod "Days"certutil -setreg CA\CRLDeltaPeriodUnits 12
certutil -setreg CA\CRLDeltaPeriod "Hours"certutil -setreg CA\CRLOverlapPeriod "Days"
certutil -setreg CA\CRLOverlapUnits 1certutil -setreg CA\ValidityPeriodUnits 5
certutil -setreg CA\ValidityPeriod "Years"Примечание: Данные параметр может быть изменены и через реестр в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\
certutil -setreg CA\AuditFilter 127
Конфигурирование расширений CDP/AIA:
Настройки CDP/AIA производятся в свойствах СА (правой кнопкой мыши на имени СА – Properties) на вкладке Extensions.
Настройки CDP:
Удаляем все LDAP-ссылки;
Настройки AIA:
Удаляем все LDAP-ссылки;
Галочки должны быть убраны. (Остаётся без изменений)
Публиковать CRT в нестандартные локации невозможно, поэтому их необходимо переименовать и переместить из папки C:\WINDOWS\system32\CertSrv\CertEnroll вручную в папку \\S-Web-01\pki
Заключение
На этом все, чем я хотел поделиться с вами в рамках данного проекта. Напоследок ещё раз хочу предупредить, что не стоит воспринимать данную статью как информацию в последней инстанции!
Для более детального изучения темы PKI предлагаю ознакомиться со следующими материалами:
-
, здесь вы найдете ответы на очень многие вопросы; от Руслана Карманова – для тех кто хочет знать всё, или почти всё.
19 комментариев:
Добрый день!
Спасибо за подробный и интересный доклад.
А как быть если корневой и издающий настроены.
Сертификат корневого добавлен в trust.
Но потом возникла необходимость поменять настройки CDP и AIA на корневом и издающем. И по старым путям доверие не прследить будет, а сертификаты уже выданы. CA используется только во внутреннем домене.Спасибо.Вам нужно сохранить доступ к старым местам, куда сейчас указывают CDP и AIA, после чего добавить на СА новые точки распространения, при этом оставит публикацию и в старые в том числе, но в новые сертификаты включать только новые точки распространения.
Спасибо,большое!
Еще вопрос,может подскажите,где копать. Ситуация такая: CA — Windows 2003 Standart Edition. Один,без корневого. PKI только во внутреннем домене. Иногда пользователи через VPN заходят на терминалки, потом на свои машины доменные. Скертификаты у них не просроченные, но CA выпускает им еще сертификат, у них становится несколько и они не могут читать свою старую шифрованную почту. Пиходится искать из закоытый ключ, там где они логигинились последний раз. Можно этого избежать? Или как быстро админу восстановить закрытый ключ? Спасибо, большое.Добрый день!
Спасибо за статью. Сделал все по ней,работает.
При установке Root CA установил срок жизни сертификата 5 лет. Потом поменял в реестре параметр на 10, выпустил еще один, 1-й стал 10 лет, появился 2-й,тоже -10 лет. Поменял в реестре на 20 лет. Выпустил 3-й, но он все равно-10лет.Поменял на 15 лет, выпустил 4-й, все равно -10.
Можно сделать, чтобы было 20 лет? Спасибо.Странная ситуация. Должно без проблем меняться. На сколько я знаю, ограничения по возрасту сертификата нет.
Вы сервис перезапускали? NET stop certsvc
NET start certsvcДобрый день!
Да, при выпуске сертификата нового, CA предупреждал,что служба будет перезапущена.
Ситуация такая: при установке RootCA был выбран срок сертификата 5 лет. Он потом выдал сертификат на 5 лет выдающему. Выдающий выдал несколько сертификатов серверам на 1 год. Потом стала задача увеличить срок корневому и выдающему. Но чтобы выданные сертификаты жили. На корневом поменяли в реестре на 10 лет,выдали. Появился под номером 1, сроком с 2012 до 2022. Потом решили сделать на обоих 20 лет. Поменяли в реестре ,выпустили на корневом, появился под номером 2 ,но все равно до 2022. Выпустили еще несколько,результат один до 2022. На CA dв выданныхсертификатах стоит Cross. Можно не переустанавливая УЦ все таки сделать на 20 лет? Спасибо.Здравствуйте!
А можно сделать,чтобы при запросе на пользовательский сертификат через веб-интерфейс CA
Выдавался сертификат из расширенного шаблона версии 2. Где стоит больший срок и другие полезные вещи.
Сейчас, что бы не делалось, при запросе сертификата пользователя (не через расширенную форму) всегда берется шаблон по умолчанию версии 1. Где срок 1 год и ничего поменять нельзя. Спасибо.При запросе через веб-форму, вам предоставляется возможность выбрать шаблон, по которому генерировать сертификат. У вас в этом выпадающем списке есть нужный шаблон?
Здравствуйте!
Эту проблему я рещил, в файле certrqst.inc исправил имя шаблона. Теперь другая проблема. У пользователя AD , у которого нет ящика почтового, при запросе на сертификат пишет:
политика выдачи сертификата отвергла запрос адрес электронной почты нельзя вставит в имя субъекта. Где поправить надо? Спасибо.Тут два варианта:
1. Указываем e-mail адрес в свойствах учетки в АД (на первой вкладке)
2. Правим шаблон сертификата — указываем на базе чего генерировать основное имя.Спасибо,все получилось.
И последнее. Когда на веб-интерфейсе на компьютере откуда запрашивал сертификат заходишь в просмотр состояния запроса на сертификат, то их иногда там несколько штук. А на УЦ в запросах нет таких. Так и должно быть? Когда нажимаешь на какой-нибудь, пишет,что был отвергнут или уже выдан по нему, и после этого пропадает.Так быть не должно. Сложно сказать почему у вас так происходит.
Добрый день!
Помогите, пожалуйста.
Я настроил на CA 2008 enterprise Issue-Архивацию и восстановление ключей.При ручной подаче запроса на Сертификат пользователя, который использует расширенный шаблон , с включенной опцией- Архивировать закрытый ключ
CA выдает ошибку: В запросе отсутствует требуемый закрытый ключ для архивирования сервером 0Х80094804 (-2146875388)
Если же выбрать расширенную форму запроса и выбрать тот же шаблон из списка, не меняя ничего в нем, то сертификат выдается и ключ архивируется.
В чем может быть проблема? Чтобы при запросе сертификата пользователя использовался нужный мне шаблон, я менял в файле C:\Windows\System32\CertSrv\certqpt.inc
со стандартного User на свой User 2003. Больше ничего не делал.
Спасибо.Здравствуйте!
Подскажите,а как поменять порядок шаблонов, в расширенной форме запроса?
Спасибо.Никогда не задумывался на тему того, по какому принципу они сортируются. Не подскажу ответа на этот вопрос. А если не секрет, то зачем вам изменять порядок сортировки шаблонов?
Добрый день!
Не подскажите, как называется оснастка для удаленного управления CA 2008 и оснастка с графическим интерфейсом для восстановления закрытых ключей и где их скачать?
Спасибо.Подскажите. Для издающего центра (который Issusing) не могу найти пути C:\Windows\System32\CertSrv\, папки CertSrv просто не существует, а оттуда мне нужно забрать crt файлик. Что необходимо сделать что бы там появился сертификат?
Возможно в настройках СА в CRL Distribution Point у вас указано другое место хранения сертификатов? (file://. )
если кто-то прочитает этот комментарий.. автор пытается настроить Enterprise сервер в качестве корневого, ОК наверное в его проекте это может иметь место. рекомендуемый же сценарий во всех инфраструктурах где есть есть корневой-подчиненный серверы — это использование в качестве корневого севера Standalone.
Памятка для удостоверяющих центров и других участников PKI
Удостоверяющий центр, в чьи функции входит поддержание жизненного цикла сертификатов открытых ключей проверки электронной подписи, шифрования, аутентификации и защиты каналов передачи данных, их выпуск, распределение, депонирование, резервное копирование, восстановление, отзыв и ведение списка отозванных сертификатов, является важнейшим участником и арбитром инфраструктуры открытых ключей.
УЦ должен работать, как часы. От его правильного функционирования зависит электронный документооборот множества клиентов и систем.
Некорректная работа или сбой удостоверяющего центра может привести к санкциям регуляторов, искам недовольных клиентов для самого УЦ и значительным финансовым и репутационным потерям всех участников электронного обмена.
Для удостоверяющих центров, аккредитованных в Министерстве цифрового развития, связи и массовых коммуникаций, выпускающих квалифицированные сертификаты и обеспечивающих безусловно юридически значимый электронный документооборот, такой вопрос стоит еще более остро.
В этом посте я хочу рассказать, с какими критическими проблемами и нарушениями в работе УЦ часто приходится сталкиваться, а также о том, как их избежать.
У полноправного участника Public Key Infrastructure, должна быть информационная система со встроенными СКЗИ, которая позволяет вести электронный документооборот с клиентами и партнерами, обмениваясь с ними документами с электронной подписью (ЭП) или зашифрованными данными.
Когда партнер присылает документы с ЭП, система выполняет ряд действий. Она проверяет электронную подпись на документе и партнерский сертификат открытого ключа проверки этой подписи.
В частности, для сертификата партнера строится путь сертификации — цепочка сертификатов, от его конечного пользовательского, на котором проверилась ЭП, до корневого центра сертификации.
В случае с квалифицированными сертификатами корневым будет сертификат Министерства цифрового развития, связи и массовых коммуникаций, а промежуточным между корневым и конечным пользовательским – сертификат аккредитованного УЦ, выданный головным УЦ Министерства цифрового развития.
Для квалифицированных сертификатов также выполняются проверки согласно 63-ФЗ «Об электронной подписи» и Приказа ФСБ РФ №795. Контролируется наличие и правильность заполнения всех необходимых атрибутов в сертификате пользователя.
Одна из главных задач контроля и ключевых фишек PKI в автоматическом электронном обмене документами – это необходимость и возможность убедиться, что сертификат не был отозван партнером и УЦ подтверждает, что сертификат действующий.
Сбои и некорректная работа УЦ в части публикации CRL
В сертификатах есть атрибут CDP — CRL Distribution Points, в нем УЦ публикует ссылки на свой список отозванных сертификатов — Certificate Revocation List
Сам по себе сертификат тоже является электронным документом с электронной подписью, которую ставит УЦ при его выпуске. Таким образом все атрибуты внутри сертификата, в том числе открытый ключ и ссылки на списки отзыва, заверены удостоверяющим центром и защищены от подмены.
CRL тоже подписан ЭП удостоверяющего центра, что дает дополнительную защиту от подмены и атак посредника «Man in the middle» при его загрузке по открытому каналу. Он содержит атрибуты с периодом своего действия и серийные номера отозванных сертификатов.
Процедура полной проверки сертификата на отзыв сводится к необходимости загрузить список с указанного URL, проверить срок его действия, проверить ЭП, убедиться, что серийного номера данного сертификата в нем нет.
Невозможность по тем или иным причинам убедиться, что сертификат пользователя не отозван, приводит к отрицательному результату проверки как самого сертификата, так и электронной подписи на поступивших от этого пользователя документах.
Такие документы будут отвергнуты до восстановления возможности проверить сертификат на отзыв.
То же самое касается контроля клиентских и серверных сертификатов, которые используются для построения защищенного канала связи TLS ГОСТ или TLS RSA по протоколу HTTPS. Если системам партнеров не удается проверить их на отзыв, то защищенное и 100% доверенное соединение партнеры установить между собой не смогут.
Какие сбои и нарушения здесь может допустить УЦ?
1. Перенаправление ссылок (Redirect)
УЦ опубликовал в сертификате конкретный URL, но на сервере, где этот ресурс опубликован, происходит перенаправление клиента на другой URL.
Вызывающая система на Java может легко определить, что включено перенаправление следующим образом:
2. HTTPS в CDP атрибуте сертификата и ни одной общедоступной ссылки
Приходилось встречать даже квалифицированные сертификаты, где не было ни одной ссылки, по которой система могла бы свободно загрузить список отзыва.
Попадались сертификаты с https://, ldap:// или защищенный SFTP, также были просто URL с IP адресами из внутренней подсети. Все эти ссылки допустимы при наличии хотя бы одной ссылки HTTP или FTP (без логина и пароля) доступной из сети Internet всем.
Почему HTTPS к свободным не относится?
За списками отзыва могут обращаться далеко не только интернет-браузеры, имеющие обширное хранилище корневых доверенных сертификатов международных УЦ, которое позволяет им поднимать защищенное соединение по HTTPS-ссылке и принимать ресурс как доверенный.
Другие информационные системы могут не иметь такого хранилища с предустановленными корневыми сертификатами и не обязаны поднимать контекст защищенного соединения к HTTPS-ссылкам.
Просто невозможно во все системы установить все корни для всего многообразия УЦ, выпускающих SSL/TLS-сертификаты.
По понятным причинам информационные системы также не могут знать логин и пароль от FTP и не будут иметь доступ к внутренней службе Active Directory по LDAP-протоколу.
Поэтому принято, что CRL публикуется в свободном доступе.
3. HTTP перенаправление (redirect) на HTTPS
Это гибридная ситуация, с которой приходилось сталкиваться, состоящая из приведенных выше пунктов 1 и 2.
Как такое возможно?
Сайт компании, где УЦ публикует свои списки отзыва, или просто веб-сервер, который используется удостоверяющим центром для этих целей, запущен, например, на Nginx.
Администратор сайта, желающий исключительно добра и защитить сайт и пользователей, совершенно забыв, а может, и не зная про публикацию CRL, включает безусловный redirect всего сайта на HTTPS.
Получается, что в сертификате приведен URL с http://, а системы, которые чувствительны к такому факту подмены подписанной информации из сертификата и справедливо защищаются от атак посредников, перестают загружать списки отзыва данного УЦ, пока администратор не настроит на сайте исключения для CRL.
4. Фильтрация по User Agent
Данная проблема и нарушение доступа к спискам отзыва сильно перекликается с приведенной в пункте 3.
Тот же администратор сайта, на том же Nginx включает фильтрацию по User Agent. Например, все системы на Java будут получать ошибку HTTP 403 при обращении к ресурсу.
Администратор забывает про то, что совершенно любая система должна иметь доступ к спискам отзыва в соответствии со стандартами группы PKIX.
Еще администратор сайта, где публикуются списки отзыва, может включить redirect на основе User Agent.
5. Просроченный CRL
Сертификат может содержать несколько ссылок на списки отзыва. Внутри каждого CRL могут быть вложены ссылки на его дельты с иными, более короткими сроками жизни, а следовательно, обновляемые чаще.
Хорошая информационная система должна загрузить список по каждой доступной ссылке, загрузить все вложенные дельты и убедиться, что серийный номер проверяемого сертификата не встречается ни в одном из них.
Рекурсивный алгоритм поиска в коробках, вложенных друг в друга, хорошо подходит для решения этой задачи.
А чтобы не загружать CRL каждый раз при интенсивном обмене в автоматических информационных системах, списки отзыва можно кэшировать на заданное разумное время, но не больше срока их жизни.
Были случаи, когда по каким-то причинам УЦ своевременно не обновлял CRL.
Список отзыва с истекшим сроком действия, естественно, не принимается. И если для сертификата нет или не удается загрузить по другим ссылкам действующий список, то общий результат будет отрицательным, а документ с ЭП отвергнут.
6. Сбои на сетевом и транспортном уровне
В качестве примера можно привести ситуацию со сбоем или некорректными настройками и состоянием на оборудовании удостоверяющего центра или сайта организации.
В сертификате, выпущенном УЦ, может быть прописано два URL с http:// и разными host именами. Такой подход правильный, он позволяет иметь резерв и всегда держать одну ссылку в доступе, если требуется провести какие-то работы на другом сервере.
Но вот незадача. Вызывающая система вдруг начинает получать IOException: ConnectionTimeOut при попытке подключения к одной из ссылок. Вторая ссылка при этом работает и отдает CRL. А вызывающая система все равно начинает замедляться на настроенное в ней время, например, ConnectionTimeOut=15000 mSec, потому что проверяет обе ссылки, и ей приходится ждать ответа от недоступной в настоящий момент.
А если в CDP сертификата четыре, пять разных ссылок на CRL и при этом две или три из них оказываются недоступны с ConnectionTimeOut?
В этом случае время проверки сертификата возрастает до неприличной величины, равной времени таймаута, умноженному на количество таких ссылок.
А что, если обмен нашей информационной системы идет с этим УЦ или партнером, организацией, аффилированной с данным УЦ? И система партнера имеет свой таймаут на вызов нашей информационной системы, который заведомо меньше того времени, которое наша система тратит на проверку их сертификата?
Партнеры говорят нам, что не получают ответ от нашей системы и отключаются по таймауту, а происходит это на самом деле из-за регламентных работ на их УЦ.
Почему может происходить ConnectionTimeOut?
Как вариант, это регламентные работы, сетевая атака или повышенная нагрузка на сайт УЦ, что привело к неконсистентному состоянию:
какой-то брандмауэр, файрвол на пути, который просто начал съедать сетевые пакеты, не сообщая отправителю такие вещи, как «No Route to host»
началась потеря пакетов из-за неправильной конфигурации сети или перегрузки линии
слишком много запросов, перегружающих сервер
небольшое количество одновременно доступных потоков / процессов на сервере, что приводит к их блокировке. Это происходит особенно с запросами, выполнение которых занимает много времени и может сочетаться с предыдущим пунктом
Как с этим справляться?
Удостоверяющим центрам следует мониторить нагрузку на точки публикации списков отзыва, применять средства защиты от сетевых атак.
А в случае регламентных работ необходимо следить за тем, чтобы сервер, слушающий данный сокет, был корректно погашен, а не оставался в некоем подвешенном состоянии.
Если точка публикации будет корректно отключена, то вызывающая система, мгновенно получив от этой ссылки, например, IOException Connection Refused: connect, сразу перейдет к загрузке по следующему URL.
Вызывающая система для купирования таких ситуаций может выполнять кэширование «битых» ссылок на непродолжительный интервал, например 5 минут. Это позволит при интенсивном обмене практически не потерять скорость обработки запросов и одновременно сохранить актуальность результатов проверки сертификатов.
Чем должны руководствоваться УЦ при публикации CRL
Спецификацией RFC 5280 IETF и стандартом X.509 ITU-T, разработанными Инженерным советом Интернета и Международным консультационным комитетом по телефонии и телеграфии.
В частности, пунктом 8. Security Considerations из RFC 5280
When certificates include a cRLDistributionPoints extension with an https URI or similar scheme, circular dependencies can be introduced. The relying party is forced to perform an additional path validation in order to obtain the CRL required to complete the initial path validation! Circular conditions can also be created with an https URI (or similar scheme) in the authorityInfoAccess or subjectInfoAccess extensions. At worst, this situation can create unresolvable dependencies.
CAs SHOULD NOT include URIs that specify https, ldaps, or similar schemes in extensions. CAs that include an https URI in one of these extensions MUST ensure that the server’s certificate can be validated without using the information that is pointed to by the URI. Relying parties that choose to validate the server’s certificate when obtaining information pointed to by an https URI in the cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess extensions MUST be prepared for the possibility that this will result in unbounded recursion.
УЦ не должны включать HTTPS или LDAP-ссылки для публикации своих списков отзыва.
Если УЦ все же включают такие ссылки, то они должны убедиться, что серверные сертификаты могут быть проверены без использования этих ссылок.
Также удостоверяющим центрам следует знать и помнить, что включение HTTPS-ссылок на свои списки отзыва, в том числе в серверные сертификаты для того же HTTPS-канала, может создавать циклические неразрешимые зависимости и привести к неограниченной рекурсии в попытках проверить сертификат на отзыв и установить защищенное соединение с применением этого же сертификата.
Другими словами, клиент и сервер будут пытаться поднять защищенное HTTPS-соединение друг с другом. Для этого им потребуется проверить сертификаты на отзыв. А чтобы это сделать, тоже нужно поднять защищенное соединение по HTTPS-ссылке к CRL, которую УЦ неосмотрительно опубликовал в атрибуте сертификата.
Следует упомянуть, что существует иной способ проверки сертификата на отзыв.
Протокол онлайн-проверки статуса сертификата OCSP — Online Certificate Status Protocol.
Такие сертификаты также включают в себя стандартный атрибут CDP и могут проверяться обычным способом.
А для работы с сервером OCSP они должны включать еще и расширение OCSP Server Client.
Но это материал для отдельной статьи.
Обязательные атрибуты квалифицированных сертификатов
Состав квалифицированного сертификата регулируется Федеральным законом «Об электронной подписи» от 06.04.2011 N 63-ФЗ и Приказом ФСБ РФ от 27 декабря 2011 г. N 795 «Об утверждении Требований к форме квалифицированного сертификата ключа проверки электронной подписи».
Несколько раз встречались квалифицированные сертификаты проверки подписи юридических лиц, выпущенные аккредитованным УЦ, в которых в поле Subject — субъект сертификации отсутствовал атрибут L – Местоположение.
Контроль квалифицированных сертификатов нашей системы отвергал данный сертификат и документы с ЭП партнера.
Удостоверяющий центр данную ситуацию комментировал так:
атрибут L для юридических лиц, зарегистрированных в г. Москве, не проставляется согласно 63-ФЗ и Приказа №795
На конкретный пункты Закона и Приказа в УЦ не ссылались.
Собственный повторный анализ юридических аспектов показал:
63-ФЗ от 06.04.2011 «Об электронной подписи»
Статья 14. Сертификат ключа проверки электронной подписи
2. Сертификат ключа проверки электронной подписи должен содержать следующую информацию:
2) фамилия, имя и отчество (если имеется) — для физических лиц, наименование и место нахождения — для юридических лиц или иная информация, позволяющая идентифицировать владельца сертификата ключа проверки электронной подписи;
Статья 17. Квалифицированный сертификат
2. Квалифицированный сертификат должен содержать следующую информацию:
2) фамилия, имя, отчество (если имеется) владельца квалифицированного сертификата — для физического лица, не являющегося индивидуальным предпринимателем, либо фамилия, имя, отчество (если имеется) и основной государственный регистрационный номер индивидуального предпринимателя — владельца квалифицированного сертификата — для физического лица, являющегося индивидуальным предпринимателем, либо наименование, место нахождения и основной государственный регистрационный номер владельца квалифицированного сертификата — для российского юридического лица, либо наименование, место нахождения владельца квалифицированного сертификата, а также идентификационный номер налогоплательщика (при наличии) — для иностранной организации (в том числе филиалов, представительств и иных обособленных подразделений иностранной организации);
Приказ ФСБ РФ от 27 декабря 2011 г. № 795
III. Требования к порядку расположения полей квалифицированного сертификата
5) stateOrProvinceName (наименование штата или области).
В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование соответствующего субъекта Российской Федерации. Объектный идентификатор типа атрибута stateOrProvinceName имеет вид 2.5.4.8;
6) localityName (наименование населенного пункта).
В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование соответствующего населенного пункта. Объектный идентификатор типа атрибута localityName имеет вид 2.5.4.7;
7) streetAddress (название улицы, номер дома).
В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую часть адреса места нахождения соответствующего лица, включающую наименование улицы, номер дома, а также корпуса, строения, квартиры, помещения (если имеется). Объектный идентификатор типа атрибута streetAddress имеет вид 2.5.4.9;
В сертификате партнера в имени субъекта сертификации были указаны: stateOrProvinceName (наименование штата или области), streetAddress (название улицы, номер дома).
И не указано localityName (наименование населенного пункта).
locality — Местонахождение
В Законе 63-ФЗ и Приказе №795 нет информации, что для города Москва не нужно заполнять атрибут locality — Местонахождение.
Наоборот в обоих документах на русском языке применяется термин место нахождения, чему соответствует атрибут localityName ( 2.5.4.7)
Согласно части 2.2 статьи 18 Закона об ЭП для заполнения квалифицированного сертификата в соответствии с частью 2 статьи 17 Закона об ЭП аккредитованный удостоверяющий центр запрашивает и получает из государственных информационных ресурсов, в том числе, выписку из единого государственного реестра юридических лиц в отношении заявителя ‑ юридического лица.
Таким образом, в случае отсутствия в выписке из единого государственного реестра юридических лиц информации о наименовании населенного пункта, но при наличии информации о наименовании муниципального образования, аккредитованному удостоверяющему центру для заполнения квалифицированного сертификата вместо наименования соответствующего населенного пункта следует использовать наименование соответствующего муниципального образования.
На основании изложенного в качестве значения атрибута имени «localityName» поля «subject» в структуре квалифицированного сертификата следует указывать текстовую строку, содержащую наименование соответствующего населенного пункта или соответствующего муниципального образования.
Данное извещение с разъяснениями регулятора, как правильно заполнять атрибут L в квалифицированном сертификате юридического лица, также было направлено в аккредитованный УЦ.
Для чего настраивается cdp уц
Как известно, каждый выданный в CA сертификат (кроме самоподписанных сертификатов. Корневой сертификат так же является самоподписанным сертификатом) содержит 2 расширения:
Эти ссылки берутся не из воздуха, а из настроек CA. Вот как они выглядят для дефолтной инсталляции Certificate Services:
В принципе, эти настройки годятся для нормальной работы certificate chaining engine в небольших сетях с одним лесом и доменом без сайтов (или с сайтами, соединённых быстрыми каналами). Если сеть состоит из нескольких доменов (или лесов с настроенным Cross-forest enrollment) и сайтами, соединённых не очень быстрыми каналами, то эти настройки уже могут приводить к сбоям построения и проверок цепочек сертификатов. Я не буду рассказывать, что означают галочки, т.к. с ними вы можете ознакомиться в статьях CRL Publishing Properties и AIA Publishing Properties, а приступлю сразу к разбору путей.
Первый путь указывает путь файловой системы, куда физически публикуются файлы CRL и CRT. Следующая ссылка ( LDAP:// ) указывает, точку публикации CRL и CRT в Active Directory. Так же эти пути будут прописаны во всех выдаваемых сертификатах. Третья ссылка ( HTTP:// ) указывает 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 свалится в бесконечный цикл проверки сертификатов.
Периодичность публикации и обновления файлов CRL и CRT
По умолчанию в 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 в корневых сертификатах
Как уже отмечалось, расширения 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.
Протокол CPD (Cisco Discovery Protocol)
Давайте рассмотрим достаточно распространённую тему — протокол CDP. Что же о нём можно сказать, если о нём всё известно? Однако некоторые механизмы работы, позволяющие упростить работу сетевого инженера, знают не все. О них и поговорим.
Протокол CPD (Cisco Discovery Protocol) – проприетарный протокол компании Cisco, работающий на 2 уровне модели OSI, который позволяет сетевым устройствам (и не только сетевым) анонсировать в сеть информацию о себе и принимать такие анонсы от своих соседей.
Протокол достаточно полезный, так как он может показать, что за устройство (версия ПО, номера портов, платформа и ещё много другой информации) подключено в сеть. Это может быть удобно для составления карты сети, ведения документации и мониторинга сети. Однако также это облегчает атаку на сеть. В связи с этим протокол CDP в большинстве случаев отключают.
В интернете огромное количество информации по данному протоколу. Например, как посмотреть соседние устройства командой show cdp neighbors :
Как видим из вывода, видны description, порты, платформа соседнего устройства. Также можно посмотреть и более детальную информацию о соседнем устройстве с помощью show cdp neighbors detail :
Тут уже видны и IP адреса и версия ПО, что достаточно удобно для документирования неизвестной сети.
Логика работы
Логика работы протокола CDP достаточно простая и в общих чертах механизм работы следующий: 1. Устройство посылает multicast-сообщение на MAC-адрес 01:00:0C:CC:CC:CC (по умолчанию каждые 60 секунд на порты Ethernet). 2. Принимающее устройство сохраняет эти сообщения в CDP-таблицу. Если спустя 180 секунд (3 анонса CDP) устройство не прислало ни одного сообщения, – удаляется из базы CDP.
Однако несмотря на все минусы и плюсы протокола в качестве мониторинга за сетевым оборудованием, CDP имеет и дополнительные возможности для управления сетевыми устройствами.
В CDP существует механизм объединения сетевых устройств в кластер, которым можно управлять с одного устройства – CDP Cluster.
Когда такой функционал может потребоваться?
Например, вы случайно или не случайно потеряли доступ к оборудованию через ssh/telnet, а до устройства физически сложно добраться. В таком случае единственное что требуется – включенный протокол CDP.
Настройка
Настройку CDP cluster рассмотрим на коммутаторах 2960: 1. Заходим на доступный коммутатор и включаем CDP cluster:
Чтобы отключить кластер, необходимо удалить всех cluster member из него и только потом отключить сам кластер:
Посмотреть кластер можно командой show cluster .
В итоге имеется полезный и удобный протокол для мониторинга и управления сети на устройствах Cisco, однако из-за отсутствия встроенных механизмов безопасности CDP может нести угрозу внутренней сети предприятия. Поэтому решение об использовании или отключении протокола принимать вам.
/AlexxHost/
Вы попали на блог, целиком и полностью посвященный продуктам компании Microsoft. В основном речь будет идти про системы корпоративных коммуникаций на базе Exchange Server.
среда, 25 мая 2011 г.
Проект внедрения PKI – конфигурирование серверов
В про шлой части — Проект внедрения PKI – базовая инфраструктура, мы разобрались с вспомогательными составляющими нашей инфраструктуры PKI. Далее давайте посмотрим непосредственно на конфигурирование серверов.Начнем с корневого СА:
Конфигурирование Root CA
Серверу необходимо присвоить следующее DNS-Имя:
vm-ca-root.alexxhost.ru
Данные для установки корневого сервера CA:
Post-install configuration
После установки роли СА на сервер необходимо сделать дополнительные настройки:
certutil -setreg CA\CRLPeriodUnits 90
certutil -setreg CA\CRLPeriod "Days"certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Days"certutil -setreg CA\CRLOverlapPeriod "Weeks"
certutil -setreg CA\CRLOverlapUnits 2certutil -setreg CA\ValidityPeriodUnits 10
certutil -setreg CA\ValidityPeriod "Years"Примечание: Данные параметр может быть изменены и через реестр в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\
certutil -setreg CA\AuditFilter 127
Удаляем все шаблоны из списка доступных для выдачи, кроме Subordinate Certification Authority.
Конфигурирование расширений CDP/AIA:
Настройки CDP/AIA производятся в свойствах СА (правой кнопкой мыши на имени СА – Properties) на вкладке Extensions.
Настройки CRL Distribution Point:
Удаляем все LDAP-ссылки;
Настройки AIA:
Удаляем все LDAP-ссылки;
Галочки должны быть убраны. (Остаётся без изменений)
Публиковать CRT в нестандартные локации невозможно, поэтому их необходимо переименовать и переместить из папки C:\WINDOWS\system32\CertSrv\CertEnroll вручную в папку \\S-Web-01\pki
На этом закончим конфигурирование Root CA и перейдем к настройке выдающих СА:
Issuing CA
Серверу необходимо присвоить следующее DNS-Имя:
Issuing-CA-1.alexxhost.ru
Данные для установки корневого сервера CA: