Назад | Перейти на главную страницу

AWS ALB / NLB HTTPS Target с самоподписанным сертификатом

Я использую AWS для создания сервиса. Для этой услуги я хочу использовать сертификаты ACM. Бэкэнд работает на экземпляре EC2 с включенным TLS с использованием самозаверяющего сертификата. Поскольку сертификаты ACM нельзя экспортировать, я хочу поставить балансировщик нагрузки перед серверной частью, который будет обслуживать действительный сертификат.

Мои предположения:

Даже при этом у меня все еще возникают ошибки.

Мой текущий статус:

Экземпляр EC2 доступен через порт 443 и сообщает о самоподписанном сертификате (как и ожидалось). Экземпляр EC2 доступен через порт 80 для проверки работоспособности.

Я создал ALB с целевой группой https с моим экземпляром в качестве цели. ALB доступен через браузер и отображает мой действующий сертификат, но отвечает 502.

Если вместо этого я использую целевую группу http и запрашиваю конечную точку проверки работоспособности, я верну 200. В целях тестирования я также использую очень слабую группу безопасности для экземпляра, а также для ALB.

Вот что я вижу в журналах ALB (каждая строка почти такая же, за исключением времени):

https 2020-06-05T09:39:26.715673Z app/testTLSAlb/660e809a22b5d7d2 10.95.21.6:65521 10.95.16.197:443 -1 -1 -1 502 - 240 293 "GET https://my.domain.com:443/adfs/.well-known/openid-configuration HTTP/1.1" "PostmanRuntime/7.25.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 arn:aws:elasticloadbalancing:eu-central-1:accountid:targetgroup/testhttpsTargetGroup/f1e8ce633e9ab069 "Root=1-5eda12ce-aabdb29ae55998867511a310" "my.domain.com" "arn:aws:acm:eu-central-1:accountid:certificate/d9a964b0-6d96-4eeb-b126-2b87f1350942" 0 2020-06-05T09:39:26.714000Z "forward" "-" "-" "10.95.16.197:443" "-"

URL-адрес доступен, если я подключаюсь к цели напрямую. Как вы могли заметить, это сервер ADFS, который, похоже, не поддерживает реальное ведение журнала.

Я записал прямой запрос и запрос от ALB с помощью wirehark. Прямой запрос дает ответ, запрос от ALB получает сброс TCP после приветствия клиента TLS:

Насколько я мог видеть, шифры должны быть совместимыми (успешный запрос использует шифр, который также предлагает ALB). Единственные существенные различия - это отправляемые расширения TLS (слева - ALB, справа - Postman).

Отсутствие поля SNI, похоже, является проблемой, поскольку это требование для ADFS (https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-requirements)

В этом случае проблема заключалась в том, что ADFS (приложение, которое я хотел запустить за балансировщиком нагрузки) отвечает только на соединения TLS, использующие SNI. Поскольку ALB этого не делает, сервер ADFS ответил сбросом TCP. Для ADFS решением было добавить привязку сертификата по умолчанию, выполнив следующие действия:

netsh http add sslcert ipport=0.0.0.0:443 certhash=certthumprint appid="{applicationguid}"

Это позволяет серверу отвечать, даже если в запросе нет SNI.