pavlyuts Dec 29 2022 at 18:12

Сертификаты Let's Encrypt и ACME вообще во внутренней сети

6 min

17K

Tutorial

Обычно внутри корпоративной сети нынче полно всяких приложений, и хотелось бы чтобы они работали по SSL. Можно, конечно, поднять свой УЦ, раздать сертификаты, прописать пользователям свой корневой сертификат - и это будет работать. А можно просто воспользоваться сервисом Let's Encrypt, раздав его сертификаты своим внутренним серверам, которые не видны из Интернета, причем сделать это просто и с минимумом трудозатрат на поддержку.

Необходимые условия

Наличие зарегистрированного домена, допустим, mycompany.ru и адресация внутренних серверов в нем.
Использование split-DNS, т.е. разрешение доменных имен mycompany.ru в разные IP адреса для внутренней сети и для всего Интернета. Делается либо через механизм View сервера BIND либо просто путем использования разных DNS серверов.
Внутренние сервера имеют доступ в Интернет по HTTPS - через маскирующий/NAT шлюз, файрвол, прокси, как угодно. Впрочем, это можно преодолеть, просто эту статью придется дочитать до конца, а поработать чуть больше.

Как это работает

Логика работы сервиса Let's Encrypt:

Сервер-претендент обращается к API Let's Encrypt по HTTPS, сообщает ему домены, для которых нужен сертификат. Например, server.mycompany.ru.
В ответ сервис формирует некий код, который должен быть размещен по запрошенному доменному адресу чтобы подтвердить принадлежность домена. Есть варианты: размещение файла с кодом на веб-сервере или добавление в DNS домена определенной записи. Мы будем использовать файл на веб-сервере.
"Проверялка" Let's Encrypt лезет простым GET запросом на адрес http://server.mycompany.ru/.well-known/acme-challenge/{а здесь сам код}, и если получает ожидаемый ответ - то считает, что домен проверен.
Let's Encrypt выпускает сертификат и предоставляет его серверу.

На самом деле все немного сложнее, но нам детали и не потребуются.

Что мы делаем и зачем

Нам понадобится один прокси-сервер (nginx) и правильная настройка DNS. Больше, удивительным образом, ничего. Прокси-сервер должен быть доступен из Интернет и иметь доступ во внутреннюю сеть (dual-homed).

Полагаем, что все наши сервера во внутреннем DNS прописаны по именам. Во внешнем DNS, в зоне mycompany.ru задаем имя для внешнего адреса прокси-сервера, пусть будет proxy. И там же для каждого сервера из внутренней сети делаем запись CNAME, указывающую на proxy.

Конфигурируем nginx, общая конфигурация самая обычная, нужные нам блоки server в контексте http выглядит так:

server {
    listen       80;
    server_name  .mycompany.ru;     # Принимаем любые имена в домене
    location /.well-known { 
        if ($request_method != GET) { # Разрешаем только метод GET
            return 444;               # иначе - сбрасываем TCP соединение
        }
        resolver 10.0.0.2 10.0.1.2; # Обязательно ипользуем внутренние DNS
        proxy_pass http://$host;    # проксируется на сервер внутрь сети с тем же именем
    }

    location / {                    # Все остальные запросы -
        return 444;                 # просто сбрасываем TCP соединение
        log_not_found off;          # и ничего не пишем в лог
        access_log off;
    }

}
server {                            # На все запросы по IP адресу без домена
    listen       80 default_server; # отвечаем сбросом TCP соединения
    server_name  _;
    return 444;
    log_not_found off;
    access_log off;
}

Кстати, если у вас уже есть dual-homed сервер с nginx для каких-то других задач, то эту конфигурацию можно просто добавить к нему, она не будет мешать обслуживанию других серверов даже с именами в том же домене.

Работает это очень просто:

Наш внутренний сервер посылает запрос, получает код авторизации и размещает его у себя как положено.
"Проверялка" Let's Encrypt разрешает запрошенное имя в адрес proxy и посылает туда запрос GET, естественно доменное имя указано в запросе.
Получив запрос, прокси еще раз разрешает доменное имя, но уже внутренним DNS и выполняет запрос на реальный сервер, получает ответ и отдает его "проверялке".
Проверка пройдена, наш внутренний сервер получает сертификат.

Вуаля! Все работает! Ставим на внутреннем сервере Certbot или активируем встроенную поддержку сертификатов Let's Encrypt у нужного нам софта - и погнали. Не забываем повесить задачу на автообновление сертификатов!

За, против и немного про безопасность

Преимущества:

Простота реализации. По плечу очень среднему админу.
Совместимость. Работают любые ACME-клиенты с проверкой по HTTP на всех платформах, в том числе родной Certbot, встроенные ACME клиенты (проверено на Proxmox), да и вообще нет ограничений по использованию ACME кроме верификации по HTTP. И да, работать должно не только с Let's Encrypt.
Минимальные усилия на изменения: чтобы Let's Encrypt стал доступен для любого сервера внутри - достаточно просто добавить CNAME для него во внешний DNS. Ну и сделать соответствующие ACME-настройки на самом сервере, конечно.

Недостатки:

Мы вроде как показываем имена внутренних серверов в Интернете. На самом деле - нет, если только внешний DNS настроен правильно и не позволяет кому попало забирать зону целиком, что является хорошей практикой независимо от целей.
UPDATE: Как правильно заметил в комментарии @HxShard , используя публичные сертификаты внутри сети мы неизбежно делаем доступными доменные имена узлов, для которых мы их получили, как минимум таким вот образом https://crt.sh/?q=habr.com. Тут уж придется каждому решить - насколько большой риск тем самым создается. Лично я оцениваю его как весьма небольшую цену за удобство, во всяком случае вряд ли именно это станет самым низким участком моего виртуального забора.
Теоретически, прокси-сервер, как любой dual-homed, создает угрозу. Но и меры защиты - самые обычные. Если они непонятны и вы не можете правильно настроить защиту для Linux + Nginx - то вам вообще не стоит иметь дела с серверами, подключенными к Интернету. Позовите взрослых пожалуйста!
Опять же, теоретически, существует возможность DoS на внутренний сервер при условии что его имя получено - путем заваливания его запросами в каталог /.well-known. Крайне маловероятный сценарий, но его можно легко купировать, ограничив скорость запросов на прокси. Это же nginx!
Внутренние серверы должны иметь доступ в Интернет. Но если это для вас проблема - то ниже покажу как ее решить.

К сожалению, Let's Encrypt не поддерживает и не публикует список собственных IP-адресов, поэтому ограничить обращение внутренних серверов наружу и запросы извне по IP - не получится.

И все же, изолированные сервера, сделаем?

Ценою усложнения схемы - сделаем и это. Дело в том, что ACME-клиент посылает запрос по HTTPs. С одной стороны - его тоже можно проксировать, но при этом "ломается" сертификат, и скорее всего ACME-клиент выдаст ошибку. SSL соединение нормально проксируется только на уровне TCP, но к счастью nginx и это умеет.

Нам понадобится:

По два внутренних IP адреса на каждый ACME сервис (для основного и staging).
"Перехватить" домен сервиса - либо путем записей в hosts либо на своем внутреннем DNS.
Настроить nginx для проксирования на уровне TCP.

Кстати: адреса API разных ACME-сервисов можно взять из скрипта acme.sh

Ок, делаем, на примере Let's Encrypt. Будем считать, что для внутренних интерфейсов прокси выделены адреса 10.0.1.34 и 10.0.1.35.

Перехват DNS

Перехват через hosts проще, но его надо не забыть сделать на каждом внутреннем сервере, добавив в файл строки:

10.0.1.34 acme-v02.api.letsencrypt.org
10.0.1.35 acme-staging-v02.api.letsencrypt.org

Перехват внутренним DNS сервером сложнее, но зато сделать его надо один раз и работать он будет для всех серверов. Для этого на внутреннем DNS создаем зону api.letsencrypt.org, и заводим в ней нужные хосты, пример файла зоны для BIND:

;Перехват api.letsencrypt.org
; SOA
api.letsencrypt.org.   3600     IN     SOA     localhost.      root.localhost. (
                                                2022122900
                                                28800
                                                7200
                                                604800
                                                3600
                                                )
;основной сервер
acme-v02                3600     IN     A      10.0.1.34

;staging сервер
acme-staging-v02        3600     IN     A      10.0.1.35

Вне зависимости от способа, проверяем результат пингуя с внутреннего сервера по именам acme-v02.api.letsencrypt.org и acme-staging-v02.api.letsencrypt.org, пинги должны проходить на .34 и .35 адреса соответственно. Значит, перехват DNS удался.

Настройка Nginx

Обратите внимание, что эти директивы должны находиться в контексте main, в то время как все привычные файлы конфигурации виртуальных хостов в каталоге "из коробки" уже находятся в контексте http. Поэтому надо либо добавлять в основной файл конфигурации /etc/nginx/nginx.conf, либо в каталог либо в отдельный файл и в правильном месте ставить include.

stream {
    resolver 8.8.8.8; # А вот здесь нам нужен DNS, способный разрешать имена в Интернете

    server { # Проксируем 443 порт на .34 адресе и отправляем на основной сервер 
        listen 10.0.1.34:443;
        proxy_pass acme-v02.api.letsencrypt.org:443;
    }

    server { # Проксируем 443 порт на .35 адресе и отправляем на stageing сервер
        listen 10.0.1.35:443;
        proxy_pass acme-staging-v02.api.letsencrypt.org:443;
    }
}

Ну вот и все! Теперь и серверы внутренние доступа наружу не имеют и Let's Encrypt на них работает.

P.S. Дед мой, добрая ему память, частенько говорил: "Кабы не клин да мох, да и плотник бы сдох!". Так и хочется перелицевать на "Кабы не nginx, да ???, так и сисадмин бы ???". Но вот что подставить? Предлагайте! :-)

Tags:

Hubs: