Краткая версия: Я получаю ошибки https на статическом веб-сайте в корзине AWS S3, настроенной для веб-хостинга, но не https. Он расположен в записи CNAME, указывающей на ведро S3 на моей зоне размещения AWS Route 53, где запись A переходит на другой сайт, который использует https.https-ошибки на статическом сайте AWS S3 на субдомене
Длинная версия:
У меня есть сайт Rails размещенный на моей вершине URL (idoimaging.com) на экземпляре AWS EC2. Я хочу, независимо от этого, разместить блог как статический сайт (Jekyll) в качестве поддомена blog.idoimaging.com.
Чтобы протестировать с помощью простой настройки, я попытался создать минимальный статический сайт субдомена hello.idoimaging.com. Я сделал тестовое ведро с именем hello.idoimaging.com, и в нем я помещал небольшие файлы index.html и error.html. Я включил хостинг веб-сайтов в свойствах ковшовых и добавил читать-всю политику в ведре:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Allow Public Access to All Objects",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::hello.idoimaging.com/*"
}
]
}
я могу посетить ведро непосредственно в его конечной точке hello.idoimaging.com.s3-website-us-east-1.amazonaws.com и я вижу страницу index.html. Все хорошо до сих пор.
Теперь я хочу установить CNAME, чтобы я мог посетить статический сайт по адресу hello.idoimaging.com. В AWS Route 53 у меня есть зона для моего домена idoimaging.com, и в этом домене я создал CNAME с именем «hello.idoimaging.com» и значением «hello.idoimaging.com.s3-website-us-east-1.amazonaws.com».
результаты рыть исправны:
$ dig hello.idoimaging.com
...
;; QUESTION SECTION:
;hello.idoimaging.com. IN A
...
;; ANSWER SECTION:
hello.idoimaging.com. 226 IN CNAME hello.idoimaging.com.s3-website-us-east-1.amazonaws.com.
hello.idoimaging.com.s3-website-us-east-1.amazonaws.com. 60 IN CNAME s3-website-us-east-1.amazonaws.com.
s3-website-us-east-1.amazonaws.com. 3 IN A 52.216.64.90
...
;; AUTHORITY SECTION:
s3-website-us-east-1.amazonaws.com. 1778 IN NS ns-1133.awsdns-13.org.
s3-website-us-east-1.amazonaws.com. 1778 IN NS ns-1919.awsdns-47.co.uk.
s3-website-us-east-1.amazonaws.com. 1778 IN NS ns-490.awsdns-61.com.
s3-website-us-east-1.amazonaws.com. 1778 IN NS ns-661.awsdns-18.net.
Первоначально, когда я пытался посетить hello.idoimaging.com я только что получил тайм-аут. Я где-то читал сообщение о щелчке правой кнопкой мыши «Сделать общедоступным» на объектах в ковше. Мне это не показалось правильным, так как я думал, что для этого нужны вековые политики, но когда я попробовал, у меня были изменения. В разделе «Разрешения» теперь у меня есть грантополучатель: все права на открытие или скачивание, и хотя он все еще не работает, теперь я получаю ошибку безопасности HTTPS вместо таймаута. Поэтому казалось, что «Make Public» (который мне никогда не приходилось использовать раньше) изменил ситуацию. Прогресс, я думаю?
Используя curl, я могу получить hello.idoimaging.com, и он извлекает файл index.html, не беспокойтесь, даже если я использую --proto https. wget и любой браузер, однако, не будут.
Все запросы к hello.idoimaging.com теперь вынуждены использовать https: //, что не работает с «Ваше соединение не является приватным»/«Этот сайт использует HTTP Strict Transport Security (HSTS)» и различные сообщения в разных браузерах. Нормально ли это поведение от силы к https? Причина, по которой я спрашиваю, заключается в том, что мой apex-сайт на сервере nginx перенаправляет HTTP-запросы на https. Но если я запрошу hello.idoimaging.com, DNS заберет CNAME для моего сайта S3, а не запись A для моего сайта apex, не так ли? Кажется, они не могут быть связаны. Сайт apex защищен локальными сертификатами от letencrypt.org.
Как только я это сделаю, я хочу использовать CloudFront, но сейчас у меня довольно много проблем с сайтом S3.
Похоже, что проблема связана с запросами на hello.idoimaging.com (набирается так же, как это), которые вынуждены записывать https, и это не работает. Ищите совет. Если проблема связана с тем, что мой apex-сайт является https, а субдомен не является https, кажется, я собираюсь усложнить его, поставив https на субдомен, потому что он будет использовать разные сертификаты с сайта apex.
Все это сейчас происходит и живет.
Я склонен полагать, что это будет дублировать [ответ Amazon AWS 307 и постоянную переадресацию на HTTPS] (http://stackoverflow.com/ a/28595295/1695906) - вы настроили HSTS в своем базовом домене и, похоже, * браузер * расширяет его до субдоменов. Служба не делает этого. Этого не может быть, becauae хостинг веб-сайтов не может делать HTTPS без помощи CloudFront. –
Это выглядит очень многообещающе! Мой сервер nginx не имеет сконфигурированного заголовка Strict-Transport-Security, но это, безусловно, объясняет поведение. Кроме того, почему curl может извлекать страницу index.html, но браузер не может. Я читаю HSTS. Похоже, было бы хорошо? Поскольку я собираюсь поставить свой ведро S3 за CloudFront, который поддерживает TLS, должен ли я просто двигаться вперед? Я думал, что будет проще начать с http, возможно, это вызовет проблему. –
Вы были правы, в принципе, сначала попробовать более простую конфигурацию, но в этом случае это, вероятно, усложняет ситуацию. Я подозреваю, что в какой-то момент вы должны были настроить HSTS, поскольку это происходит. Браузеры помнят этот флаг, как только они его видят. Также обратите внимание, что с CloudFront, [не выбирайте имя ковша из раскрывающегося списка] (http://stackoverflow.com/a/34065543/1695906), когда ведро настроено для хостинга веб-сайтов. Введите имя хоста конечной точки веб-сайта (ваша текущая цель CNAME) в поле имени хоста. –