CAA (Certification Authority Authorization) — DNS-запис, який вказує, які центри сертифікації (CA) мають право видавати SSL-сертифікати для вашого домену. Якщо зловмисник спробує отримати SSL для вашого домену через неавторизований CA — CAA-запис заблокує видачу.
Навіщо потрібен CAA-запис
- Захист від шахрайського отримання SSL вашого домену
- Запобігання атакам типу «compromised CA»
- Обов'язковий для організацій з високими вимогами безпеки
- Рекомендований NIST і вимагається деякими стандартами
Синтаксис CAA-запису
# Дозволити лише Let's Encrypt
@ IN CAA 0 issue "letsencrypt.org"
# Дозволити Let's Encrypt і Sectigo
@ IN CAA 0 issue "letsencrypt.org"
@ IN CAA 0 issue "sectigo.com"
# Дозволити Wildcard лише від визначеного CA
@ IN CAA 0 issuewild "letsencrypt.org"
# Email для сповіщень про відмови
@ IN CAA 0 iodef "mailto:security@example.com"Популярні CA та їхні CAA-значення
| Центр сертифікації | CAA-значення |
|---|---|
| Let's Encrypt | letsencrypt.org |
| DigiCert | digicert.com |
| Sectigo (Comodo) | sectigo.com |
| GlobalSign | globalsign.com |
| Entrust | entrust.net |
Перевірка CAA-запису
dig example.com CAA
# Онлайн: caatest.co.ukissuewild для того самого CA. Без нього CA відмовить у видачі Wildcard, навіть якщо є звичайний запис issue.Часті помилки під час налаштування CAA
| Симптом / повідомлення | Причина | Рішення |
|---|---|---|
Let's Encrypt: Error creating new order :: Policy forbids issuing for this domain | CAA-запис дозволяє інший CA або взагалі не містить letsencrypt.org | Додати 0 issue "letsencrypt.org" у зону, зачекати на поширення TTL запису |
| Звичайний SSL видається, а Wildcard — ні | Є запис issue, але відсутній окремий issuewild для того самого CA | Додати 0 issuewild "letsencrypt.org" додатково до issue |
| CA видає сертифікат, хоча CAA явно забороняє | CAA перевіряється CA лише в момент видачі нового сертифіката — уже видані раніше сертифікати не відкликаються автоматично | Явно відкликати небажаний сертифікат через CA, якщо його видано до появи CAA |
| Кілька CAA-записів з різними CA конфліктують | Це не конфлікт — кілька записів issue працюють як дозвільний список (OR), а не як виключний | Якщо потрібно залишити лише один CA — видалити решту записів issue, а не додавати їх усі |
Прив'язка до акаунту Let's Encrypt через accounturi
Параметр accounturi у CAA-записі обмежує видачу сертифікатів не просто конкретним CA, а конкретним ACME-акаунтом усередині цього CA — навіть співробітник того самого CA не зможе видати сертифікат від чужого імені.
# Дозволити видачу лише визначеному ACME-акаунту Let's Encrypt
@ IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567"ID акаунту можна знайти у файлі regr.json клієнта Certbot або в логах ACME-клієнта під час першої реєстрації.
Перевірка перед видачею нового сертифіката
# Перевірити поточні CAA-записи
dig example.com CAA +short
# Перевірити, що запис видно з публічного резолвера, а не лише локально
dig @8.8.8.8 example.com CAA +short
# Тестовий запит сертифіката в staging-середовищі Let's Encrypt
certbot certonly --staging -d example.com- Якщо
digне повертає CAA — або запису немає взагалі, або він ще не поширився - Staging-середовище Let's Encrypt дає змогу перевірити весь ланцюжок без ризику впертися в ліміт видачі бойових сертифікатів (50 на тиждень на домен)
- Після додавання нового CAA-запису зачекайте щонайменше його TTL перед повторною спробою видачі
Коли CAA може завадити
- Зміна CA без оновлення CAA-запису — новий провайдер SSL не зможе видати сертифікат, поки в зоні лишається обмеження на старий CA
- Використання кількох сервісів для різних піддоменів (наприклад, CDN із власним SSL) — кожен CA, задіяний будь-яким піддоменом, має бути явно дозволений на рівні зони або конкретного піддомену
- Автоматична видача через сторонні платформи (Cloudflare, хостинг-панелі) — якщо CAA налаштовано вручну і він не включає CA цієї платформи, автоматизація почне повертати помилки видачі
- Делегування піддомену іншому DNS-провайдеру — CAA перевіряється в зоні того піддомену, який запитує сертифікат, а не лише в кореневій зоні, див. делегування піддомену
Успадкування CAA піддоменами
CAA-запис, встановлений у корені зони, автоматично поширюється на всі піддомени, якщо для них не задано власного CAA-запису. Власний запис піддомену повністю перевизначає запис батьківської зони, а не доповнює його.
| Де задано CAA | Чи діє на mail.example.com |
|---|---|
| Лише на @ (корінь) | Так, якщо у mail немає власного CAA |
| Окремо на mail.example.com | Так, діє лише запис піддомену, батьківський ігнорується |
Часті питання
Чи відкличе чинний сертифікат автоматично нова обмежувальна CAA-запис?
Ні, чинний сертифікат через нову CAA-запис автоматично не відкликається — перевірка CAA відбувається у центру сертифікації лише в момент видачі нового сертифіката, а не постійно для вже чинних. Коли старий сертифікат видано до появи обмеження, він продовжить працювати до завершення строку дії, доки його явно не відкличуть через сам центр сертифікації.
Чи перевіряють браузери відвідувачів CAA-запис під час кожного заходу на сайт?
Ні, браузери відвідувачів CAA-запис не читають і не перевіряють геть — ця перевірка стосується лише центрів сертифікації і виконується один раз, у момент запиту на видачу сертифіката. Для відвідувача CAA лишається цілковито невидимим технічним механізмом на боці DNS, а не частиною перевірки з'єднання, яку браузер виконує під час кожного відкриття сторінки.
Чи поширюється CAA-запис на поштові S/MIME-сертифікати, чи лише на SSL сайту?
Поширюється, коли область дії запису не обмежена явно тегом під конкретний тип сертифіката — стандартні теги issue і issuewild стосуються звичайних і wildcard TLS-сертифікатів, а для поштових S/MIME-сертифікатів існує власний окремий тег з іншим призначенням. Без правильного тега центр сертифікації, що відповідає за поштові сертифікати, здатен геть не враховувати вашу CAA-запис.
Скільки часу після зміни CAA-запису може минути, перш ніж центр сертифікації побачить нове значення?
Час залежить від значення TTL конкретного запису в зоні і від того, як часто резолвер центру сертифікації опитує DNS заново — доки старе значення кешоване десь по дорозі, центр сертифікації здатен бачити його замість актуального. Найнадійніший спосіб не гадати — зачекати на завершення TTL запису і лише тоді повторювати запит на видачу сертифіката.