TLS-сертификаты в эксплуатации
Сертификат - это документ, который подтверждает, что домен принадлежит именно этому сайту, и подписан доверенным центром сертификации. Выпустил сертификат со сроком действия в прошлом и поднял с ним сервер. Клиент, которому этот центр известен и доверен, отвечает «certificate has expired» и соединение не устанавливает. Тот же клиент с отключённой проверкой спокойно получает страницу - и это ровно тот флаг, которым «чинят» такие аварии в три часа ночи, снимая заодно всю защиту.
Стержень: сертификат перестаёт работать по календарю, а не по нагрузке, и продление должно быть автоматическим и проверяемым.
// Формулировки: «как устроена цепочка доверия?», «что делать с истёкшим сертификатом?», «что такое взаимная проверка?»
Цепочка доверия
Клиент доверяет не сертификату сайта, а корневым центрам из своего хранилища. Сертификат сайта подписан промежуточным центром, промежуточный - корневым. Проверяя, клиент строит эту цепочку до корня, и если хоть одного звена не хватает, доверия нет.
Отсюда самая частая авария выходного дня: сервер отдаёт только свой сертификат без промежуточного. Браузер открывает сайт, потому что держит запас промежуточных и умеет дотягивать недостающее; а вот клиенты из кода этого не делают и честно падают. Я строил такую цепочку сам и проверял оба случая на стенде.
// Поэтому в конфигурации веб-сервера всегда указывают файл с полной цепочкой, а проверяют это командой, которая показывает, сколько сертификатов сервер реально прислал. И проверяют с той же машины, откуда ходит клиент: у разных систем разные хранилища корней, и старая машина может не знать нового корневого центра.
- цепочка доверия
- путь от сертификата сайта через промежуточные к корню в хранилище клиента
- полная цепочка
- файл с сертификатом сайта и промежуточными; его и указывают серверу
Срок и автопродление
У сертификата есть даты начала и конца. Наш боевой выпущен 3 июля и действует до 1 октября - я посчитал, осталось 51 день. Три месяца это типичный срок для бесплатных центров, и вручную такое не продлевают: забудут в отпуске, и сайт ляжет в субботу.
Автопродление ставят сразу и с запасом: обновлять за 30 дней до конца, а не за один. Дальше - три вещи, без которых оно однажды не сработает. Мониторинг оставшихся дней как обычная метрика с алертом на пороге в две недели: это ловит и «продление молча падает третью неделю». Проверка после продления, что сервер действительно ПОДХВАТИЛ новый файл - многие серверы читают сертификат только при старте или по отдельной команде. И проверка внутренних сервисов наравне с внешним адресом: их сертификаты забывают чаще, потому что снаружи их никто не видит.
// Когда сертификат всё-таки истёк, лечение одно - выпустить новый и перечитать конфигурацию. Отключение проверки на клиенте лечит симптом ценой всей защиты: я показывал это на стенде, страница отдаётся, но соединение больше не защищено от подмены.
- автопродление
- автоматический выпуск нового сертификата заранее, за недели до конца
- перечитывание конфигурации
- сервер должен подхватить новый файл; сам он это делает не всегда
Взаимная проверка
В обычной схеме сертификат предъявляет только сервер, а клиент доказывает, кто он, паролем или токеном уже внутри защищённого канала. При взаимной проверке сертификат предъявляют обе стороны: сервер проверяет клиентский так же, как клиент проверяет серверный.
Применяют это между своими сервисами, где нет живых пользователей: сервис получает сертификат вместо пароля, и он же служит его личностью. Плюсы очевидны: нет общего секрета, доступ отзывается отзывом сертификата, а не сменой пароля у всех.
// Плата - управление жизненным циклом всех этих сертификатов. Их надо выпускать при появлении сервиса, продлевать автоматически (обычно сроками в часы, а не месяцы) и уметь отзывать. Ставят это обычно не руками, а прослойкой, которая делает выпуск и продление прозрачными для приложения. Без такой прослойки взаимная проверка превращается в постоянные аварии по истечению срока, только теперь во внутренней сети.
- взаимная проверка
- обе стороны предъявляют сертификаты; клиентский заменяет пароль
- жизненный цикл сертификата
- выпуск, продление и отзыв; без автоматики не работает
Как отвечать: «Сертификат истёк в субботу. Как чинить и как не повторить?»
Чиню выпуском нового и перечитыванием конфигурации сервера - и обязательно проверяю, что сервер действительно подхватил новый файл, а не держит в памяти старый. Отключение проверки на клиентах не рассматриваю: я показывал на стенде, что с этим флагом страница отдаётся, но защита от подмены пропадает целиком. Чтобы не повторилось, нужны четыре вещи. Автопродление за месяц до конца, а не за день. Метрика оставшихся дней и алерт на двух неделях - она ловит случай, когда продление молча падает третью неделю. Проверка после продления, что сервер перечитал файл. И покрытие внутренних сервисов наравне с внешним адресом: их сертификаты забывают чаще всего, потому что снаружи их никто не видит.
Ответ отделяет лечение от профилактики и явно отказывается от вредного быстрого решения. Пункт про внутренние сервисы показывает, что человек это уже проходил.
На чём валятся
- −Отдают сертификат без промежуточного: браузер работает, клиенты из кода падают.
- −Отключают проверку сертификата вместо починки цепочки.
- −Продлевают вручную и однажды забывают.
- −Ставят автопродление, но не мониторят оставшиеся дни: молчаливый сбой продления не виден.
- −Следят только за внешним адресом и забывают сертификаты внутренних сервисов.
Проверьте себя
Пять вопросов из банка по этой подтеме. Всего их 6, остальные разбираются в тренажёре.
- Сертификат просрочился в субботу, хотя автопродление настроено. Как такое допускают?A)Автопродление работает только для сертификатов на годB)Продление прошло, но браузеры кэшируют старую версию до перезапускаC)Продление молча падало, а срок никто не мониторилD)Срок действия считается от выпуска, а не от установки
показать ответ и разбор
+C)Продление молча падало, а срок никто не мониторил// разбор: Автопродление ломается тихо: изменился способ подтверждения владения доменом, закрылся порт для проверки, кончилось место, сервис не перечитал новый файл. Задание при этом «отработало». Потому кроме автоматики держат внешнюю проверку срока по факту — опрос живого эндпоинта с алертом за две-три недели до истечения — и следят, что после обновления файла сервис действительно перечитал сертификат.
- Внутри кластера включают взаимный TLS между сервисами. Что это даёт и чем оплачивается?A)Ускоряет соединения за счёт переиспользования сессий, но грузит процессорB)Стороны проверяют друг друга сертификатамиC)Заменяет сетевые политики и снимает нужду в нихD)Скрывает трафик от системы мониторинга, зато защищает от перехвата
показать ответ и разбор
+B)Стороны проверяют друг друга сертификатами// разбор: Обычный TLS проверяет только сервер: клиентом может быть кто угодно, кто дотянулся по сети. Взаимный добавляет клиентский сертификат — сервис знает, кто именно к нему пришёл, и на этом строит авторизацию. Цена — инфраструктура выпуска: свой удостоверяющий центр, короткие сроки, автоматическая ротация и отзыв. Потому обычно берут service mesh, который выдаёт и обновляет сертификаты сам.
- Приватный ключ от TLS-сертификата случайно утёк в публичный репозиторий. Насколько это серьёзно?A)Не страшно: сам сертификат публичный, его и так все видятB)Ключ скомпрометирован: отозвать и перевыпустить с новымC)Достаточно удалить файл из репозитория и его историиD)Проблема уйдёт сама, когда сертификат истечёт по сроку
показать ответ и разбор
+B)Ключ скомпрометирован: отозвать и перевыпустить с новым// разбор: Приватный ключ — это то, чем сервис доказывает свою подлинность. Его утечка позволяет выдавать себя за сервис (MITM, подмена) и расшифровывать перехваченный трафик (без forward secrecy). Поэтому ключ считают скомпрометированным: сертификат отзывают (revocation), перевыпускают с НОВЫМ ключом и раскатывают. Удаление файла из репозитория не откатывает утечку — ключ уже мог быть скачан. Сам сертификат при этом действительно публичен.
- Браузер ругается: сертификат валиден и доверен, но выдан на api.example.com, а сервис открывают как example.com. В чём дело?A)Истёк срок действия сертификата этой ночьюB)Не хватает промежуточного сертификата в цепочкеC)Часы на клиенте сбились и не совпали с серверомD)Имя запроса не входит в SAN сертификата
показать ответ и разбор
+D)Имя запроса не входит в SAN сертификата// разбор: TLS-клиент проверяет, что запрошенное имя хоста присутствует в поле SAN (Subject Alternative Name) сертификата. Сертификат на api.example.com не покрывает example.com (голый домен и www — разные имена), поэтому при заходе на example.com — ошибка несоответствия хоста, хотя сертификат валиден и доверен. Решают: выпустить сертификат со всеми нужными именами в SAN (или wildcard *.example.com + сам домен), либо ходить по правильному имени.
- Сертификат на кластере балансировщиков надо заменить до истечения, не роняя живые соединения. Как правильно?A)Выкатить новый сертификат на все терминаторы и мягко перечитать конфигB)Разом перезапустить все балансировщики с новым сертификатомC)Заменить сертификат на одном узле и ждать месяцD)Просто продлить срок в файле сертификата текстом
показать ответ и разбор
+A)Выкатить новый сертификат на все терминаторы и мягко перечитать конфиг// разбор: Замена сертификата без даунтайма: разложить новый сертификат и ключ на все терминаторы TLS (балансировщики/ingress) и сделать мягкий reload (nginx -s reload, hot reload) — процесс подхватывает новый сертификат, не разрывая уже открытые соединения. Делать это заранее, до истечения, автоматизированно (ACME/cert-manager) и с мониторингом срока. Короткоживущие сертификаты как раз вынуждают наладить эту автоматику.
дальше
Теорию прочитали. Навык ставится повторением
В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.