Должен ли я использовать отдельные корневые центры сертификации для сертификатов внутреннего сервера, сертификатов внешних клиентов и сертификатов HTTPS?
Должен ли я иметь 3 корневых центра сертификации, 1 корневой центр сертификации + 3 промежуточных звена или другую настройку PKI для в следующей ситуации?
У меня есть три варианта использования:
- Открыть веб-API через HTTPS (сертификаты сервера)
- Разрешить клиентам аутентифицироваться с помощью сертификата клиента вместо имени пользователя / пароля (внешние сертификаты клиентов)
- Подтверждение внутренних серверов как клиентов (внутренние сертификаты клиентов)
Каждая пара ключей будет использоваться только для одного из вариантов использования.
Предположим, мне не нужен сторонний центр сертификации, и вместо этого я работаю с настраиваемой PKI в закрытой системе. Я вижу два основных способа поддержки этого:
- 1 корневой ЦС с 3 промежуточными ЦС (по одному промежуточному для каждого случая)
- 3 корневых ЦС (по одному корневому ЦС для каждого варианта использования)
Я попытался запустить # 1, но я обнаружил, что для тестирования сертификатов клиентов openssl s_client на HTTPS-сервере node.js мне необходимо выполнить проверку от промежуточного уровня к корневому, а не только к промежуточному. Это означает, что клиентские сертификаты между вариантами использования 2 и 3 можно менять местами, поскольку корень является якорем доверия. Я осмотрелся, но не могу найти способ сделать промежуточный ЦС якорем доверия для HTTPS-сервера node.js.
Итак, я что-то сильно неправильно понимаю, мне нужно перейти к реализации №2 или к смеси вещей.
Сертификаты X.509 могут обеспечивать конфиденциальность и аутентификацию. То есть их можно использовать для шифрования ссылки и, необязательно, для аутентификации пользователя или сервера.
Они не обеспечивают авторизацию. Вместо этого это зависит от приложения, которое определяет, разрешен ли объекту, аутентифицированному с помощью сертификата X.509, доступ к ресурсам.
Это означает, что (1) выше в порядке. Используйте один корень и убедитесь, что авторизация выполняется другим способом.
Однако, если вы настаиваете на том, чтобы сертификаты X.509 также обеспечивали авторизацию, вам потребуется либо:
- Полагаться на политики сертификатов, чтобы гарантировать, что приложения доверяют только определенным сертификатам - удачи с этим, так как вам, вероятно, потребуется кодировать свои собственные приложения, проверяющие политики;
- Используйте разные корневые сертификаты для каждого приложения; как в (2) выше.