хотел спросить мимоходом
будет рабомтать внутри локалки с локальным днс сервером + докер
может ли трафик дергать сертификаты lets encrypt из локалки через тлс?
вчера учатика гпт спросил, он говорит что не может, надо иметь днс публичный или чтобы трафик торчал наружу 443м портом, чего я пока делать не хочу
там еще есть докер контейнер, который что-то делает, но я еще пока не разобрался
Как это работает
В Traefik есть встроенный ACME client.
Он может работать через:
httpChallenge
tlsChallenge
dnsChallenge
По умолчанию он обращается к публичному Let’s Encrypt ACME-серверу (https://acme-v02.api.letsencrypt.org/directory).
Но в конфиге можно задать свой caServer, например step-ca или тестовый сервер Let’s Encrypt (staging).
вот что он мне написал
я думал, что если нет днс и публичного веб сервера, то тлц вариант сам делает запрос на сервер lets encrypt
правильно ли я понял? или никак не сделать это и надо делать сплит днс?
Не совсем так.
Раньше ты покупаешь домен, приносишь “чек на покупку” и тебе выписывают за деньги сертификат. (сейчас это тоже работает для корпоратов)
LetsEncrypt должен подтвердить права владения доменом, т.е. должен быть куплен публичный домен, на который выписывается сервтификат (поле CN), потвердить владение доменом можно несколькими способами, но по сути, они сводятся к 2м
DNS challenge - это когда ты добавляешь txt или cname запись, тем самым подтверждаешь, что являешься админом домена
http/tls challenge - это когда ты загружаешь файлик на сервер, который можно скачать, причем, я почитал про tls challenge, там вроде как обычный http, просто с самоподписанным сертификатом
Т.е. а любом случае должен быть домен (скоро ожидается выпуск сертификатов для IP адресов, но подозреваю, что публичных, а не локальных) и для этого домена LE выпускает и подписывает своей подписью сертификат, а подпись эта (сертификат), в свою очередь либо подписывается более крутым удостоверящим центом (как было изначально), либо на уровне договоренностей копируется на все клиентские системы.
Соответственно, цепочка доверия выглядит так:
Корневой СA (крутой), который зашит в операционную систему или браузер-> какой-то менее крутой УЦ → LE → сертификат вашего домена
В этой цепочке Google доверяет нескольким корневым CA и зашивает его подпись в
Google Chrome, корневые тесно работают с УЦ нижнего уровня, но все равно это физическое доверие (лицо к лицу так сказать, договора, ключи и т.д., раньше банки заставляли для банк-клиентов печатать запрос на подпись сертификата на бумаге, ставить печать ООО и подпись директора и с этой бумажкой и паспортом идти в офис банка, там эти данные проверяли и подписывали сертификат клиента)
И тут где-то в цепочке есть LE, но сейчас, повторюсь, они стали настолько крутыми, что уже работают с Google без посредников
И дальше на самом последнем этапе доверия есть пользователь certbot, который купил домен и хочет выпустить LE сертификат для него, сходить ножками в офис LE он не может, поэтому LE говорит
Вот тебе TXT запись, зайди в админку управления доменом и добавь там эту запись, а мы сходим в публичный DNS сервер и запросим у эти данные, если совпало, то мы тебе верим
Собственно, поэтому, LE выпускает сертификаты на 90 дней, а со следующего года собирается сокращать время действия сертификата. Как раз для того, чтобы постоянно проверять “прописку клиента” (закончился срок регистрации домена и я не могу подтвердить его владение) и исключать утечку сертификата (если злоумышленник скачает приватный ключ с сервера, то сможет его пользовать до окончания срока действия, это как требования периодической смены пароля)
Резюме
Как мы видим, в данной схеме в любом случае должен быть публичный домен, к которому имеет доступ LE, он может не резолвится в случае DNS challenge, но SOA, NS, TXT/CNAME записи должны быть
Что можно сделать
1. Поднять свой УЦ
Выпускаем корневой сертификат
Выпускаем сертификаты для сервисов на внутренние доменные адреса или IP
Подписываем CA эти сертификаты
Всем клиентам добавляем корневой CA в качестве доверенного
В этом случае у насработает принцип доверия как с LE сертификатами, только мы должны принудительно добавить в доверенные наш УЦ
Тут получение, выпуск и отзыв сертификатов производится при помощи соответствющих инструментов
Это корпоративный стандарт, т.к. вместо подтверждения владением доменом, используются креды сервиса, а в корпоративной среде вообще может быть какой-нить jabber сервер без 80 порта, а кому-угодня править DNS записи тоже давать не стоит. Тут же мы говорим: пользователю AAA можно выпускать сертификаты для дометов AAA.domain.com и BBB.domain.com
2. Поднять свой LE сервер
По сути, тут у нас все как с пунктом 1. но вместо PKIшки готовой мы берем certbot и пишем свой letsencrypt сервер + придумываем challenge
В этом случае, мы сможем быстро подключить сервисы, которые умеют работать с LE, но нам надо будет писать с нуля свой LE под свою инфраструктуру
Ну в вашем случае либо заморачиваться с полноценным CA если надо выпускать много сертификатов, или по ссылке по LE для localhost сгенерировать несколько файлов (со сроком действия лет 10, но лучше 1-2 года), 2 из них ручками положить в traefik, а один скопировать на все клиентские машины, которые будут работать с traefik
Тут еще надо учитывать, что не все браузеры и другое ПО использует /usr/local/share/ca-certificates/ поэтому может понадобиться добавлять их руками
это как тот самый пункт, который хочется избежать путем применения ле сертификата, иначе просто дефолтный самоподписной принять браузером и готово, но не хочется так делать
я думал будет работать и для локальных доменов без копирования сертификатов на все браузеры
ну тогда придется делать сплит днс, публичный сервер у нас есть и вроде есть такая зона на внутреннем днс, надо будет в понедельник у админа тогда узнать
вообще хотел для всех админских ресурсов сделать целую днс зону, а то все через ип адреса заходим
