Как правильно развернуть удостоверяющий центр?

Question

[Григорий]

Доброго времени суток! Товарищи специалисты, подскажите пожалуйста как правильно организовать удостоверяющий центр в рамках компании.

Вопрос технического характера:
Допустим я хочу организовать следующую структуру удостоверяющих центров:

• CompanyName Root CA - Корневой УД
  • CompanyName Project 1 CA - УД Проекта 1
    • codesign
    
    
  • CompanyName Project 2 CA - УД Проекта 2
    • client, server
    
    
  • CompanyName Security CA - УД например для VPN
    • client, server
      
    
    
  
  

Корневой УД существует только для создания дочерних УД.
1. Должен ли корневой сертификат (CompanyName Root CA) иметь ссылки на crl и ocsp?
Просмотрел кучу корневых сертификатов разных корпораций, и только у нескольких есть указание ссылки и/или на crl и ocsp. Собственно вытекает вопрос:
2. Если ссылка указываться, что будет храниться на этих адресах, информация об отозванных сертификатах УД?
3. Можно ли отозвать сертификат дочернего УД?

Со ссылками на crl и ocsp в дочерних УД все понятно, там ссылки нужны для быстрого отзыва клиентских и серверных сертификатов.

Вопрос идеологического характера:
CompanyName Project 2 CA - УД Проекта 2 занимается тем что:
1. Выдает клиентские сертификаты - клиентам
2. Выдает серверные сертификаты - серверам
Клиент имеющий ключ, получает доступ к серверу - все как всегда.
Ключ клиента, понятно, подписан CompanyName Project 2 CA, а тот в свою очередь CompanyName Root CA.

CompanyName Security CA - УД например для VPN замается тем что:
1. Выдает клиентские сертификаты - сотрудникам
2. Выдает серверные сертификаты - vpn серверам
Сотрудник имеющий ключ, получает доступ к vpn серверу - все как всегда.
Ключ сотрудника, подписан CompanyName Security CA, а тот в свою очередь CompanyName Root CA.

Может ли случится такое в дикой природе, что хитрый админ у которого есть доступ только к CompanyName Security CA, создаст сертификат и продаст его клиенту, который по нему сможет получить доступ к CompanyName Project 2 CA?

На эту тему, у нас с коллегой вышел спор. Он утверждает, что может. Если вдруг программист реализует неправильную проверку внутри продукта, при проверке цепочки сертификатов, функция может вернуть положительное значение, опустив тот факт что промежуточный УД не тот. Он предлагает для каждого проекта создавать свой ROOT CA и не подписывать их общим ключом компании.

Собственно, хотелось бы увидеть мнение на этот счет, на сколько реальна такая схема.

В ходе изучения материала, наткнулся на пару сертификатов со встроенным логотипом компании.
У меня даже получилось добавить свой логотип в сертификат, но RFC3709 гласит что это просто фенечка - забавы ради. Есть какой ни будь более глубокий смысл добавления логотипа в сертификат на практике?

Спасибо.

Answer 1

[Роман]

Должен ли корневой сертификат (CompanyName Root CA) иметь ссылки на crl и ocsp?
Ответ: Корневой самоподписанный сертификат не должен содержать ссылок на crl и ocsp

А вот что касается любого (ну почти любого) подчиненного сертификата - в нем д.б. ссылка на crl. Ссылка на ocsp - опционально, по Вашему желанию или требованию информационной системы (ИС).
Соответственно, как в сертификатах подчиненных УЦ (Проекта 1, Проекта 2, VPN и т.д.) обязательно должна быть ссылка на crl. Уже не говоря о клиентских сертификатах, выпущенных УЦами Проекта 1, Проекта 2, VPN и т.д.

Ссылка на crl в сертификатах УЦов Проекта 1, Проекта 2, VPN и т.д. будет одна и та же и будет содержать список отзыва, выпускаемый Корневым УЦ. С помощтю этого СОС можно управлять сер-тами подчиненных УЦ.

В сер-тах, выпускаемых УЦами Проекта 1, Проекта 2, VPN и т.д. будет содержаться ссылка на crl, соответствующий каждый определенному УЦ и управлять отзывом сер-тов клиентов можно с каждого подчиненного УЦ, на котором сер-т этого клиента был выпущен.

Не совсем понятно, что означает фраза "получить доступ к CompanyName Project 2 CA по сер-ту, выпущенному на УЦ CompanyName Security CA".
Судя по всему ответ "нет" - получить доступ к CompanyName Project 2 CA по сер-ту, выпущенному из под CompanyName Security CA, не получится.

Что же касается ИС, в которых используются сертификаты, то реализация функции доверия этой ИС к сер-ту целиком и полностью ложится на плечи разработчика ИС и ее архитектуры.
Самый простой способ ограничить использование сер-тов выпущенных только CompanyName Project 2 CA - это установить корневой сер-т CompanyName Project 2 CA в систему и проверять эту цепочку. При этом сер-т CompanyName Security CA в ИС должен отсутствовать

Comments

[Григорий]

Laroux спасибо Вам большое за ответ! Более профессионального ответа, я и ожидать не мог. Теперь все встало на свои места.
Я забыл от том факте, что реквесты от дочерних УЦ подписываются Корневым УЦ и собственно Корневой УЦ устанавливает свои ссылки на crl и ocsp а не на оборот.

Что касается второй части вопроса. Сейчас есть один УЦ который выдает "клиентские лицензии", то есть просто клиентские сертификаты. Есть программа для Windows, при установке она добавляет в хранилище арма сертификат УЦ. Далее клиент получает файл лицензии (p12), скармливает его программе - программа проверяя подпись ключа активирует программу. (В программе хардкодом вшита хэш сумма сертификата УЦ. Таким образом мы "как-бы" удостоверились что сертификат УЦ по которому происходит проверка наш.) Далее программа обращается к https серверу на котором включена проверка клиентских сертификатов и прикладывает свою клинтскую лицензию. Если проверка прошла успешно, сервер отдает некий контент для арма.

Теперь если переделать схему, на ту что я описал выше, получается что сертификат УЦ становится бандлом который будет содержать как CompanyName Project 2 CA так и Company Name Root CA и проверка лицензии будет происходить по нему.

Соответственно, было интересно, что будет если программе скормить сертификат выданный CompanyName Security CA (который так же в свою очередь подписан Company Name Root CA). Можно ли как то обойти проверку, допустив тот факт что админ выдал клинту сертификат выпущенный CompanyName Security CA а клиент установил в систему бандл CompanyName Security CA.

P.S. Как вариант, была идея добавлять в лицензии выдаваемые CompanyName Project 2 CA в качестве дополнительно oid некую хэш сумму (скажем serial_number + secret).
Но я не вижу в этом большого смыла т.к. секрет будет в любом случае вшит в программу а со стороны сервера придется пробрасывать параметры dn до движка и делать проверку программно. Не красиво как-то получается.

[Роман]

Григорий: не мудрите. Вы сами себе голову заморачиваете.

Все очень просто: чтобы сертификаты другого УЦ не принимались некой ИС (пусть в том исполнении, которое Вы описали) обязательно надо куда-то "зашить" параметры промежуточного корневого, которому "можно" выпускать сер-ты для этой ИС. Без вариантов.
Т.е. надо разделить проверка на 2 части:
1) проверка цепочки сер-тов - тут юзаются все сер-ты цепочки и все СОСы
2) проверка клиентского сер-та путем проверки сер-та над ним (промежуточного) между корневым и клиентским. В клиентском сер-те есть данные издателя (данные промежуточного УЦ) и вот по нему и надо отсеивать "неверных"

[Григорий]

Роман: Спасибо! Я как раз предлагаю сделать, как вы написали, это коллеги мои перестраховщики)

На сколько я понял, Вы имеете самое непосредственное отношение Удостоверяющему Центру. Не подскажете, какой софт лучше использовать в качестве ocsp responder?

[Роман]

Григорий: по зарубежным продуктам не подскажу.
Работаю только с российскими средствами