SSL-сертификат AWS с Elastic Beanstalk: сайт HTTPS недоступен

Question

Когда я связываю сертификат AWS с моим приложением Elastic Beanstalk и посещаю домен с помощью https, я получаю сообщение "Этот сайт недоступен, mydomain.com отказался подключиться". Я могу зайти на сайт по http.

Я создал сертификат безопасности с помощью AWS ACM. Я добавил свое доменное имя example.com вместе с дополнительными именами, которые были поддоменами к сертификату. В разделе "Балансировка нагрузки" среды моего приложения я настроил это:

Я устанавливаю группу безопасности с именем awseb-e-abc123-stack-* для моей среды следующим образом:

Существует еще одна группа безопасности с именем awseb-e-abc123-stack-AWSEBLoadBalancerSecurityGroup-*, что заключается в следующем. Он имеет тот же тег имени, что и вышеприведенная группа, который совпадает с именем моей среды:

Однако кажется, что записи группы безопасности "AWSEBLoadBalancerSecurityGroup" ничего не делают, так как удаление всех записей по-прежнему позволяет HTTP-трафику работать.

В .elasticbeanstalk\securelistener.configУ меня есть следующее

option_settings:
  aws:elb:listener:443:
    SSLCertificateId: <my certificate's ARN>
    ListenerProtocol: HTTPS
    InstancePort: 80

Однако, если добавить в этот файл синтаксическую ошибку, развертывание все равно будет успешным.

Вот вывод curl -vL https://<my domain>:

* Rebuilt URL to: https://<my domain>/
*   Trying <my elastic IP>...
* connect to <my elastic IP> port 443 failed: Connection refused
* Failed to connect to <my domain> port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to <my domain> port 443: Connection refused

Я использовал отдельный регистр доменных имен для настройки моего доменного имени и настроил IP-адрес DNS-записей моего домена, равный моему Elastic IP.

[редактировать]

Я уже упоминал выше, что изменение правил группы безопасности балансировщика нагрузки ничего не дает. Это произошло потому, что группа безопасности моих экземпляров EC2 указывала на группу безопасности экземпляра, а не на группу безопасности балансировщика нагрузки. Когда я указал группу безопасности EC2 на группу безопасности балансировщика нагрузки, правила группы безопасности были подвергнуты строгому контролю. Я проверил это, удалив все правила из группы безопасности балансировщика нагрузки и убедившись, что запросы не принимаются. Однако, если я добавлю обратно правила HTTP и HTTPS в группу безопасности балансировщика нагрузки, но удалю все правила из группы безопасности экземпляра, все запросы HTTP будут выполнены. Это НЕ ожидаемое поведение, потому что балансировщик нагрузки должен направлять трафик к экземпляру. Кажется, что происходит (1) группы безопасности экземпляра и балансировщика нагрузки вообще не связаны с экземпляром и балансировщиком нагрузки и (2) трафик не идет на балансировщик нагрузки.

Есть что-то еще, что я пропускаю?

[править 2]

Я неправильно понял комментарий Гкризека. Если я использую общедоступный DNS балансировщика нагрузки, я могу подключиться по протоколу HTTP или HTTPS. Я могу подключиться к обеим версиям, используя telnet. Поэтому вместо создания записи A, в которой для testdomain.com задан мой Elastic IP, я создал запись CNAME sub.testdomain.com, в которой установлен балансировщик нагрузки. Теперь я могу просматривать оба http://sub.testdomain.com а также https://sub.testdoamin.com, Два вопроса:

• Можно ли использовать публичный DNS балансировщика нагрузки в записи CNAME? Я не могу использовать URL-адрес *.elasticbeanstalk.com, потому что он может измениться, поэтому мне интересно, применяется ли здесь такая же ситуация?
• Как я могу обеспечить https://testdomain.com (без субдомена). Кажется, что с этим методом, невозможно иметь https://testdomain.com так как я не могу создать запись с доменным именем.

Answer 1

Проблема заключается в том, что вам нужно создать запись CNAME с вашим доменом и использовать DNS-имя балансировщика нагрузки в качестве адреса. Если вы используете Elastic IP, запросы не будут направлены на балансировщик нагрузки.

Чтобы ответить на мои последние вопросы:

• AWS говорит, что это нормально
• Это невозможно, пока AWS не позволит назначить Elastic IP для балансировщика нагрузки.