Комментарии 15
А почему ACME не использовали?
В любом случае, статья скорее туториал, а не отражение конкретного эпизода из опыта. Поскольку, не у всех это в инфре есть, а частенько админы гитлабов и кубернетисов не админят свой удостоверяющий центр, то это может быть в принципе недоступно.
Не совсем понимаю вас. В статье ведь не шло речи о подписи, только о доставке существующих?
Дано:
1. У нас есть процесс, который обращается к сервису по зашифрованному каналу с использованием сертификатов.
2. У сервиса есть цепочка подписи сертификатов, если мы доверяем хотя бы одному сертификату из цепочки, то связь помечается доверенной и происходит обмен информацией.
Проблема:
У нас в перечне доверенных сертификатов нет ни одного сертификата из цепочки сервиса, из-за этого связь является не доверенной и прекращается (можем конечно игнорировать отсутствие сертииката).
Решение:
В лоб, добавить один из сертификатов в доверенные везде где нам необходимо. (Это самое идиотское, что можно сделать, но так все делают и я привык видеть такое решение)
Корректное решение: нам известно, что все сервисы имеют перечень корневых сертификатов и часто имеют процессы обновления этих перечней (например обновление пакета ca-certificates для линукс дистрибутивов). Можно контролировать сертификат сервиса, а не его клиентов и трудозатраты будут меньше. Мы возьмём и подпишем наш сертификат у ЦС чей корневой сертификат есть у всех и этот же сертификат подпишем у нашего ЦС организации. Есть исключения, но я о них умолчу с вашего позволения, чтобы не вводить низкокваллифицированных специалистов в заблуждения.
Малый недочёт этого подхода в том, что незачем подписывать сертификат в ЦС организации если мы уже подписали его в публичном ЦС. Более существенный недостаток в том, что публичный ЦС определённый сертификат может просто не подписать. Ну, допустим, какой нибудь test.internal.subdomain.company.com который вообще доступен только внутри сети организации по ip из rfc1918. Как проходить челленджи летсэнкрипта?
Челенджи можно пройти с помощью acme delegate, acme proxy на бастионе?
Одно кольцо, чтобы править всеми. (с)
Очень странно завязывать свою критическую инфраструктуру на внешние ресурсы, каковыми являются внешние УЦ.
С другой стороны, если мы работаем в vasya-roga-i-kopyta.ru, то в случае потери контроля над доменным именем (а именно по нему идут проверки при выдаче сертификатов) у нас проблемы существенно более серьезные, чем вся эта возня с сертификатами. Клиент не может к нам попасть — мы реально теряем деньги. Если же клиент попадает к злоумышленнику или фишеру (кто-то перехватил управление нашим доменом) — мы полностью теряем контроль над ситуацией
Плюс с перекрестной подписью
Мы возьмём и подпишем наш сертификат у ЦС чей корневой сертификат есть у всех и этот же сертификат подпишем у нашего ЦС организации.
у нас увеличивается сложность выпуска. Нельзя уже просто взять и перевыпустить сертификат. Отдельный вопрос про CRL процесс — это целая боль. А еще мои коллеги умудрились в случае Let's Encrypt лососнуть тунца, когда они нарвались на лимиты. Кто там говорил, что платные сертификаты это плохо? Плохо, но если есть регулярный процесс ревью их сроков и замены — жить можно
letsencrypt.org/docs/rate-limits
Это конечно достижимый предел, но так же можно запросить увеличение лимита.
При этом лимит не распространяется на продление сертификатов.
Могу заблуждаться, но мне казалось, ACME не столько про доверенные CA, сколько про выписку сертификатов подписанных каким-то CA?
ACME очень классная история. Я бы очень хотел увидеть ACME-совместимый сервер на базе MS CA или Vault PKI внутри периметра организации. Видимо, влажные мечты
А у вас в статье речь идет все же о сертификатах от УЦ.
я параноик
- curl http://pki.company.ru/api?name=RootCA -O /usr/local/share/ca-certificates/RootCA.crt
как в этом случае убедиться, что мы идем на pki.company.ru, а не на подмененный злоумышленником RootCA?
Но на деле, если внутри своей инфры кто угодно может угнать твой dns и подсунуть левый сертификат… ну хз. С одной стороны ты и так уже в жопе, а с другой — не придёт правильный сертификат, не отработает следующий же https запрос ещё куда-то и билд будет сломан. Поэтому паранойя полезная, но уязвимость не сама страшная.
Самоподписные сертификаты кровавого энтерпрайза против вашего лампового CI/CD