SSL - установить доверенный корневой сертификат в контейнер док-станции aspnetcore - PullRequest
0 голосов
/ 19 сентября 2018

Я пытаюсь установить доверенный самоподписанный корневой сертификат на образ докера microsoft / aspnetcore.

Я следовал следующим темам,

Доверенные корневые сертификаты в DotNet Core в Linux(RHEL 7.1)

Установить сертификат в базовый контейнер док-станции dotnet

Это не сработало для меня.здесь вывод сборки docker,

Шаг 10/24: COPY corppvt_root_cert.cer /usr/local/share/ca-certificates/corppvt_root_cert.cer ---> af1674a5219c

Шаг 11/24: COPY CCASRootCert.cer /usr/local/share/ca-certificates/CCASRootCert.cer ---> a2d6affc1ae1

Шаг 12/24: RUN update-ca-сертификаты ---> Запускв ca6fb1b9aa50 Обновление сертификатов в / etc / ssl / certs ... 0 добавлено, 0 удалено;сделанный.Запуск хуков в /etc/ca-certificates/update.d ... готово.При удалении промежуточного контейнера ca6fb1b9aa50

из выходных данных команды RUN update-ca-Certificates создается впечатление, что он не может идентифицировать / хранить новые скопированные сертификаты, поскольку в выводе указано 0 добавлено, 0 удалено.

Я использую образ Microsoft / Aspnetcore.который я считаю образ на основе Ubuntu / Debian.поэтому местоположение сертификата должно быть / usr / local / share / ca-Certificates /

Может кто-нибудь посоветовать, что не так с этими командами и почему хранилище сертификатов не обновляется?Кто-нибудь использовал это изображение раньше и делал этот материал ssl?

Заранее спасибо!

Ответы [ 2 ]

0 голосов
/ 17 августа 2019

Ваш сертификат не устанавливается / обновляется, потому что update-ca-Certificates будет выбирать только .crt, а не .cer.

Просто переименуйте расширение и попробуйте снова.

0 голосов
/ 19 сентября 2018

Во-первых, вам не нужно помещать сертификаты в ваш контейнер.При использовании ASP.NET Core в Docker-контейнерах типичный вариант использования - настроить его на использование обратного прокси-сервера (такого как nginx, IIS и т. Д.) Как будто (сервер, обращенный к Интернету), который принимает запрос извне и действует как конечная точка завершения SSL кака также балансировщик нагрузки.

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

Обратный прокси-сервердолжен отправлять X-Forwarded-* заголовки, которые сообщают приложению, был ли этот запрос подключен с использованием SSL (заголовок X-Forwarded-Proto), для которого он был перенаправлен (X-Forarded-For, IP-адрес запрашивающего лица) может быть другим обратным прокси или ip конечного пользователя) и т. д.

Ядро ASP.NET распознает эти заголовки и не будет обрабатывать их так, как если бы это был запрос HTTPS (даже если соединение обратного прокси-сервера с приложением не зашифровано).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...