Цепи сертификатов, управление ключами и центры сертификации...
Вы когда-нибудь задумывались, почему у вашего сертификата веб-сервера есть «цепочка» других сертификатов,
связанных с ним? Основная причина заключается в том, что браузеры могут определить, был ли ваш сертификат выпущен организацией, которая была проверена для обеспечения безопасности, политики и методов работы, которым доверяют все публично доверенные центры сертификации. Этот сертификат в верхней части цепочки обычно называется «root». Подпись под сертификатом ниже указывает, что организация, управляющая корнем, полагает, что практика CA ниже нее соответствует той же самой высокой панели.
Но почему не выдавать сертификаты непосредственно из «root»? Есть несколько причин; основная задача -
предотвратить компромисс. Чтобы лучше понять, полезно знать, что секретные ключи, связанные с «root», хранятся в
автономном криптографическом устройстве, расположенном в сейфе, который находится в хранилище в физически
защищенном объекте.
Эти ключи только периодически достаются, чтобы гарантировать, что соответствующее криптографическое устройство все
еще функционирует, для выдачи любых соответствующих эксплуатационных сертификатов (например, сертификата ответчика OCSP),
которые могут потребоваться, и для подписания новых списков отзыва сертификатов (CRL).
Это означает, что для злоумышленника для доступа к этим ключам им необходимо будет получить физический доступ к
этому криптографическому устройству, а также криптографические жетоны и соответствующие секреты, которые используются
для аутентификации устройства.
CA делают это, потому что хранение ключей в автономном режиме - отличный способ снизить риск скомпрометированного ключа,
но это плохой способ предложить высокодоступную и эффективную услугу, поэтому была внедрена концепция выдающего CA (ICA).
Эта концепция также позволила «root» ответить на ключевые события компрометации CA, отменив сертификат ЦС,
которому больше не нужно доверять. Это также позволяет делегировать контроль, ограничивая тех, кто может влиять на данный ICA,
чтобы что-то подписать.
Другой способ решения CA проблемы «онлайн-CA» заключается в том, чтобы использовать то, что обычно называют центром
сертификации политик (PCA). Эта модель позволяет ЦС сегментировать операционную практику более подробно.
Например, возможно, ЦС проверяется на соответствие определенному набору государственных стандартов, поэтому ICAs,
связанные с этими практиками, будут подписаны соответствующим PCA. Это не только позволяет сегментировать политику и
процедуры, но также позволяет разделять сценарии использования. Например, один PCA может разрешать выдачу
сертификатов для защищенной почты, в то время как другой PCA может разрешить выдачу сертификатов SSL.
Эти PCAs также очень часто работают как автономные субъекты и имеют под ними ICAs.
Хотя приведенные выше две модели представляют собой наиболее распространенные способы секционирования с
открытым ключом (PKI), они не являются единственными двумя. Например, операционная практика, требуемая для
централизованного доверительного управления ЦС, гораздо более строгая, чем то, что может использовать типичный центр
обработки данных. По этой причине для ЦС очень важно управлять PKI для других организаций на своих объектах.
ЦС могут также «откатывать» ICA в качестве средства для управления размером CRL. Например, если данному ЦС пришлось
отменить много сертификатов в течение своей жизни, он может решить управлять размером списков отзыва сертификатов -
было бы целесообразно создать новый ICA и удалить предыдущий из службы, чтобы будущие CRL могли по-прежнему
быстро загружаться клиентами. Когда это происходит, оба сертификата CA могут быть действительны для перекрывающегося
времени, но активно используется только более недавний.
Некоторые считают, что количество центров сертификации, существующих в Интернете, может обманывать.
Один из самых простых способов увидеть это -
DV  OV EV WC SAN PRO CodeSign Email PDF Wi-Fi
IoT
ALL
 Купить сертификат
| 
