Алгоритм проверки пути сертификации

Алгоритм проверки пути сертификации — это алгоритм , который проверяет, что данный путь сертификата действителен в рамках данной инфраструктуры открытых ключей (PKI). Путь начинается с сертификата субъекта и проходит через ряд промежуточных сертификатов до доверенного корневого сертификата , обычно выдаваемого доверенным центром сертификации (CA).

Проверка пути необходима проверяющей стороне для принятия обоснованного решения о доверии при предоставлении любого сертификата, которому еще не присвоено явное доверие. Например, в иерархической PKI цепочка сертификатов, начинающаяся с сертификата веб-сервера, может вести к небольшому ЦС, затем к промежуточному ЦС, а затем к большому ЦС, якорь доверия которого присутствует в веб-браузере проверяющей стороны. В мостовой PKI цепочка сертификатов, начинающаяся с пользователя в компании A, может привести к сертификату CA компании A, затем к мосту CA, затем к сертификату CA компании B, а затем к якорю доверия компании B, который является проверяющей стороной в компании B. мог доверять.

RFC   5280 определяет стандартизированный алгоритм проверки пути для сертификатов X.509 с учетом пути сертификата. (Обнаружение пути, фактическое построение пути, не рассматривается.) Алгоритм принимает следующие входные данные:

• Путь к сертификату, который необходимо оценить;
• Текущая дата/время;
• Список идентификаторов объектов политики сертификатов (OID), приемлемых для проверяющей стороны (или любой другой);
• Доверительная привязка пути сертификата; и
• «любой» OID политики. Индикаторы того, разрешено ли сопоставление политик и как/когда/должен ли быть допущен

В стандартизированном алгоритме для каждого сертификата в пути, начиная с якоря доверия, выполняются следующие шаги. Если какая-либо проверка какого-либо сертификата завершается неудачей, алгоритм завершает работу и проверка пути завершается неудачно. (Это пояснительное изложение объема алгоритма, а не строгое воспроизведение подробных шагов.)

• Проверяются алгоритм и параметры открытого ключа;
• Текущая дата/время сверяется со сроком действия сертификата;
• Статус отзыва проверяется с помощью CRL , OCSP или какого-либо другого механизма, чтобы гарантировать, что сертификат не отозван;
• Имя издателя проверяется, чтобы убедиться, что оно соответствует имени субъекта предыдущего сертификата в пути;
• Проверяются ограничения имени, чтобы убедиться, что имя субъекта находится в списке разрешенных поддеревьев всех предыдущих сертификатов CA, а не в списке исключенных поддеревьев любого предыдущего сертификата CA;
• Заявленные политики сертификата OID проверяются по допустимым OID предыдущего сертификата, включая любые эквиваленты сопоставления политик, заявленные предыдущим сертификатом;
• Ограничения политики и базовые ограничения проверяются, чтобы гарантировать, что какие-либо явные требования политики не нарушены и что сертификат является сертификатом CA соответственно. Этот шаг имеет решающее значение для предотвращения атак «человека посередине» ;
• Длина пути проверяется, чтобы убедиться, что она не превышает максимальную длину пути, указанную в этом или предыдущем сертификате;
• Расширение использования ключа проверяется, чтобы убедиться, что разрешено подписывать сертификаты; и
• Любые другие критические расширения распознаются и обрабатываются.

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

См. также

• Делегированное обнаружение пути
• Проверка делегированного пути