Comments 18
Для начала, оригинальная статья от 2018 года и на тот момент, LE был "революционно новым" ... с точки зрения автора. Можно было бы как-то вычитать статью перед публикацией?
Как видите, это не так уж и сложно.
Сначала мы присвоили каждому устройству (так называемому внутреннему серверу) публичное доменное имя, используя наш собственный динамический DNS-сервер и выделенную зону DNS. Используя домен, назначенный серверу (здесь: xi8qz.example.com), мы затем использовали предложение бесплатного сертификата Let's Encrypt и их запрос DNS, чтобы выпустить сертификат для этого сервера.
tl;dr Слишком сложно и много немотированного мазохизма...
Буквально как вот вчера занимался похожим: надо было наладить HTTPS по внутренней сетке, создав свои сертификаты и подписав их своим же trustable certificate authority.
На самом деле все куда проще, чем предлагает автор этой оригинальной статьи.
Cтавим easy-rsa согласно гуглегайдам.
Тут нет ничего сложного:
apt install easy-rsa
mkdir ~/easy-rsa
ln -s /usr/share/easy-rsa/* ~/easy-rsa/
cd ~/easy-rsa
nano varsset_var EASYRSA_REQ_COUNTRY "XX"
set_var EASYRSA_REQ_PROVINCE "Localhost"
set_var EASYRSA_REQ_CITY "Localhost"
set_var EASYRSA_REQ_ORG "Localhost"
set_var EASYRSA_REQ_EMAIL "admin@localhost"
set_var EASYRSA_REQ_OU "internal"
set_var EASYRSA_ALGO "ec"
set_var EASYRSA_DIGEST "sha512"
затем
./easyrsa init-pkiГенерим свой CA сертфикат:
./easyrsa build-ca nopass
и кладем в /usr/share/ca-certifactes:cp ~/easy-rsa/pki/ca.crt /usr/share/ca-certifactes/
далее запускаем:dpkg-reconfigure ca-certificates
(для Debian, Ubuntu)
хотя гайды говорят что надо запускать update-ca-certificates - но это все копи-пасты из одного источника без проверки результата.Далее делаем столько CSR'ов сколько необходимо сертификатов (в моем случае нужна была пачка из 12 сертификатов, я просто запустил в цикле список внутренних доменов:
openssl req -new -newkey rsa:4096 -nodes -keyout example.com.key -out example.com.csr -subj /C=LO/ST=Localhost/L=Localhost/O=Localhost /OU=testonly/CN=*.example.comхинт: ничего не мешает сделать wildcard subdomain
Импортируем CSRы в репо easy-rsa:
./easyrsa import-req CERT ALIAS
где ALIAS - это некий алиас, например имя домена:./easyrsa import-req /path/dir/example.com.csr example.comЕсли импорт прошел ок, подписываем серты своим CA:
./easyrsa sign-req server ALIAS
где ALIAS - это алиас из предыдущего запуска
все подписанные серты лежат в~/easy-rsa/pki/issued
и имеют название <ALIAS>.crt
Кладем этот .crt + .key из п.3 в нужные места своих серверов.далее грузим ca.crt в /usr/share/ca-certificates всех своих серверов (которые под линуксом) и проделываем dpkg-reconfigure ca-certificates
Для винды, если нужно чтобы браузер не орал о том, что он категорически не доверяет самодельному сертификату:
win-R / mmc
открывается microsoft managment consoleFile - > Add/remove snap -ins
в списке находим:"Certificates" - > double click -> выбираем "Computer Account" -> Next -> Local Computer -> Finish -> OK
в MMC видим:
Console Root
> Certificates (Local computer)
Тыц -> Раскрывается список :Trusted root certification authorites -> правая кнопка -> All tasks -> Import -> Next -> Browse (выбрать где лежит наш ca.crt) -> Next и тд.закрыть MMC (отменить сохранение). закрыть браузер(ы). Запустить браузер(ы). Теперь браузер обучен доверять самописному серту в пределах данного компьютера
по дефолту: свой CA имеет срок 10 лет, самописный серт - 3 года. В отличии от LE, который надо будет обновлять с бубном каждые 3 месяца.
"революционно новым" убрал из текста. По посту - я как и ищу автоматизировать создание сертификатов LE для внутренних IP адресов
хотя гайды говорят что надо запускать update-ca-certificates - но это все копи-пасты из одного источника без проверки результата.
Использую update-ca-certificates на своих убунтах — всё отлично работает. Что с ним не так?
создав свои сертификаты и подписав их своим же trustable certificate authority
Хорошо, что это подошло вам, но все же это не прямая альтернатива Lets Encrypt, это просто обычная реализация своих сертификатов.
В отличии от LE, который надо будет обновлять с бубном каждые 3 месяца.
Серификат с коротким сроком действия безопаснее в случае его "угона", плюс побуждает настроить всё сразу автоматически, надёжно. Уж сколько было случаев, когда через несколько лет что-нибудь переставало работать, т.к. сертификат был подложен руками и его никто не отслеживал.
Очень категорично заявили, поэтому спрошу: вы считаете, что раскладывать самопальные сертификаты на все новые клиентские устройства прям во всех случаях удобнее, чем получать валидные на серверы?
Даже не написали какой DNS-сервер используется, как настраивается доступ к API, и имеют ли все устройства один и тот же пароль/токен от API?
Это надо задавать автору оригинального поста https://blog.heckel.io/2018/08/05/issuing-lets-encrypt-certificates-for-65000-internal-servers/
У меня глупый вопрос. А почему бы не использовать wildcard-сертификаты? Зачем генерить отдельно сертификаты для каждой машины в одном и том же домене, если можно получить один и раскатить на все машины?
apt-cache search certbot | grep dns, если нет (хотя можно и домен третьего уровня отдать под это).
Использование wildcard чревато лёгким MITM для всех, кто может использовать Let's Encrypt. Вообще, мне не нравится идея как-то вытаскивать сведения наружу об инфраструктуре; на месте хакера, прознав о DNS-зоне, доступ к которой открыт из интернета для серверов LE, я бы раз в полминуты или чаще отправлял бы запрос на TXT-записи и регулярно пополнял бы список поддоменов, которые затем можно пробить на резолв. Узнать о такой зоне может быть непросто, но sublist3r может помочь.
Резюмируя: не стоит. Вместо этого предлагаю использовать сервер step-ca с поддержкой ACME. Бинарник разворачивается на внутренней инфраструктуре. Его поведение не совсем RFCшное, например, не реализован отзыв сертификата, но чем больше людей им пользуются, тем больше шансы, что его доведут до ума.
У нас сделано так есть int.firm.lan и отдельно _acme-challenge.int.firm.lan.
Снаружи видна только зона _acme-challenge.int.firm.lan.
Да, вот здесь упоминается об идее сделать CNAME, которые все будут указывать на одну зону _acme-challenge, в таком случае уровень поддомена неважен. Но там же поднимается вопрос публичности логов LE, я чувствовал, что что-то забыл, ведь certbot предупреждает, что данные о доменах будут доступны публично. Ссылку пришлось поискать, здесь есть строка, куда можно вбить домен и посмотреть, что на него было выписано и залогировано.
В общем, wildcard - безопасный с т. з. логов вариант, но уже есть опасность MITM и сбора таким образом LDAP-паролей сотрудниками внутри компании.
Certbot делает запись TXT в зону, сервер LE считывает и выдает сертификат, запись TXT удаляется. Получение wildcard сертификата с использованием DNS абсолютно безопасно, если только у вас админка DNS не проходной двор.
Зависит от принятой в организации модели управления хостами. Если поддомен выделяется на разработчика - да, если на команду или систему распределения ресурсов (*.k8s.example.org) - нет. Если доступ к DNS имеют только пяток админов, которые также контролируют учётки - да, если делаем сервис для самовыписывания сертификатов разрабами - тут может быть и безопасно, и нет, смотря на какие домены разрешать.
Использование Let's Encrypt для внутренних серверов