Правильный SSL-сертификат на правом уровне - PullRequest
0 голосов
/ 22 марта 2019

У меня есть веб-приложение, которое требует довольно строгой безопасности.У меня уже есть достаточно безопасный стек решений, включая Cloudflare, HAProxy и Modsecurity.Я близок к тому, чтобы подготовить свою среду Dev к тестированию, прежде чем создавать свои среды Staging и Production.

Я стремился использовать SSL-сертификат Cloudflare Origin на своем балансировщике нагрузки и веб-сервере, но явозникла проблема.

Я стремился получить полную (строгую) криптографию через Cloudflare, что означает, что Cloudflare будет проверять сертификат при каждом запросе.Поэтому я хотел использовать сертификат источника Cloudflare для того, чтобы, но похоже, что я мог использовать сертификат источника Cloudflare на своем балансировщике нагрузки только потому, что он предназначен только для потока данных Cloudflare to Origin, что позволило бы мне купить сертификат в CAдля моего веб-сервера (ов).

Это три сертификата SSL для покрытия трех точек завершения SSL:

End User      --> Cloudflare (via Dedicated cert)
Cloudflare    --> Load Balancer
Load Balancer --> Web Server

Я попытался установить сертификат Origin на веб-сервере, но не смог подтвердитьдействительность этого сертификата.Я даже обновил OpenSSL до последней стабильной версии (v1.1.1b), чтобы обеспечить подготовку к TLS 1.3.

Так что я могу думать только о двух возможных подходах:

End User      --> Cloudflare (via Dedicated cert)
Cloudflare    --> Load Balancer (via Cloudflare Origin cert)
Load Balancer --> Web Server (via DigiCert cert)

или

End User      --> Cloudflare (via Dedicated cert)
Cloudflare    --> Load Balancer (via Digicert cert)
Load Balancer --> Web Server (via Digicert cert)

Буду признателен всем, кто выделит, если я что-то упустил.

1 Ответ

1 голос
/ 22 марта 2019

Сертификаты обычно содержат DNS веб-сервера в качестве «общего имени». Вы должны сделать вещи совместимыми с этим; это действительно означает либо установку дополнительной точки доверия на ваш балансировщик нагрузки, либо получение «настоящего» сертификата.

Как правило, ваши конечные точки могут использовать один сертификат для идентификации себя. Проблема заключается в том, что в настоящее время вы используете сертификаты, для которых в различных конечных точках невозможно построить цепочку доверия . Конечно, вы можете решить эту проблему, купив сертификат, для которого можно построить цепочку * (например, в коммерческом центре сертификации). Однако, как правило, вы также можете обновить хранилище доверия, добавив в него дополнительные сертификаты, чтобы можно было построить цепочку доверия. В этом случае вы можете использовать свои собственные сертификаты; В конце концов, это ваша инфраструктура.

То, что вы не хотите делать, это использовать листовые сертификаты на нескольких машинах, поскольку это будет означать, что вы копируете закрытый ключ на большее количество машин. Безопасность машин должна быть отдельной, поэтому, если вы начнете копировать файлы PKCS # 12, вам может понадобиться переосмыслить свое решение key management (и если у вас нет явного решения KM, тогда это будет нужное время).

...