Боюсь, на этот вопрос нет простого ответа да/нет.
Если Kestrel и Apache работают на одном и том же компьютере, вы фактически используете сертификат только потому, что Kestrel ожидает его. Он не обеспечивает безопасности и Это более безопасно? вопрос не актуален.
Если Kestrel и Apache находятся на разных компьютерах, это немного сложнее. Если два ящика находятся в доверенной сети, вы можете рассуждать так же, как и выше, — сертификаты есть только потому, что Kestrel ожидает их.
Если сеть не является доверенной, вам теперь потребуется некоторая безопасность. Сертификат предоставляет удостоверение компьютера, необходимое для инициирования подключения TLS. Независимо от того, используете ли вы для этого самозаверяющий сертификат или сертификат, подписанный ЦС, вы получаете больше возможностей.
- Если приложение Kestrel использует внутреннее полное доменное имя (например,
app.local) и центр сертификации не желает сертифицировать такие имена (например, коммерческий центр сертификации не будет этого делать), то вы вынуждены использовать самозаверяющие сертификаты.
- Если ЦС является внутренним и готов сертифицировать локальные имена, вы можете рассмотреть возможность использования ЦС для сертификата Kestrel.
Итак, предполагая на данный момент, что вы можете использовать сертификат ЦС для Kestrel, вам нужно спросить себя, зачем вам это нужно:
Сертификат, подписанный ЦС, обычно становится полезным в сценарии «один ко многим». Если у вас есть один сервер и много доверяющих сторон (клиентов), сертификат, выданный ЦС, гарантирует:
- доверяющим сторонам нужно доверять только ЦС, и каждый выданный сертификат является неявно доверенным (все клиенты должны доверять самозаверяющему сертификату);
- доверяющим сторонам не нужно проверять процессы управления и операционные процессы каждого сервера, которому они хотят доверять, поскольку они могут предположить, что если ЦС сертифицировал его, то он заслуживает доверия;
- все работает после переоформления сертификата (по сравнению с самоподписанным, который нужно было бы раздавать на все клиенты после обновления);
- отзыв работает (нет понятия отзыва для самозаверяющих сертификатов - если сертификат сервера скомпрометирован, вы должны удалить сертификат из все клиенты);
Однако, если вы находитесь в сценарии «один к одному» (например, между обратным прокси-сервером и сервером приложений), то ЦС дает меньше преимуществ (принятие решений о доверии проще, продление легко, и если сервер скомпрометирован, вы просто удаляете сертификат от одного клиента). На самом деле, если у вас нет доступного ЦС, накладные расходы на создание и управление ЦС только для соединения между сервером приложений и обратным прокси-сервером настолько велики, что делать это нецелесообразно.
Для последнего единственным недостатком использования самозаверяющего сертификата может быть отсутствие централизованного управления. Многие ЦС помогают управлять жизненным циклом выданных сертификатов, даже если это просто автоматическое электронное письмо с напоминанием о том, что срок действия сертификата истекает, или такое сложное, как автоматическое продление. Самоподписанный сертификат управляется вами. Чтобы смягчить это, некоторые организации используют инструменты управления жизненным циклом сертификатов для управления своими сертификатами, и если инструмент также может отслеживать самозаверяющий сертификат, то это решает эту проблему.
Итак, подведем итог: если ваш ЦС предоставляет дополнительную службу управления жизненным циклом, которая помогает вам управлять сертификатом, возможно, стоит подумать об этом; но в противном случае, в индивидуальном сценарии, таком как между сервером приложений и обратным прокси-сервером, на самом деле не имеет значения, используете ли вы самозаверяющий сертификат или сертификат, подписанный центром сертификации.
Если вы пойдете по пути сертификата, выданного ЦС для сервера приложений, у вас будет больше решений:
Если приложение и обратный прокси-сервер находятся в одном и том же поле, вы можете смело использовать один сертификат между ними — маловероятно, что вы окажетесь в ситуации, когда одна служба скомпрометирована, а другой остается доверенным. Вы бы (должны) предположить, что все сертификаты на коробке скомпрометированы, если один из них скомпрометирован, поэтому, как правило, нет никакой реальной пользы в отдельных сертификатах.
Если приложения находятся в разных ящиках, вы можете оказаться в ситуации, когда одно скомпрометировано, а другое — нет. При подготовке к таким случаям у вас должен быть отдельный сертификат на каждую коробку.
Обратите внимание, что, хотя выше обсуждается связь между сервером приложений и обратным прокси-сервером, вы можете попробовать то же самое с Идентификационный сервер 4 (что бы это ни было).
