Глобальная проверка CAA-записей
Запись CAA (Certification Authority Authorization) — это критическое улучшение безопасности, представленное в RFC 6844 для укрепления инфраструктуры открытых ключей (PKI). Запись CAA позволяет администраторам доменов явно определять, каким именно центрам сертификации (Certificate Authorities, таким как Let's Encrypt, DigiCert или Sectigo) юридически разрешено выпускать сертификаты SSL/TLS для их инфраструктуры. Она действует как агрессивная защита периметра против мошеннических (rogue) или скомпрометированных центров сертификации, генерирующих мошеннические, доверенные сертификаты для атак man-in-the-middle.
Обязательные проверки перед выпуском
С 2017 года CA/Browser Forum обязал каждый коммерческий CA выполнять DNS-поиск записей CAA до выпуска любого сертификата. Когда автоматизированный клиент ACME или администратор запрашивает сертификат, CA опрашивает зону. Если записи CAA не существует, CA предполагает неявное разрешение и выдает сертификат. Однако, если запись CAA присутствует, и имя хоста запрашивающего CA (например, letsencrypt.org) не указано в Payload в явном виде, процесс выпуска жестко блокируется и прерывается мгновенно на уровне CA.
Tree-Climbing (Древовидный обход) и область применения
Сильным аспектом архитектуры CAA является ее логика парсинга «tree-climbing». Если администратор запрашивает сертификат для глубоко вложенного поддомена (например, api.staging.example.com), центр сертификации запросит этот точный узел на наличие записи CAA. Если он его не найдет, он поднимается вверх (парсинг вверх), проверяя staging.example.com, и, наконец, apex example.com. Это означает, что одна запись CAA, развернутая на корневом домене, действует как общая политика безопасности, автоматически каскадно спускаясь и защищая каждый поддомен ниже от несанкционированного выпуска.
Отладка сбоев автоматического обновления
Хотя записи CAA радикально улучшают безопасность, они являются ведущей причиной внезапных, тихих сбоев SSL в современных конвейерах (pipelines) DevOps. Если компания переключается с ручного Wildcard сертификата, выданного DigiCert, на автоматическое обновление Let's Encrypt через Kubernetes cert-manager, но забывает обновить свои ограничительные записи CAA, бот обновления завершится неудачей. CA вернет ошибку авторизации, и в конечном итоге активный сертификат истечет, вызывая предупреждения в браузере для всех конечных пользователей. Кроме того, администраторы могут настроить тег iodef в рамках Payload CAA, предписывая CA отправлять автоматическое электронное письмо или webhook-оповещение команде безопасности всякий раз, когда происходит заблокированная попытка выпуска.