- Что такое crl или список аннулированных сертификатов?
- Автоматическая проверка аннулирования
- Автоматический контроль процесса аннулирования сертификатов
- Аннулирование сертификата
- Аннулирование сертификатов в приложениях
- Дополнения сас
- Дополнения точек входа в сас
- Ключевая служба инфраструктуры pki
- Частные дополнения
Что такое crl или список аннулированных сертификатов?
CRL или CAC — списки SSL-сертификатов, отозванных центром выдачи (CA). На 2021 год происходит отказ от использования CRL (САС) в пользу OCSP (Онлайн Протокол Состояния Сертификата).
SSL обеспечивает защищённое HTTPS-соединение с сайтом, но существуют угрозы безопасности даже при действующем сертификате. Самая распространённая – секретный ключ скомпрометирован. Передача данных становится небезопасна. Чтобы номера кредитных карт и пароли пользователей не попали к мошенникам, сертификат нужно отозвать.
Основные причины аннулирования SSL:
- ключ утерян/украден или скомпрометирован
- неверно указано название компании или другие данные
- сайт прекратил работу
- сменился владелец ресурса
- выдавший сертификат Certification Authority скомпрометирован
Как работают списки CRL?
Список аннулированных сертификатов публикует Certificate Authority (CA), выдавший сертификат:
1) Владелец домена или посетитель сайта, заметивший проблему, обращается в CA и просит аннулировать действующий SSL.
2) CA заносит уникальный серийный номер сертификата в список CAC, который:
- защищён цифровой подписью центра — нельзя изменить
- обновляется минимум раз в сутки — всегда актуален
3) Каждый раз при соединении с ресурсом браузер посетителя проверяет, аннулирован ли SSL-сертификат. Смотрит в загруженных списках CRL или по протоколу OCSP — через запрос к CA. Если находит сертификат в списке CRL или получает от CA ответ, что сертификат отозван — показывает предупреждение об ошибке.
Не все браузеры загружают списки CAC и пользуются OCSP
Firefox проверяет статус только для сертификатов с расширенной проверкой EV. Пользователи этого браузера не узнают об отзыве SSL DV и OV. Так же как и мобильные пользователи Safari в iOS. Chrome определяет статус сертификата для Windows, но не для Linux и Android.
Internet Explorer и Opera — самые безопасные в этом отношении браузеры. Они используют OCSP и CRL в зависимости от того, что предлагает CA.
Аннулированный сертификат нельзя восстановить, только купить новый. Берегите секретный ключ — его утеря или компрометация чаще всего приводит к отзыву SSL-сертификата.
Автоматическая проверка аннулирования
В среде PKI для автоматической проверки аннулирования могут применяться различные методики. Большинство из них, за исключением деревьев аннулирования сертификатов и протокола OCSP (Online Certificate Status Protocol), построено на основе использования абсолютных списков CRL, списков лишения полномочий (authority revocation lists)
Как отмечалось выше, инфраструктура PKI среды Windows 2000 поддерживает абсолютные списки и CDP. В Windows 2003 PKI добавлена поддержка списков изменений. Кроме того, в Windows 2003 и Windows 2000 имеется поддержка расширений для Netscape, предназначенных для обработки данных по аннулированным сертификатам.
В индустрии ИT требования к процессу аннулирования зачастую связаны с необходимостью поддержки протокола OCSP. Данный протокол, как определено в документе RFC2560, предоставляет в реальном времени информацию об аннулированных сертификатах всем пользователям инфраструктуры PKI.
Следует отметить, что ни в Windows 2003, ни в Windows 2000 не включена поддержка OCSP; для ее реализации требуются программные решения независимых фирм, таких как Alacris или Valicert (одно из подразделений компании Tumbleweed Communications). «Родной» для среды Windows альтернативой протокола OCSP является использование узлов CDP и списков изменений.
Автоматический контроль процесса аннулирования сертификатов
При разработке инфраструктуры открытых ключей PKI (Public Key Infrastructure) одним из наиболее важных аспектов является процесс аннулирования (revocation) сертификатов, а точнее — автоматический контроль их аннулирования. В процессе аннулирования сертификатов проверяется, внесен ли системой PKI серийный номер соответствующего сертификата (если секретный ключ пользователя был скомпрометирован) в черный список, называемый списком сертификатов, подлежащих аннулированию (Certificate Revocation List, CRL).
Аннулирование сертификата также гарантирует, что информация об этом будет доведена до всех клиентов инфраструктуры PKI и приложений, использующих PKI. Если в системе PKI необходимо обрабатывать конфиденциальную информацию или сведения о транзакциях повышенной важности, пользователь подобной системы должен разбираться в таких вопросах, как процесс аннулирования сертификатов и поддержка проверки аннулирования в приложениях, использующих Windows PKI, а также иметь представление о решениях, обеспечивающих автоматический контроль процесса аннулирования. Начнем со структуры списков CRL.
Аннулирование сертификата
Аннулирование сертификата может выполняться администратором центра Windows CA либо с помощью оснастки Certification Authority, либо через командную строку. Запустив оснастку Certification Authority, следует открыть в ней контейнер Issued Certificates, щелкнуть правой кнопкой на том сертификате, который надлежит аннулировать, после чего выбрать в меню пункт All TasksRevoke Certificate.
certutil revoke
При аннулировании сертификата администратор центра CA может указать код причины (reason code), как показано на экране 4. Допускаются следующие коды причин: Unspecified, Key Compromise, CA Compromise, Change of Affiliation, Superseded, Cease of Operation, и Certificate Hold.
Аннулирование сертификатов в приложениях
Не все ориентированные на использование PKI приложения для Windows выполняют автоматическую проверку аннулирования сертификатов. Кроме того, возможность выполнения данной проверки зависит в ряде случаев от настройки соответствующего приложения. Перечень наиболее распространенных приложений, использующих Windows PKI и поддерживающих механизмы проверки аннулирования сертификатов, приводится в табл. 1.
Для того чтобы включить поддержку проверки аннулирования сертификатов в Secure MIME (S/MIME) приложения Microsoft Outlook 2000 Service Release 1 (SR1), необходимо открыть на клиентском компьютере реестр, найти в нем подраздел HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptography{7801ebd0-cf4b-11d0-851f-0060979387ea}, создать новый параметр с именем PolicyFlags (типа REG_DWORD) и присвоить ему значение 00010000.
Чтобы активизировать поддержку проверки аннулирования сертификатов для IP Security (IPSec) в Windows 2000 Service Pack 2 (SP2), требуется открыть реестр, перейти в подраздел HKEY_LOCAL_MACHINE SYSTEMCurrentControlSetServicesPolicyAgentOakley, создать новый параметр с именем StrongCrlCheck (типа REG_DWORD) и присвоить ему значение 1 или 2. Ниже приводится описание возможных значений данного параметра.
0 — отключает проверку CRL для протокола IPSec, базирующегося на сертификатах.
1 — включает проверку CRL и прерывает процесс проверки подлинности сертификатов в тех случаях, когда в CRL явно указывается, что данный сертификат аннулирован. Клиентская система будет игнорировать все другие сбои, в том числе и те случаи, когда URL CDP ссылается на недоступный узел.
2 — включает проверку CRL и прерывает процесс проверки подлинности сертификатов только при наличии каких-либо ошибок проверки CRL.
Дополнения сас
Стандарт X.509 версии 1997 года [77] ввел в САС несколько дополнений – CRL Extensions. Каждое дополнение САС может быть помечено как критичное или некритичное. ВалидацияСАС становится невозможной, если обнаруживается нераспознанное критичное дополнение.
Однако такое дополнение может быть проигнорировано.
Формат САС X.509 v2 допускает задание частных дополнений, позволяющих указывать специфическую для данного PKI-сообщества информацию.
ДополнениеAuthority Key Identifier (идентификатор ключа издателя САС ) идентифицирует открытый ключ, необходимый для валидации цифровой подписи, которой заверен САС. Идентификация может базироваться либо на идентификаторе ключа (из дополнения Subject Key Identifier сертификата издателя САС ), либо на имени издателя САС и серийном номере его сертификата. В этом дополнении используются следующие поля:
ДополнениеAuthority Key Identifier помогает пользователям выбрать правильный открытый ключ для верификации подписи на данном САС в том случае, когда издательСАС имеет несколько ключей подписи и соответственно несколько сертификатов.
При смене ключа подписи издателя САС происходит некоторое перекрытие периодов действия двух ключей, в этот интервал времени валидными считаются оба сертификата с одним и тем же именем издателя и разными открытыми ключами подписи.
ДополнениеIssuer Alternative Name позволяет указывать альтернативные имена издателя САС: адрес электронной почты, DNS-имя (имя Интернет-хоста)
, IP-адрес и унифицированный идентификатор ресурса URI (обычно уникальный адрес ресурса WWWURL).
Включение этих имен не обязательно. Формально это дополнение может быть как критичным, так и некритичным. Но поскольку документ RFC 3280 требует, чтобы поле с именем издателя САС не было пустым, необходимо, чтобы это дополнение было помечено как некритичное.
ДополнениеCRL Number выполняет функцию счетчика и содержит упорядоченную по возрастанию последовательность номеров всех списков САС, выпущенных данным издателем. Дополнение позволяет пользователям определять, когда происходит смена одного списка данного издателя другим, более свежим САС.
В соответствии с рекомендациями X.509 это дополнение всегда помечается как некритичное. Документ RFC 3280 требует от издателей включения этого дополнения во все списки САС.
ДополнениеCRL Scope формально стандартизовано версией 2000 года рекомендаций X.509 и обеспечивает гибкость классификации информации списков САС по разным признакам. Списки САС могут быть разбиты на множества различными способами: по типам сертификатов, кодам причин аннулирования, серийным номерам, идентификаторам ключей субъектов и поддеревьям имен. Это дополнение всегда помечается как критичное.
ДополнениеStatus Referrals формально стандартизовано версией 2000 года рекомендаций X.509 и обеспечивает две основные функции: во-первых, дает возможность динамически разбивать информацию об аннулировании (поскольку включает в свой синтаксисдополнениеCRL Scope ); во-вторых, позволяет удостоверяющим центрам публиковать перечень текущих списков САС.
Перечень помогает доверяющей стороне анализировать, владеет ли она последней информацией об аннулировании, и избегать лишней (без необходимости) пересылки списков САС. В этом дополнении также может публиковаться информация нового САС, прежде чем произойдет обновление более старого, но не просроченного списка.
Это дополнение всегда помечается как критичное.
ДополнениеCRL Stream Identifier формально стандартизовано версией 2000 года рекомендаций X.509 и используется для идентификации контекста, внутри которого номер САС является уникальным.
Если каждому пункту распространения САС присваивается уникальный идентификатор, то его комбинация с номером САС позволяет, независимо от типа списка, уникально идентифицировать каждый САС, выпущенный данным УЦ. Это дополнение всегда помечается как некритичное.
ДополнениеOrdered List формально стандартизовано версией 2000 года рекомендаций X.509 и характеризует упорядоченность САС по возрастанию серийных номеров или дат аннулирования.
ДополнениеDelta Information формально стандартизовано версией 2000 года рекомендаций X.509 и указывает местонахождение дельта-списка САС и время выпуска следующего дельта-списка (последний атрибут необязателен). Это дополнение всегда помечается как некритичное.
ДополнениеIssuing Distribution Point используется вместе с дополнением сертификата CRL Distribution Point и отражает названия пунктов распространения САС и типы сертификатов, содержащихся в списке (например, сертификаты только конечных пользователей, сертификаты только удостоверяющих центров и/или сертификаты, аннулированные по определенной причине ).
Когда разрешено, дополнение указывает, что САС является косвенным списком. Один издательСАС может поддерживать несколько пунктов распространения САС.
Дополнения точек входа в сас
Международный Союз по телекоммуникациям ввел несколько дополненийточек входа в САС X.509 v2 [78]. Они связывают с точками входа в САС некоторые дополнительные атрибуты.
Каждое дополнение может быть помечено как критичное или некритичное. ВалидацияСАС не может быть выполнена, если встречается нераспознанное критичное дополнение, однако некритичное дополнение может быть проигнорировано. Дополненияточек входа в САС приведены в табл. 8.3.
ДополнениеReason Code указывает причину аннулирования сертификатов. Издателем САС настоятельно рекомендуется включать в это дополнение значащие коды причин. В дополнении могут указываться следующие коды причин:
ДополнениеHold Instruction Code (код команды передачи сертификата на хранение) используется для временного приостановления сертификата. Оно содержит идентификатор зарегистрированной команды, указывающий действие, которое необходимо выполнить, если при обработке транзакции встречается сертификат, который должен быть приостановлен и передан на хранение.
Документ RFC 3280 требует, чтобы поддерживалось несколько кодов команд, в том числе “позвонить издателю” и “отвергнуть сертификат”. Это дополнение всегда помечается как некритичное. Оно имеет очень ограниченное применение, в частности, при выполнении финансовых транзакций.
Например, если пользователь совершает покупку и при оплате предъявляет кассиру смарт-карту, на которой хранится секретный ключ его сертификата, то УЦ, выпустивший этот сертификат, может использовать команду “позвонить издателю”, чтобы заставить кассира связаться с УЦ.
ДополнениеCertificate Issuer позволяет включать в САС информацию о пунктах распространения САС нескольких издателей, то есть поддерживать косвенные списки САС.
Это дополнение идентифицирует издателя сертификата, связанного с определенной точкой входа в косвенный САС. Если дополнение первой точки входа в косвенный САС отсутствует, то по умолчанию издателем сертификата считается издательСАС.
При отсутствии дополнения Certificate Issue последующей точки входа в САС издателем сертификата считается тот же субъект,
который связан с предшествующей точкой входа в САС.
Это дополнение всегда помечается как критичное. Если при валидации сертификата это дополнение игнорируется, то невозможно корректно установить соответствие между сертификатами и точками входа в САС.
ДополнениеInvalidity Date (дата утраты валидности) содержит дату, когда стало известно или ожидается, что секретный ключ скомпрометирован или сертификат по какой-либо причине утратил валидность.
Эта дата может предшествовать дате, указанной для точки входа в САС и являющейся датой, начиная с которой издательСАС выполнял аннулирование.
Дата утраты валидности может предшествовать дате выпуска более ранних списков САС, но дата аннулирования не должна предшествовать дате выпуска этих списков. Дата утраты валидности выражается в обобщенном формате времени или в формате скоординированного универсального времени UTC.
Это дополнение всегда помечается как некритичное. Присутствие этого дополнения не влияет на принятие сертификата, однако информация о дате утраты валидности может использоваться при разрешении споров по поводу отказа субъекта аннулированного сертификата от своего участия в транзакции.
Ключевая служба инфраструктуры pki
Процедура проверки аннулирования является ключевой службой инфраструктуры PKI, поскольку надежный механизм проверки аннулирования сертификатов — это важная часть любой заслуживающей доверия службы PKI. При проектировании среды PKI нужно обязательно уделять внимание процессу аннулирования сертификатов.
Средства, имеющиеся в операционных системах Windows 2003 и Windows 2000, позволят автоматизировать процесс аннулирования сертификатов. Наконец, следует отметить, что появившиеся в инфраструктуре PKI системы Windows 2003 дополнения и расширения механизмов проверки аннулирования существенно повышают удобство использования данных служб.
Частные дополнения
Формат САС X.509 v2 позволяет использовать частные дополнения для поддержки специфической для данного сообщества пользователей информации. В соответствии с рекомендациями X.509 частные дополнения могут задаваться для САС и для точек входа в САС.