Эта статья является частью в тестовом окружении.
После выбора схемы иерархии, необходимо выбрать:
- срок действия сертификата CA ;
- сроки действия издаваемых сертификатов;
- сроки действия Base CRL и Delta CRL ;
- срок действия перекрытия (overlap) Base CRL и Delta CRL ;
- использование OCSP Online Responder;
- CRL Distribution Points (CDP) и Authority Information Access (AIA).
Необходимо заранее спланировать изменения, которые будут вносится в настройки CA , как минимум, это параметры CDP и AIA расширений. Их необходимо внести сразу после установки, и до выдачи первых сертификатов. По умолчанию, некоторые шаблоны помечены для автоматического издания. Доменный контроллер запросит себе два сертификата сразу же, как только обнаружит появление CA . Это произойдет при автоматическом обновлении групповых политик. По этой причине, после полной настройки CA нужно будет убедится, что ни один сертификат еще не был выдан.
Выбор срока действия сертификата CA
Срок действия сертификата CA рекомендуется выбирать в пределах 5-20 лет. Чем больше, тем реже придется заниматься его распространением, но и тем больше будет проблем при компрометации этого сертификата. Для одноуровневой иерархии срок действия сертификата CA по умолчанию 5 лет. Срок действия сертификата CA выбирается при его установке или вышестоящим CA .
Выбор сроков действия издаваемых сертификатов
Значение по-умолчанию 2 года. Шаблоны переопределяют это значение.
Со временем CRL может очень сильно вырасти в размерах. Чтобы уменьшить нагрузку по получению CRL , используется Delta CRL .
Ссылки в расширениях CDP и AIA можно изменить и добавить двумя способами. При помощи certutil.exe и при помощи оснастки certsrv.msc . Однако при помощи оснастки certsrv.msc нельзя поменять порядок следования ссылок в сертификатах. И если планируется изменить порядок по умолчанию, то certutil.exe остается единственным выбором. Единственным, потому, что через оснастку доступны не все свойства ссылок. Взгляните сами на дефолтные ссылки AIA из свежеустановленного CA . Для LDAP ссылки установлено свойство CSURL_SERVERPUBLISH, однако в оснастке просто нет возможности установить это свойство. Интересно, не правда-ли.
Планирование CDP
| № | Код | |
| 0 | 65 | C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl
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
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
6:http://%1/CertEnroll/%3%8%9.crl |
| 3 | 0 | file://%1/CertEnroll/%3%8%9.crl
0:file://%1/CertEnroll/%3%8%9.crl |
- для ссылки 2 добавлены две опции, т.е. включается добавление в издаваемые сертификаты HTTP ссылки;
- ссылка 3 не меняется, поскольку IIS сервер находится на сервере CA , и публикация для HTTP сервера выполняется по ссылке 0.
certutil.exe :
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"
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"
Планирование AIA
| № | Код | Ссылка и используемые параметры |
| 0 | 1 | C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt
1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt |
| 1 | 3 | ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11
3:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11 |
| 2 | 2 | http://%1/CertEnroll/%1_%3%4.crt
2:http://%1/CertEnroll/%1_%3%4.crt |
| 3 | 0 | file://%1/CertEnroll/%1_%3%4.crt
0:file://%1/CertEnroll/%1_%3%4.crt |
| 4 | 32 | http://%1/ocsp
32:http://%1/ocsp |
Примечания и отличия от конфигурации по-умолчанию:
- параметры для ссылки 0 невозможно задать из оснастки certsrv.msc ;
- параметры для ссылки 1 невозможно задать из оснастки certsrv.msc ;
- для ссылки 2 включена публикация в издаваемых сертификатах;
- ссылка 3 не меняется, поскольку HTTP сервер находится на сервере CA , и публикация для HTTP сервера выполняется по ссылке 0;
- добавлена ссылка 4 с публикацией ссылки на OCSP Responder; если не добавить эту ссылку то нет никакого смысла ставить сервис Online Responder.
Итоговая команда для изменений при помощи certutil.exe :
certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n3:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11\n2:http://%1/CertEnroll/%1_%3%4.crt\n0:file://%1/CertEnroll/%1_%3%4.crt\n32:http://%1/ocsp"
Она же, но в случае выполнения из командного файла:
Чеклист
| Название | Название параметра в certutil | Значение по-умолчанию | Выбранное значение |
| Имя CA | YourName Root Certification Authority | ||
| Тип CA | |||
| Срок действия сертификата CA | 5 Years | 10 Years | |
| Срок действия издаваемых сертификатов | |||
| Время действия издаваемых сертификатов | CA\ValidityPeriodUnits | 2 | |
| Единица измерения срока действия издаваемых сертификатов | CA\ValidityPeriod | Years | |
| Срок действия Base CRL | |||
| Период достоверности Base CRL | CA\CRLPeriodUnits | 1 | |
| Единица измерения периода достоверности Base CRL | CA\CRLPeriod | Weeks | |
| Срок действия Delta CRL | |||
| Период достоверности Delta CRL | CA\CRLDeltaPeriodUnits | 1 | |
| Единица измерения периода достоверности Delta CRL | CA\CRLDeltaPeriod | Days | |
| Перекрытие периода действия Base CRL | |||
| Время до истечения срока действия текущего основного CRL , за которое будет публиковаться новый основной CRL . | CA\CRLOverlapUnits | 0 | 24 |
| Единица измерения этого времени для основного CRL (Hours|Minutes) |
CA\CRLOverlapPeriod | Hours | Hours |
| Перекрытие периода действия Delta CRL | |||
| Время до истечения срока действия текущего инкрементального (если используется) CRL , за которое будет публиковаться новый инкрементальный CRL (максимум 12 часов) |
CA\CRLDeltaOverlapUnits | 0 | 12 |
| Единица измерения этого времени для инкрементального CRL (Hours|Minutes) |
CA\CRLDeltaPeriodPeriod | Minutes | Hours |
| Использовать OCSP | Yes | ||
| CDP extension | CA\CRLPublicationURLs | File, LDAP | File, LDAP , HTTP |
| AIA extension | CA\CACertPublicationURLs | File, LDAP | File, LDAP , HTTP, OCSP |
Конфигурационный скрипт для Certification Authority
До установки роли AD CS необходимо создать конфигурационный скрипт, который выполнит послеустановочную настройку CA на основании выбранных параметров. Ниже следует пример такого скрипта:
CAScript.cmd
:: 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"
:: AIA
certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11\n2:http://%%1/CertEnroll/%%1_%%3%%4.crt\n0:file://%%1/CertEnroll/%%1_%%3%%4.crt\n32:http://%%1/ocsp"
:: В случае использования роли OCSP , при обновлении сертификата CA могут быть
:: проблемы с проверкой подлинности сертификатов. Чтобы устранить эту проблему
:: используется:
certutil –setreg CA\UseDefinedCACertInRequest 1
:: Включаем наследование Issuer Statement в издаваемых сертификатах
certutil -setreg Policy\EnableRequestExtensionList +"2.5.29.32"
:: Задаём срок действия издаваемых сертификатов
::certutil -setreg CA\ValidityPeriodUnits 2
::certutil -setreg CA\ValidityPeriod "Years"
:: Задаём параметры публикации CRL
::certutil -setreg CA\CRLPeriodUnits 1
::certutil -setreg CA\CRLPeriod "Weeks"
::certutil -setreg CA\CRLDeltaPeriodUnits 1
::certutil -setreg CA\CRLDeltaPeriod "Days"
:: Меняем параметры CRL Overlap
certutil -setreg CA\CRLOverlapUnits 24
certutil -setreg CA\CRLOverlapPeriod "Hours"
certutil –setreg CA\CRLDeltaOverlapUnits 12
certutil –setreg CA\CRLDeltaOverlapPeriod "Hours"
:: включаем полный аудит для сервера CA
certutil -setreg CA\AuditFilter 127
:: Перезапускаем сервис CA
net stop certsvc && net start certsvc
:: Публикуем новый CRL в новую локацию.
certutil -CRL
Примечание: данный материал публикуется как обязательный для знания 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) )
В принципе, эти настройки годятся для нормальной работы 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 в выдаваемых сертификатах при таких настройках:
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
Authority Info Access
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
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
Это важно знать, поскольку 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 до 2 раз в неделю и Delta CRL до 2-х раз в сутки. Если сертификаты отзываются редко (реже, чем раз в неделю), то периодичность публикации Base CRL можно увеличить до 2-4 недель, а от Delta CRL можно даже отказаться или публиковать раз в неделю. Но это касается только Issuing или Online CA. Для Offline CA рекомендации будут чуть другие. Поскольку Offline CA выдают сертификаты только другим CA и большую часть времени выключены, для них следует отключить публикацию Delta CRL (установив параметр CRLDelta PeriodUnits в ноль), а основные 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 :
Empty = true
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 и для более детального изучения всего этого процесса уже следует обратиться сюда:
- КриптоАРМ
Разработчик: ООО "Цифровые Технологии"
- КриптоАРМ Старт просит лицензию
Везде написано что КриптоАРМ Старт это бесплатная версия программы, и лицензию запрашивать не должна!
Все верно, однако мало кто обращает внимания на то, что функционал в бесплатной версии значительно урезан, и "Старт" с Российскими ГОСТами работать не будет. Поэтому, когда пользователи пытаются подписать документы с использованием ГОСТового криптопровайдера, своим квалифицированным сертификатом, неизбежно возникает проблема. Необходимо приобрести
- Не найден лицензионный ключ "КриптоАрм"
Нужно просто установить лицензионный ключ для программы КриптоАрм, поскольку он не был установлен ранее или его срок действия истек.
Если он у Вас уже есть, просто запускаем программу КриптоАРМ, в верхнем меню находим пункт помощь, и в выпадающем списке выбираем "Установить лицензию" В открывшееся окно в поле "Лицензионный ключ" можно внести лицензию.
Если лицензии у Вас еще нет, то ее легко можно
- Как получить временную лицензию на КриптоАРМ
При первой установке предоставляестя тестовый период на 14 дней. Поддерживается полный функционал , затем программа перейдет в ограниченную версию Старт, для активации полного функционала необходимо будет приобрести лицензию.
-
Возникновение этой ошибки свидетельствует о некорректном вводе лицензии, причин может быть несколько:
Во-первых, лицензии между версиями программы не совместимы, поэтому стоит убедиться, что версия установленного дистрибутива совпадает с версией лицензии, которую Вы приобрели. Определить версию можно просто взглянув на лицензионный ключ продукта. Для КриптоАРМ - версии соответствует третий символ лицензии.
Во-вторых,
В-третьих,
- Программа не работает, висит окно "пожалуйста, подождите"
Нужно отключить режим КЭП (нужен для проверки сертификатов на квалифицированность, для подписания документов не обязательно его использовать).
- - Кликаем правой кнопкой мыши по любому документу,
- - В открывшемся меню выбираем пункт "КриптоАРМ",
- - Снимаем галочку "Квалифицированная подпись".
можно обновить программу до последней версии, скачать .
- КриптоАРМ при формировании отчета просит pin-код, как его поменять
При создании подписи программа КриптоАРМ обращается к контейнеру, в котором хранится сертификат ЭП. Если сертификат хранится на токене, то необходимо ввести пин-код токена. Стандартные пароли производителей собраны в .
Однако, при генерации подписи в удостоверяющем центре, пароль могли поменять на стандартный для этого УЦ, либо на пользовательский (т.е. тот кто получал ЭП на организацию ввел пин-код самостоятельно).
- Не удаётся найти сертификат и закрытый ключ для расшифровки,
использование выбранного сертификата не возможно - Cтатус сертификата неизвестен, локальный СОС не найден
Эта ошибка означает, что актуальный список отозванных сертификатов Удостоверяющего Центра не установлен в локальном хранилище. Нужно проверить статус вашего сертификата в личном хранилище по CRL полученному из УЦ.
Чтобы установить список, проверьте статус сертификата по CRL, полученному из УЦ:
- - В программе “КриптоАРМ” выбрать папку “Личное хранилище сертификатов”;
- - В окне справа выбрать нужный сертификат;
- - Правой кнопкой мыши вызвать контекстное меню и выбрать “Проверить статус” - “По СОС (CRL) полученному из УЦ”.
Статус сертификата должен обновиться, актуальный СОС будет установлен в локальном хранилище.
Если статус не обновился:
- - Откройте меню “Сервис” -> пункт “Свойства обозревателя” -> закладка “Подключения” -> кнопка “Настройка сети”;
- - Убедитесь в том, что в “Настройках сети” флажки “Автоматическое определение параметров” и “Использовать скрипт автоматической настройки” были сброшены;
- - Повторите процедуру обновления статуса сертификата.
Если хотите, чтобы статус обновлялся автоматически:
- - В окне Параметры настройки, выберите закладку Верификация сертификатов;
- - Добавьте нужный УЦ выбором из имеющихся или все УЦ.
- Ошибка при получении последней версии СОС из УЦ
Для использования возможности получения списка отозванных сертификатов из УЦ необходимо соблюдение следующих условий:
- - В проверяемом сертификате должно присутствовать расширение “Точки распространения списков отзыва/CRL Distribution Point (CDP)”, в котором указан правильный адрес списка отозванных сертификатов;
- - По одной (оптимально, если по первой) из точек распространения СОС можно скачать СОС браузером Internet Explorer, не вводя при этом никакой дополнительной информации (имени пользователя, пароля, перехода по ссылкам);
- - В настройках Internet Explorer НЕ должна быть включена автоматическая настройка прокси-сервера. Для проверки этого запустите “Internet Explorer” -> меню “Сервис” -> пункт “Свойства обозревателя” -> закладка “Подключения” -> кнопка “Настройка сети” ->
- СОС и корневой не подгружаются автоматически
- - В верхнем меню выберите раздел "Настройки"->"Управление настройками". В левой части открывшегося окна выбираем пункт "Профили". В правом окне создайте новый или измените старый профиль настроек. В окне "Параметры профиля", выберите закладку Верификация сертификатов. Добавьте нужный УЦ выбором из имеющихся или все УЦ;
- - В настройках Internet Explorer НЕ должна быть включена автоматическая настройка прокси-сервера. Для проверки этого запустите “Internet Explorer” -> меню “Сервис” -> пункт “Свойства обозревателя” -> закладка “Подключения” -> кнопка “Настройка сети” -> должны быть сброшены флажки “Автоматическое определение параметров” и “Использовать скрипт автоматической настройки”.
- Статус сертификата: недействителен, ошибка построения пути сертификации
Вам необходимо установить на рабочем месте корневой сертификат Удостоверяющего центра и список отозванных сертификатов УЦ.
Если у вас их нет, скачайте с официального сайта Удостоверяющего центра или по ссылке в составе сертификата:
- - В КриптоАрм, открыть в личном хранилище нужный сертификат двойным кликом мыши -> Просмотреть -> Вкладка состав;
- - Чтобы посмотреть ссылку на Корневой сертификат надо выбрать “Доступ информации о центре сертификации”;
- - Чтобы посмотреть ссылку на Списки отзыва сертификатов надо выбрать Точки распространения списков.
- Проблема с проверкой сертификата по CTL
Проверка по CTL - это дополнительная функция программы КриптоАРМ и позволяет проверять сертификат по личному списку доверия пользователя. По умолчанию она должна быть выключена.
- - Открываем прорамму КриптоАРМ;
- - В верхнем меню главного окна выберите раздел "Настройки", раздел "Профили";
- - В правом окне создайте новый или измените старый профиль;
- - В окне "Параметры профиля", выберите закладку "Верификация сертификатов";
- - В нижней части вкладки снимите галочку "Использовать CTL для проверки пути сертификации".
- Не активна галочка "Сохранить подпись в отдельном файле"
Пункт "Сохранить подпись в отдельном файле" не доступен, если в текущих настройках подписания выбрано задание каталога сохранения вручную. Чтобы подпись сохранялась в отдельном файле, надо задавать значение - «Текущий каталог»:
- - Откройте программу "КриптоАРМ";
- - В верхнем меню найдите ветку "Настройки";
- - В левой части окна выберете пункт "Профили";
- - Справа выберите профиль по умолчанию (отмечен зеленой галочкой);
- - Откройте профиль;
- - Перейдите на вкладку "Каталоги";
- - Выберите опцию сохранения "Текущий каталог";
- - Сохраните и закройте профиль (Применить);
- - Начните подписывать. В мастере подписи галочка "Сохранить подпись в отдельном файле" будет активна.
- Ошибка при установке: файл не является 7z архивом
Установочный файл скачался не полностью. Одной из причин неполного скачивания файла может быть антивирус, попробуйте его отключить. Так же можно попробовать скачать файл с помощью другого браузера.
- Ошибка при установке 2738
MCafee или другой антивирус блокировал запуск VB script. Чтобы устранить ошибку нужно переустановить VB Script.
- При вызове любой операции появляется окно инсталлятора,
который производит настройку программыПрограмма установилась некорректно, либо повреждены системные файлы. Ее нужно переустановить:
- - Удаляем КриптоАРМ через Панель упарвления/установка и удаление программ;
- - Пререзагружаемся;
- - Устанавливаем программу заново. Скачать последнюю версию можно
- Росреестр не принимает документы. Исходный файл и файл подписи не соответствует друг другу
Если портал Росреестра возвращает подписанные с помощью КриптоАРМ файлы с указанием, что исходный файл и файлы подписи не соответствует друг другу, необходимо:
- - При создании подписи убедиться, что выбран тип кодировки DER и указана опция "Сохранить подпись в отдельном файле". Т.е. необходимо создать отделенную подпись и на портале размещать оба файла (исходный документ и файл подписи, около 2Кб).
- - Если вы все подписали правильно и проверили со своей стороны подпись (она действительна), то проблема на стороне портала, у них периодически случаются сбои, попробуйте отправить файлы повторно.
- Отсутствует личный сертификат, необходимый для расшифрования файла
Если при расшифровке файлов возникает данная ошибка:
- - Переустановите ваш сертификат в КриптоПро CSP по ;
- - Если сертификат удачно обновляется, посмотрите, есть ли он в списке сертификатов получателей зашифрованных данных. Посмотреть можно открыв двойным щелчком мыши зашифрованный файл и дойдя до конца мастера. Серийный номер сертификата должен совпадать с прописанным в составе вашего личного сертификата;
- - Также проверьте, установлены ли лицензии в программах КриптоПро CSP и КритпоАРМ.
- КриптоАРМ Старт просит лицензию
- КриптоПРО CSP
Разработчик: ООО "КРИПТО-ПРО"
- Ошибка: указан неверный серийный номер
Во-первых, лицензии между версиями программы не совместимы, поэтому стоит убедиться что версия установленного дистрибутива совпадает с версией лицензии, которую Вы приобрели. Определить версию можно просто взглянув на лицензионный ключ продукта. Для КриптоПРО CSP первые 2 символа лицензии соответствуют версии продукта.
Во-вторых, на серверную ОС можно установить только серверную лицензию на ПО, вне зависимости от целей использования.
В-третьих, данная ошибка может возникать из-за отсутствия у пользователя прав локального администратора. Чтобы лицензионный ключ заработал, нужно запустить программу от имени администратора и только тогда устанавливать лицензию.
- Обновили Windows и перестало работать КриптоПРО При обновлении операционной системы обновляются и файлы системного реестра, в которые при установке прописывается криптопровайдер, поэтому после обновления ОС КриптоПРО тоже нужно .
-
Не обновляется ОС Windows 7 ошибка обновления 800b0001
Эта ошибка характерна для КриптоПРО версии 3.6
Если у Вас установлена Версия КриптоПРО 3.6, то попробуйте обновиться до CSP 3.6.7777 R4. Просто устанавливаете новый дистрибутив поверх старого, лицензию заново вводить не нужно, она хранится в реестре. - Как установить лицензию на программу КриптоПРО
- - Запускаем программу КриптоПРО CSP: пуск(или поиск)/все программы/КриптоПРО/КриптоПРО CSP;
- - На вкладке общее находим кнопку "ВВОД ЛИЦЕНЗИИ" нажимаем;
- - В открывшемся окне видим поле "Серийный номер" в него нужно вставить буквенно-цифровой лицензионный ключ. Правая кнопка мыши при этом не работает, нужно воспользоваться сочетанием клавиш "Ctrl+V" на клавиатуре.
-
Срок действия этой версии КриптопПРО CSP истек
Лицензия исткла или не была установлена в программе. Возможно несколько вариантов:
Программа была установлена в тестовом режиме и триальный период закончился;
Истек срок действия годовой лицензии КриптоПРО CSP;
После переустановки/обновления программы лицензионный ключ не был введен.
Если лицензия у Вас уже есть, можно воспользоваться инструкцией выше. Приобрести новую лицензию можно на
- Не удаётся найти сертификат и закрытый ключ для расшифровки
Нужно переустановить личный сертификат. Можно воспользоваться нашей .
Если данная ошибка возникает при подписании документов на web-ресурсах, значит их нужно добавить в доверенные узлы в браузере.
- - запустите “Internet Explorer”;
- - Откройте меню “Сервис” -> пункт “Свойства браузера” -> закладка “Безопасность” -> закладка "Надежные узлы"-> кнопка “добавить”;
- - Добавляем в список адрес сайта, на котором Вы собираетесь подписывать документы.
- Ошибка: указан неверный серийный номер
- КриптоПРО Office Signature
Разработчик: ООО "КРИПТО-ПРО"
- Как установить лицензию на программу Office Signature
Самым простым способом будет установить лицензию при инсталяции программы, но если программа уже установлена и требет ввода лицензии, можно пойти по сложному пути:
- - Запускаем приложение КриптоПРО PKI: пуск(или поиск)/все программы/КриптоПРО/КриптоПРО PKI;
- - В левой части окна, раскрываем список "управление лицензиями" (нужно просто кликнуть по плюсику);
- - Выбираем пункт КриптоПРО Office Signature;
- - В верхнем меню программы выбираем действие/все задачи/ввести серийный номер;
- - Вставляем в открвышееся окно лицензионный ключик и нажимаем ОК.
Подробно об установке программы и лицензии написано в нашей .
- Ошибка: указан неверный серийный номер
Возникновение этой ошибки свидетельствует о некорректном вводе лицензии. Причин может быть несколько:
Во-первых, лицензии между версиями программы не совместимы, поэтому стоит убедиться, что версия установленного дистрибутива совпадает с версией лицензии, которую Вы приобрели. Определить версию можно просто взглянув на лицензионный ключ продукта. Для offiсe signature версии соответствует третий символ лицензии.
Во-вторых, данная ошибка может возникать из-за отсутствия у пользователя прав локального администратора. Чтобы лицензионный ключ заработал, нужно запустить программу от имени администратора и только тогда устанавливать лицензию.
- Как установить лицензию на программу Office Signature
- КриптоПРО PDF
Разработчик: ООО "КРИПТО-ПРО"
- Инструкция по установке и использованию КриптоПРО PDF
- Введен неверный лицензионный ключ
При создании лицензии на приложение КриптоПРО PDF обязательно указывается наименование организации заказчика, при ее установке нужно указать то же наименование организации (регистр и кавычки имеют значение).
Если лицензия была приобретена на физ. лицо, то в поле "Организация" нужно вводить ФИО заказчика.
Одним из важных аспектов безопасности сайта является процедура аннулирования SSL сертификатов и их внесения в списки CRL. Как известно, центры сертификации выписывают SSL сертификаты безопасности только после валидации доменного имени и в некоторых случаях после тщательной проверки компании, которой принадлежит этот домен. Благодаря данной процедуре сертификационный центр может обеспечить достоверность информации в SSL сертификате и соответственно гарантирует безопасность защищенного веб-сайта. Все же иногда случается, что безопасность сайта может оказаться под угрозой даже с действующим SSL сертификатом, например, если специальный ключ доступа был утерян или украден. В таких случаях он должен быть аннулирован (отозван). Аннулированные SSL сертификаты заносятся в специальные списки CRL. Причины аннулирования SSL Существует множество причин для внесения SSL сертификатов в списки CRL до истечения срока их действия. Вот некоторые из них:
- SSL сертификат содержит неверное название компании или другую неверную информацию
- специальный ключ был утерян или скомпрометирован
- сотрудник, имеющий к нему доступ, уволился с места работы
- нарушение политики безопасности
- защищенный сайт больше не работает и т.д.
Статус SSL сертификата
Статус SSL сертификата на предмет его аннулирования проверяется браузером перед каждым установлением безопасного соединения по протоколу https. Существует два типа статусов:- Аннулирован или же отозван . Процедура аннулирования безвозвратна. Если статус гласит «аннулирован», то чтобы снова защитить Ваш сайт необходимо заново купить SSL сертификат .
- Временно недоступен . Если же владелец домена, например, не уверен, потерял ли он ключ, он может использовать второй статус - «временно недоступен» - до установления места нахождения секретного ключа. В таком случае, если он нашелся и не был доступен для третьих лиц, этот статус можно отозвать и SSL снова станет действительным.
CRL или списки САС
Как же пользователи веб-ресурса узнают, что SSL аннулирован и защита сайта нарушена? Как раз для этого существуют списки аннулированных сертификатов (в международном варианте - Certificate Revocation Lists, сокращенно CRL), которые содержат следующие данные:- уникальные серийные номера всех отозванных SSL сертификатов
- название ответственного центра сертификации,
- дату аннулирования,
- актуальную дату,
- дату публикации нового списка CRL.
