Любые параметры для HTTPS в директиву с listen 443, как и
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
Для результата, который описан в первом сообщении, следующий код с редиректом не нужен ни в одной директиве
if ($scheme = http) { return 301 https://$server_name$request_uri;}
У вас сайт будет работать через HTTPS при запросе HTTP, даже без редиректа (как только вы хотя бы раз посетите HTTPS версию или ваш сайт добавят в HSTS preload list).
Для этого и нужен HSTS/preload list.
В то время, Яндекс и другие клиенты без поддержки HTTP/2, будут получать быструю HTTP версию сайта.
А скорость загрузки для поискового робота важнее шифрования, ведь он не будет вам данные кредитных карт отправлять.
Dram, у вас должно быть две директивы server {}.
Одна отлавливает HTTP запросы (listen 80), а другая HTTPS (listen 443).
Вот во вторую и нужно вставлять все специфические для HTTPS параметры, в том числе заголовок HSTS.
То-есть, вам нужно создавать параллельно к server {listen 80} еще одну директиву с теми параметрами, что указаны в инструкции DigitalOcean.
Это можно сделать скопировав директиву server {listen 80} и изменив/добавив нужные параметры (listen меняем с 80 на 443).
Ошибка у вас была потому, что вы все параметры задавали в одной директиве.
А код if я вам дал для PHP, а не Nginx, потому, что думал, что вы задаете заголовки через него.
Можете отправить мне изначальный файл site.com.conf в личные сообщения и уточнить путь на crt/key/pem.
Я отправлю вам отредактированную версию.
Да, если 100% пользователь пользователей заходят с последней версии Google Chrome и корректная индексация Яндекс не нужна.
В противном случае, некоторые пользователи с поддержкой только уязвимых методов шифрования (SSL), вообще не увидят сайт при корректной настройке сервера.
Яндекс и пользователи, которые открывают сайт из под динозавров (IE8, IE9, IE10, Opera Mini, Opera Mobile, Opera 12) будут использовать медленный HTTP/1.1, хотя это не обязательно!
А так:
1. 80% пользователей использующих современные браузеры, в том числе Google Chrome, который помечает сайт, как "Надежный" получают быструю HTTP/2 версию сайта через HTTPS.
2. Яндекс и по желанию Google, используют быстрый HTTP без шифрования (ибо шифрования им не нужно, они ведь не будут отправлять вам данные кредитных карт!)
3. Пользователи, которые не поддерживаю TLS и используют уявзимые методы шифрования, получат HTTP версию вместо медленной и уязвимой SSL версии.
Это полностью соответствует рекомендациям Google по миграции сайтов на HTTPS.
Скобки в этом случае не обязательны
http://stackoverflow.com/questions/2125066/is-it-bad-practice-to-use-an-if-statement-without-brackets
http://stackoverflow.com/questions/11650640/why-isnt-serverhttps-set-to-1
Как я понял, определенные ключи в $_SERVER могут отсутствовать или отдавать разные значения в зависимости от сервера и сборки.
Приведите дамп var_dump($_SERVER); или var_dump($_SERVER['HTTPS'], $_SERVER['SERVER_PORT'], $_SERVER['HTTP_X_FORWARDED_PROTO']); для HTTP версии
и полный текст ошибки для кода выше.
Этот заголовок должна возвращать только HTTPS версия сайта.
То-есть, нужно предварительно проверить протокол по которому запрашивается сайт.
Если не ошибаюсь
if ((!empty($_SERVER['HTTPS'])) or ($_SERVER['SERVER_PORT'] == 443)) header('Strict-Transport-Security: max-age=63072000; includeSubDomains; preload');
Один раз посетив HTTPS, вы будете получать HTTPS, даже запрашивая HTTP.
А уже благодаря HSTS Preload List (который встроен в современные браузеры и регулярно обновляется из одного хранилища),
мы получаем HTTPS по-умолчанию, даже если никогда не посещали HTTPS версию.
Не забудьте добавить заявку на включение вашего домена в этот список.
Так ведь я могу установить Excel, если мне понадобится функционал конкретно EXE версии.
В этом случае, я бы сохранял файлы в папку Google Drive, чтобы была возможность просматривать их на других устройствах.
Но именно предпочитаю я веб-версии (Todoist, Skype, Messenger, Gmail, Google Calendar, Google Music, Google Drive и много других).
Практически, мне достаточно войти в Google Chrome на любой устройстве, и почти все мои приложения, данные, история и так далее, будут доступны.
Кроме того, у меня есть возможность разделить свою жизнь на контексты.
Один профиль для работы, другой профиль для личной жизни.
Открыл рабочий профиль - никакие развлекательные сайты в нем не мелькают и никакие оповещения не отвлекают.
Почта, соответственно, тоже другая.
Очень удобно.
Настроить шифр, отключить уязвимые протоколы шифрования, которые позволяет перехватывать трафик, отключить контент сниффинг, включить HSTS.
Сервис позволяет также проверить доступность и протокол (http/https/spdy 1.1/2) для самых популярных устройств и поисковых ботов.
Вы можете отловить ситуацию, когда сайт не работает на каком-то устройстве/не доступен конкретному боту из-за некорректной настройки конкретно вашей конфигурации сборки сервера.
Вы прогоните сайт через этот сервис, там более 50 параметров.
Я следовал рекомендациям Google и только.
Рекомендации и инструкции зависят от того, что вы уже умеете.
Вы задавайте конкретные вопросы в теме, мы постараемся вам помочь пошагово.
Лучше использовать Let's Encrypt.
Но для него нужно устанавливать дополнительный софт на сервер, для автоматической выдачи новых сертификатов по истечению срока годности.
Там срок годности сертификата 3 месяца, если не ошибаюсь.
Рекомендую инструкцию по установке Let's Encrypt на Ubuntu 16 LTS от DigitalOcean
(на выходе - A+, HTTP/2, HSTS, запрещен контент сниффинг, абсолютно все нюансы включены и если у вас сервер на DO, можно даже задать вопрос по материалу тех. поддержке)
https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04
Если доступа к SSH сервера нету, тогда из бесплатных остается только StartSSL/CloudFlare.
(ну и еще возможно какие-то китайские провайдеры, что вас вряд ли заинтересует)
Я использовал StartSSL, но планирую перейти на Let's Encrypt.
Установка очень простая, StartSSL отдает цепочку сертификатов.
Этот файл вы размещаете на сервере и ссылаетесь на него из Nginx в директиве server {}
Попутно, я включил поддержку HTTP/2.
У меня последняя версия Ubuntu LTS, поэтому, мне не нужно было ничего обновлять для поддержки ALPN (но обязательно нужно уточнить этот момент).
Если на домен уже есть обратные ссылки, то лучше делать редирект с HTTP на HTTPS.
В противном случае, HTTP версия страниц, на которые есть обратные ссылки, может быть параллельно с HTTPS и выводиться по умолчанию в SERP.
(это касается только Google)
Для Яндекса достаточно выбрать HTTPS версию в Host и подать заявку на переезд сайта в вебмастере.
Если вы хотите, чтобы пользователь вводя ваш адрес в адресную строку, по умолчанию, получал HTTPS версию, тогда нужно отдавать HSTS заголовок и добавить сайт в HSTS preload list.
(этого делать не нужно, если вы настроили редирект, но Google советует, использовать именно HSTS, если нужно предпочитать HTTPS версию)
https://hstspreload.org/
После полной настройки HTTPS на сервере, рекомендую проверять настройку шифрования, а также доступность для разных устройств (и в том числе YandexBox) с помощью
(ориентируйтесь на результат A+)
https://www.ssllabs.com/ssltest/
Я не делал редирект с HTTP на HTTPS, как рекомендует Google.
Для Яндекса, я выбрал главное зеркало в Host и Вебмастер - Переезд сайта.
Все обновилось за один ап.
Для Google - canonical на HTTPS.
Тоже все обновилось за сутки.
HTTP страницы сразу исчезли из выдачи и не появлялись вот уже более пару месяцев.
(но здесь нужно учитывать, что сайт новый и обратных ссылок на HTTP версию не было)
Из плюсов - всякие браузеры, которые не поддерживают современные инструменты шифрования (TLS и так далее - Android 2.3, всякие там Nokia браузеры), будут получать в ответ HTTP версию, а современные, благодаря HSTS preload, всегда будут получать HTTPS.
Google часто предзагружает первый результат (прорисовывает, если быть точным) в SERP через <link rel="prerender"...
Что было сделано:
1. На служебной странице был UNREGISTER ServiceWorker для сайта, с которым выполнялся пункт номер 2
chrome://serviceworker-internals/
2. Найден сайт в Google, где для него выводится расширенный сниппет и Google добавляет его в <link rel="prerender">.
А именно "smashingmagazine.com"
3. Обновлена страница
4. В ней появился ServiceWorker сайта, который Google добавил в prerender.
При этом я не переходил по ссылке из SERP!
Кто хочет повторить эксперимент, переходите сразу на chrome://serviceworker-internals/, потом вводите на google.com (не в адресную строку, это само себе вызывает prerender) "smashingmagazine.com" и обновляйте chrome://serviceworker-internals/.
В результате, без посещения сайта, у вас появляется процесс, который будет скачивать обновления сайта, которого вы не посещали.
То-есть, без посещения сайта, Google Chrome подтягивает скрипт, который может скачивать и хранить до 500 ГБ в Cache API.
Я пока изучаю вопрос SW более подробно, в том числе, какие функции доступны ему.
Как я понимаю, в контексте Event, ему недоступно множество методов и свойств, которые доступны в Document/Window.
Как я понял, Fetch, в том числе и с другого домена (Google Cache/AMP) ему доступен.
https://fetch.spec.whatwg.org/
Возможно у кого-то появились мысли по этому поведению браузера/Google,
буду рад услышать, можно в личные сообщения.
