well known что за папка
Общее: Валидация сертификата
В статье мы подробно опишем процесс валидации домена для выпуска сертификата.
Валидацию сертификата можно осуществить одним из двух методов на ваш выбор:
Через размещение http файла
В разделе Выбор варианта валидации SSL-сертификата выбираем HTTP валидацию
Вам будет предоставлено название файла, которое необходимо создать в подпапке /.well-known/pki-validation/ Вашего сайта.
Для этого переходим в панель управления ISP в менеджер файлов. Ссылка и данные для входа были отправлены при активации сервера/хостинга. Папка WWW
Папка с названием сайта для валидации сертификата
В подпапке pki-validation нам необходимо разместить файл для валидации сертификата, в нашем случае это будет файл:
99EBE327CEE0D808A340AC22473B289D06266F7AABAAB1DB20319827C30F2091 comodoca.com 5fd77cd500668
Далее чтобы внести изменения в содержимое созданного файла нажимаем кнопку Изменить.
И добавляем содержимое файла, в нашем случае:
99EBE327CEE0D808A340AC22473B289D06266F7AABAAB1DB20319827C30F2091 comodoca.com 5fd77cd500668
Готово. Файл размещен.
Проверить корректность размещения файла можно по ссылке:
В браузере по ссылке должно открыться содержимое файла.
Далее в нажимаем кнопку «Отправить запрос на валидацию» на странице выбора типа валидации.
Проверка проводится автоматически. Если она прошла успешно, на ваш технический email будет отправлен файл сертификата.
Через почтовый ящик
В разделе настройка сертификата необходимо выбрать один из почтовых ящиков в вашем доменном имении нажать кнопку для перехода на следующий этап.
Почтовый ящик для валидации задан поставщиком сертификата. Почта должна быть в доменном имени для которого выпускается сертификат и должна быть вида:
webmaster@
postmaster@
hostmaster@
administrator@
admin@
После того, как сертификат заказан на ваш валидационный e-mail высылается письмо с просьбой подтвердить заказ SSL-сертификата. Для подтверждения заказа вам необходимо перейти по ссылке в письме и ввести валидационный код, который также будет предоставлен в письме
Готово. В течение нескольких минут после подтверждения на вашу контактную электронную почту вы получите письмо с сертификатом, который необходимо установить на сайт.
На следующем шаге вам необходимо выполнить установку сертификата.
Well known что за папка
Проект Let’sEncrypt вошёл в стадию публичной беты 3-го декабря 2015 года. Теперь его можно попробовать.
В чём суть проекта: он позволяет выпускать и продлевать SSL сертификаты бесплатно и автоматически.
На счёт «бесплатно» — здесь всё ясно. Можно бесплатно получить сертификат уровня Domain Validation.
А вот на счёт «автоматически» — чуть посложнее. Разберём процесс получения и установки сертификата.
UPD: Увеличена степень «автоматизма» получения сертификата, убраны однообразные ручные операции.
Испокон веков получение SSL-сертификата было, в некотором роде, геморроем, который заключался в выполнении следующих пунктов:
Так вот, для того, чтобы вам не нужно было проходить через всё это, некоммерческая организация Let’s Encrypt разработала специальный протокол ACME а также клиент, работающий с ним. Также, эта организация создала свой доверенный центр сертификации, который признаётся корневыми центрами сертификации, и уже есть во всех последних версиях браузеров.
Таким образом, в идеальном случае, вам достаточно будет установить клиент, и выполнить специальную команду, которая запросит сертификат, сама пройдёт проверку владения вами доменом, после чего получит сертификат и положит его в соответствующее место. Но это в теории. На практике же, инструмент может потребовать некоторых усилий.
В частности, если вы используете веб-сервер Nginx, а также, если веб-сервер у вас уже настроен, и работает, а вам нужно получить для него сертификат.
Алгоритм действий для получения сертификата
Я буду создавать сертификат для своего домена mihanentalpo.me, а также для поддоменов www и redmine. Поддомен www и вам пригодится, а другие поддомены выбирайте по своему усмотрению.
Настройка веб-сервера для использования Let’s Encrypt
Сервер Let’s Encrypt, перед выдачей сертификата убеждается в том, что домен принадлежит именно вам, для этого он обращается по определённому адресу вашего домена, и ожидает получить оттуда определённые данные. Для того, чтобы было удобно проходить эту проверку, будем размещать файлы проверок в конкретной папке.
1. Создадим папку /var/www/letsencrypt, в ней папку для файлов-испытаний letsencrypt и дадим серверу права на них:
Можно использовать и другую папку, но всюду где она будет упомянута далее, вам нужно будет также её подменять на свою придуманную.
В эту папку (.well-known/acme-challenge) мы будем класть файлик с «испытанием» для подтверждения владения сервером.
2. Изменим конфигурацию nginx для домена и поддоменов.
В секции server, описывающей ваш домен (порт 80, протокол http), добавим следующий блок:
Данную настройку нужно повторить для всех ваших поддоменов!
3. Создадим файл для тестирования доступа к папке с challenge’ами:
# echo «Hello world» > /var/www/letsencrypt/.well-known/acme-challenge/index.html # chown www-data:www-data /var/www/letsencrypt/.well-known/acme-challenge/index.html
4. Перезапускаем nginx, и проверяем, открывается ли что-нибудь из этой папки:
Для проверки открываем адреса (домен конечно нужно подставлять ваш):
http://mihanentalpo.me/.well-known/acme-challenge/index.html
http://www.mihanentalpo.me/.well-known/acme-challenge/index.html
http://redmine.mihanentalpo.me/.well-known/acme-challenge/index.html
Вы должны увидеть «Hello world» в каждом из случаев. Также, надо проверить все остальные ваши домены, если хоть один из них не будет отдавать «Hello world», надо разобраться в чём дело, так как дальше продолжать будет невозможно.
Установим и запустим клиент letsencrypt
1. Установка
Из мануала quick start следует, что установить клиент пока (июнь 2016 года) можно только из гитхаба. (Для некоторых дистрибутивов уже собраны пакеты, но в нашем родном Debian’е всё происходит не так быстро)
При первом запуске, команда letsencrypt-auto установит все пакеты, необходимые ей для работы, поэтому запускать её нужно либо от root’а, либо от имени пользователя, у которого настроено sudo, так как, программа, не найдя root-доступа, пытается запустить sudo.
2. Запуск процедуры получения сертификата:
Следующая команда запустит ручной процесс получения сертификата, в котором будут прописаны все эти указанные домены.
После запуска этой команды, в консоли откроется интерфейс, который начнёт с вами общение.
1. Клиент спросит вашу почту — нужно указать ту почту, к которой вы хотите привязать сертификаты. На неё будут приходить уведомления, когда сертификат будет близок к устареванию.
2. Нужно согласиться с пользовательским соглашением
Прохождение процедуры проверки
1. Согласиться с логированием IP-адреса
2. …. А и всё! Если конечно всё настроено правильно. Раньше здесь была инструкция на 5 пунктов о том, как подкладывать файлы challenge вручную в режиме —manual, но поскольку сейчас мы делаем через —webroot, то и процесс весь проходит сам.
3. Далее вы получите примерно такое сообщение об успехе:
Это значит что файлы сертификатов получены (и лежат они по адресу, в моём случае, /etc/letsencrypt/live/mihanentalpo.me/), и теперь остаётся только подключить их к серверу.
Подключение сертификатов к серверу
Самый простой конфигурационный файл nginx для подключения SSL-шифрования и использования выданных сертификатов (приложение на php-fpm):
Если где-то есть другой 443-сервер для редиректа на 80-й порт, то может быть ошибка:
no «ssl_certificate» is defined in server listening on SSL port while SSL handshaking, client: xxx.xxx.xxx.xxx, server: 0.0.0.0:443
Подключить ssl таким образом нужно во всех поддоменах. В моём случае, для www подключение не понадобилось, так как домен с www у меня задан как алиас для основного имени, а вот для redmine потребовалось внести коррективы в конфиг-файл
Всё! Теперь, как несложно убедиться, когда вы находитесь на моём сайте, слева от его адреса нарисован замочек, чего и вашим сайтам желаю.
Проверка сертификата
Проверить сертификат, и узнать о нём максимум информации, можно с помощью различных онлайн-сервисов, таких как https://www.ssllabs.com/ssltest/. Там нужно ввести адрес вашего сайта, и можно получить массу полезной информации, касаемо не только вашего SSL-сертификата, но и того, правильно ли сделаны настройки сервера.
Обновление сертификата
Для выпуска нового сертификата, если у вас истёк предыдущий (а это будет происходить раз в несколько месяцев), нужно запустить команду
поскольку скрипт помнит о том, как и для каких доменов вы получали сертификаты в прошлый раз, он просто повторит процедуру.
Если у вас добавились поддомены, вы можете выполнить команду, аналогичную представленной выше, добавив туда новый домен.
При этом клиент letsencrypt спросит вас «Сертификат для этого домен уже есть. Обновить его?», на что нужно ответить «да».
После обновления сертификата нужно перезагрузить веб-сервер
Решение проблем после обновления
После обновления сертификата и перезапуска Nginx у вас может возникнуть одна из следующих проблем:
(увидеть вы их можете, открыв свойства сертификата в браузере)
1) Дата истечения сертификата не изменилась
2) Дата истечения сертификата стала старше чем была
3) Сертификат вообще не работает
У этих проблем, как правило, одна причина: неверно создались симлинки на файлы сертификатов в папке /etc/letsencrypt/live/mysite.com (разумеется, путь должен быть с вашим именем сайта).
1) Проверяем куда ведут ссылки:
и видим что-то вроде этого (в моём случае):
2) Проверяем дату создания файлов по ссылкам:
и видим там что-то такое:
Отсюда видно, что симлинки стоят на древние сертификаты, устаревшие ещё в 2015 году. Новые же сертификаты лежат под именами cert3.pem, chain3.pem, fullchain3.pem.
Пересоздадим симлинки:
Для чего нужна «хорошо известная» папка?
Вот некоторые записи в журнале ошибок PHP одного из моих доменов. (Я удалил дату, ip и target-домены).
Сначала я подумал, что могу быть тем, кто это сгенерировал, но в те времена я не обращался к этим доменам и не работал с ними. И эти запросы доступа поступают от 3 наших доменов. (с разными веб-приложениями)
ИНФОРМАЦИЯ 1. Похоже, что IP получен от Google-Bot (Crawler). Но что такого важного для доступа к этим файлам? (у нас нет этих файлов в папках, они проверены на наличие скрытых каталогов во всех доменах).
Этот /.well-known/ подкаталог определяется RFC 5785 RFC 8615
Для веб-протоколов все чаще требуется запрашивать политику или другую информацию о хосте («метаданные всего сайта») перед выполнением запроса. Например, протокол исключения роботов http://www.robotstxt.org/ определяет способ для автоматизированных процессов получить разрешение на доступ к ресурсам; аналогично, Платформа для настроек конфиденциальности [W3C.REC-P3P-20020416] сообщает агентам пользователей, как заранее узнать политику конфиденциальности.
Хотя существует несколько способов доступа к метаданным для каждого ресурса (например, заголовки HTTP, PROPFIND WebDAV [RFC4918]), воспринимаемые накладные расходы (связанные с задержкой и / или сложностями развертывания), связанные с ними, часто исключают их использование в эти сценарии.
Когда это происходит, обычно назначают «общеизвестное местоположение» для таких данных, чтобы их можно было легко найти. Однако этот подход имеет недостаток риска столкновений, как с другими такими назначенными «хорошо известными местоположениями», так и с уже существующими ресурсами.
Местоположения в этом каталоге затем используются для определенных целей,
Оба из них поддерживают аналогичную цель, они позволяют оператору сайта инструктировать посетителя открывать сайт в связанном приложении, а не в (мобильном) браузере.
Вот несколько записей журнала ошибок PHP одного домена. (Я удалил дату, ip и целевые домены).
Сначала я подумал, что я мог бы быть тем, кто сгенерировал это, но в то время, когда я не получал доступа к этим доменам. И эти запросы доступа поступают из 3 наших доменов. (с различными веб-приложениями)
1 ответ
Подкаталог /.well-known/ определяется RFC 5785
Для веб-протоколов все чаще используется требование обнаружение политики или другой информации о хосте («на сайте метаданные «) перед выполнением запроса. Например, роботы Протокол исключения http://www.robotstxt.org/ определяет способ автоматизированные процессы для получения разрешения на доступ к ресурсам; Аналогично, Платформа конфиденциальности [W3C.REC-P3P-20020416] сообщает пользовательским агентам, как заранее установить политику конфиденциальности.
Хотя существует несколько способов доступа к метаданным для каждого ресурса (например, HTTP-заголовки, PROPFIND WebDAV [RFC4918]), воспринимаемые накладные расходы (либо с точки зрения клиентской задержки и /или развертывания трудности), связанные с ними, часто исключают их использование в этих сценарии.
Когда это происходит, обычно обозначается «хорошо известный location » для таких данных, чтобы он мог быть легко расположен. Однако этот подход имеет недостаток рисковых столкновений, как с другими такими обозначенными «хорошо известными местоположениями» и с ранее существовавшие ресурсы.
Местоположение в этом каталоге затем используется для определенных целей,
Оба из них поддерживают аналогичную цель, они позволяют оператору сайта указывать посетителю открывать сайт в связанном приложении, а не в (мобильном) браузере.
Не могу создать сертификат ssl для одного домена
Привет, у меня возникла проблема при создании ssl сертификата для одного домена от Let’s Encrypt
с другими домена все прошло успешно, а вот для одного постоянно в консоли кидает вот эту ошибку
— The following errors were reported by the server:
Domain: odin-domen.ru
Type: unauthorized
Detail: Invalid response from
http://odin-domen.ru/.well-kno. awjkhH5KY:
»
404 Not Found
Not Found
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
делал все так же как и с другими доменами, что не так?
может кто сталкывался, у меня операционка немного устаревшая UBUNTU 12.04
но по факту с другими доменами все гуд а этот че-то золупнулся и все тут.
Не могу установить ssl сертификат на веб морду
сертификать добавляеться но нп сохраняеться
Не могу настроить ssl сертификат на веб сервере
Добрый день получил сертификат thawte SSL123 через nic.ru делаю по их инструкции, скачал файл.
я примерно это и понял, но ранее создавал сертификаты для других доменов и все проходило успешно
и директория .well-known/acme-challenge
в корне тех доменов никогда не создавалась
да и в корне сервера тоже нет, это виртуальная видимо директория которой физически не существует на сервере, а если существует тогда подскажите где она может быть?
Добавлено через 4 минуты
по этому пути где лежат сертификаты /etc/letsencrypt
и по этому /opt/eff.org/certbot/venv
данной директории нет .well-known/acme-challenge
в другие директории Let’s Encrypt вроде как не пустил метастазы.
Добавлено через 30 минут
также это читал https://community.letsencrypt. blem/42413
но не помогло так как нет директории /var/www/html/
Добавлено через 12 минут
с другими доменами все проходило нормально, может эта директория .well-known/acme-challenge где-то и создавалась но я ее не нашел!
служебный файл для проверки создается в рабочей директории вебсервера.
Решение
вот и загадка почему с одними доменами все прошло, а с другим нет.
Добавлено через 1 минуту
вроде как я не прописываю путь для какого домена, все в консоли через помощник указываю цифру домена энтер, ну вы в курсе.
Добавлено через 16 минут
попробовал и такие команды, тоже ошибка 404
просто бред какой-то
все домены висят на одном ип и права на директории одинаковы, какая-то избирательность, может есть фильтр на стоп слова в имени домена, там же говорилось что сертификаты только для некоммерческих сайтов.
Ssl сертификат для Kerio MailServer
Здравствуйте. Недавно появилась проблема с Kerio MailServer: 06.04.2019 заканчивается ssl.
Не могу создать куку для другого домена
Вообщем не хочет создавать куку для другого домена: setcookie («TestCookie».
Бесплатные или дешевые доменное имя и SSL-сертификат для домашнего сервера
Есть постоянный внешний IP на QWERTY и Linux-сервер дома. IP адрес и DNS от QWERTY получает роутер.
Как привязать свой сертификат SSL к приложению SelfHost для использования шифрования TSL?
Приветствую! Вопрос в следующем: Делаю самостоятельное приложение (SelfHost) API. С http работает.