Как правильно развернуть удостоверяющий центр? Доброго времени суток! Товарищи специалисты, подскажите пожалуйста как правильно организовать удостоверяющий центр в рамках компании.
Вопрос технического характера:
Допустим я хочу организовать следующую структуру удостоверяющих центров:CompanyName Root CA - Корневой УДCompanyName Project 1 CA - УД Проекта 1codesignCompanyName Project 2 CA - УД Проекта 2client, serverCompanyName Security CA - УД например для VPNclient, 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 гласит что это просто фенечка - забавы ради. Есть какой ни будь более глубокий смысл добавления логотипа в сертификат на практике?
Спасибо.
Как правильно развернуть удостоверяющий центр? Доброго времени суток! Товарищи специалисты, подскажите пожалуйста как правильно организовать удостоверяющий центр в рамках компании.
Вопрос технического характера:
Допустим я хочу организовать следующую структуру удостоверяющих центров:CompanyName Root CA - Корневой УДCompanyName Project 1 CA - УД Проекта 1codesignCompanyName Project 2 CA - УД Проекта 2client, serverCompanyName Security CA - УД например для VPNclient, 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 гласит что это просто фенечка - забавы ради. Есть какой ни будь более глубокий смысл добавления логотипа в сертификат на практике?
Спасибо.
Вопрос технического характера:
Допустим я хочу организовать следующую структуру удостоверяющих центров:CompanyName Root CA - Корневой УДCompanyName Project 1 CA - УД Проекта 1codesignCompanyName Project 2 CA - УД Проекта 2client, serverCompanyName Security CA - УД например для VPNclient, 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 гласит что это просто фенечка - забавы ради. Есть какой ни будь более глубокий смысл добавления логотипа в сертификат на практике?
Спасибо.
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
Добрый день! Давайте разберемся с вашими вопросами по порядку:
Должен ли корневой сертификат (CompanyName Root CA) иметь ссылки на CRL и OCSP?
Да, рекомендуется, чтобы корневой сертификат имел ссылки на CRL (Certificate Revocation List) и OCSP (Online Certificate Status Protocol), чтобы была возможность проверять статусы отозванных сертификатов. Это обеспечит безопасность и обновление сертификатов в вашей иерархии.
Если ссылка указываться, что будет храниться на этих адресах, информация об отозванных сертификатах УД?
На ссылках на CRL и OCSP должны храниться списки отозванных сертификатов и их статусы, чтобы клиенты и серверы могли проверять их и обеспечивать безопасную связь.
Можно ли отозвать сертификат дочернего УД?
Да, можно отозвать сертификат дочернего УД. В случае необходимости, корневой УД может отозвать сертификат дочернего УД из соображений безопасности.
Относительно схемы с созданием отдельного ROOT CA для каждого проекта - это может быть хорошим решением, если вы хотите уменьшить риск пересечения доступа между различными проектами. Такой подход действительно может повысить безопасность вашей сети и предотвратить возможные атаки через утечку сертификатов.
Добавление логотипа в сертификат, хотя и может показаться интересным или декоративным элементом, обычно не несет никакой дополнительной функциональности. Однако, в некоторых случаях это может быть использовано для психологического воздействия на конечного пользователя или для улучшения узнаваемости вашей компании.
Надеюсь, что мои ответы были полезными для вас. Если у вас есть еще какие-либо вопросы, не стесняйтесь обращаться!