Следует ли использовать отдельные корневые центры сертификации для внутренних сертификатов сервера, внешних клиентских сертификатов и сертификатов HTTPS?

Следует ли использовать отдельные корневые центры сертификации для внутренних сертификатов сервера, внешних клиентских сертификатов и сертификатов HTTPS?

Следует ли мне иметь 3 корневых центра сертификации, 1 корневой центр сертификации + 3 промежуточных центра или какую-то другую настройку PKI для следующей ситуации?

У меня есть три варианта использования:

  1. Предоставление веб-API через HTTPS (сертификаты сервера)
  2. Разрешить клиентам аутентификацию с использованием клиентского сертификата вместо имени пользователя/пароля (внешние клиентские сертификаты)
  3. Проверка внутренних серверов как клиентов (внутренние клиентские сертификаты)

Каждая пара ключей будет использоваться только для одного варианта использования.

Предположим, мне не нужен сторонний CA, и вместо этого я работаю с пользовательским PKI в закрытой системе. Я вижу два основных способа поддержки этого:

  1. 1 корневой CA с 3 промежуточными CA (по одному промежуточному для каждого случая)
  2. 3 корневых центра сертификации (по одному корневому центру для каждого варианта использования)

Я попытался начать #1, но обнаружил, что для того, чтобы иметь openssl s_clientтестовые клиентские сертификаты для HTTPS-сервера node.js, мне нужно выполнить проверку от промежуточного до корневого, а не только промежуточного. Это означает, что клиентские сертификаты между вариантами использования 2 и 3 могут быть взаимозаменяемыми, поскольку корневой является якорем доверия. Я поискал, но не могу найти способ сделать промежуточный CA якорем доверия для HTTPS-сервера node.js.

Итак, я что-то совершенно не понимаю, мне нужно перейти к реализации №2 или к сочетанию того и другого.

решение1

Сертификаты X.509 могут обеспечить конфиденциальность и аутентификацию. То есть, они могут использоваться при шифровании ссылки и, опционально, для аутентификации пользователя или сервера.

Они не предоставляют авторизацию. Вместо этого приложение должно решить, разрешено ли субъекту, прошедшему аутентификацию с помощью сертификата X.509, получать доступ к ресурсам.

Это значит, что (1) выше в порядке. Используйте один root и убедитесь, что авторизация осуществляется другими способами.

Однако если вы настаиваете на том, чтобы сертификаты X.509 также обеспечивали авторизацию, вам необходимо либо:

  • Используйте политики сертификатов, чтобы гарантировать, что приложения доверяют только определенным сертификатам. Желаем вам удачи в этом деле, поскольку вам, вероятно, придется писать собственные приложения, проверяющие политики.
  • Используйте отдельный корневой сертификат для каждого приложения, как в пункте (2) выше.

Связанный контент