Останнє оновлення: 16 серп. 2023 р. | Переглянути всю документацію

CAA - це тип запису DNS, який дозволяє власникам сайтів вказувати, яким центрам сертифікації (ЦС) дозволено видавати сертифікати, що містять їхні доменні імена. Вперше він був стандартизований у 2013 році, а версія, яку ми використовуємо сьогодні, була стандартизована у 2019 році RFC 8659 та RFC 8657. За замовчуванням, кожен публічний центр сертифікації може випускати сертифікати для будь-якого доменного імені в публічному DNS, за умови, що вони підтверджують контроль над цим доменним ім’ям. Це означає, що якщо є помилка в будь-якому з багатьох процесів перевірки публічних центрів сертифікації, це може вплинути на кожне доменне ім’я потенційно може постраждати. CAA надає власникам домену можливість зменшити цей ризик.

Використання CAA

Якщо ви не дбаєте про CAA, то вам, як правило, не потрібно нічого робити (але дивіться нижче на помилки CAA). Якщо ви хочете використовувати CAA, щоб обмежити сертифікати авторизації, яким дозволено видавати сертифікати для вашого домену, вам потрібно буде використовувати DNS-провайдера, який підтримує налаштування записів CAA. Список таких провайдерів можна знайти на SSLMate’s CAA сторінці. Якщо ваш провайдер є у списку, ви можете скористатися Генератором Записів SSLMate’s CAA для створення набору записів CAA із переліком центрів сертифікації (CAs), які ви хочете дозволити.

Де поставити запис

Як правило, вам потрібно встановити записи CAA на вашому зареєстрованому домені (наприклад, “example.org” або “mysite.co.uk”). Таким чином, вони застосовуються як до цього домену, так і до будь-яких субдоменів, які ви створюєте під ним, наприклад, “community.example.org”.

Зверніть увагу, що центр сертифікації завжди поважатиме запис CAA найближчий до доменного імені, для якого він випускає сертифікат. Отже, якщо ви запитуєте сертифікат для “www.community.example.org”, центр сертифікації перевірить “www.community.example.org”, потім “community.example.org”, потім “example.org”, зупинившись на першому знайденому записі CAA.

Це означає, що ви можете перевизначити CAA для піддоменів. Наприклад, уявіть, що ви розміщуєте “example.org” самостійно, а “api.example.org” - у хмарного провайдера. Ви можете використовувати CAA-запис на “example.org”, щоб вказати, що тільки Let’s Encrypt може випускати сертифікати для цього домену та всіх його піддоменів, а також використовувати CAA-запис на “api.example.org”, щоб скасувати це і дозволити хмарному провайдеру випускати сертифікати для цього одного піддомену.

Зауважте також, що перевірка CAA слідує за перенаправленнями CNAME, як і всі інші DNS-запити. Якщо “community.example.org” є CNAME для “example.forum.com”, то CA буде поважати будь-які записи CAA, встановлені на “example.forum.com”. Доменне ім’я із записом CNAME не може мати інших записів, тому не може бути конфліктів між записами CAA на оригінальному імені та записами CAA на об’єкті перенаправлення.

Що вносити до запису

Усі записи CAA мають однаковий базовий формат:

CAA <flags> <tag> <value>

Прапори є цілим числом і майже завжди мають бути цілим числом 0, що означає, що прапори не встановлено. За бажанням, ви можете встановити прапори на ціле число 128, що вказує на те, що встановлено “критичний біт”, і що центри сертифікації повинні негайно зупинитися і не видавати сертифікат, якщо вони не розпізнають вміст поля тегу.

Тег - це рядок, що вказує на тип запису CAA: issue або issuewild у більшості випадків. Більше про це нижче.

Нарешті, значення - це рядок, що містить щонайбільше один ідентифікатор ЦС (наприклад, “letsencrypt.org”) і деякі необов’язкові параметри, розділені крапкою з комою, які також обговорюються нижче.

Властивості issue та issuewild

Записи з тегом issue просто контролюють, чи може центр сертифікації випускати сертифікати для цього домену та його піддоменів. Зазвичай це єдиний запис, який вам потрібен, оскільки він контролює як звичайну (наприклад, “example.org”), так і шаблонну (наприклад, “*.example.org”) видачу за відсутності будь-яких інших записів. Ви можете контролювати, який центр сертифікації може видавати сертифікати для цього домену, ввівши ідентифікаційне доменне ім’я цього центру сертифікації в частину значення запису CAA.

Записи з тегом issuewild контролюють, чи може центр сертифікації випускати сертифікати wildcard (наприклад, “*.example.org”). Вам потрібно використовувати записи issuewild, тільки якщо ви хочете отримати різні дозволи для видачі підставних і не підставних символів.

Зверніть увагу, що ви можете мати декілька записів з однаковим типом властивості, і вони є адитивними: якщо будь-який з цих записів дозволяє ЦС видавати, то він є дозволеним.

Зашифруймо ідентифікаційне доменне ім’я для CAA letsencrypt.org. Це офіційно задокументовано в Розділі 4.2.1 нашого CP/CPS.

Параметр validationmethods

Цей параметр можна розмістити після ідентифікаційного доменного імені ЦС, щоб контролювати методи перевірки, які ЦС може використовувати для підтвердження контролю над доменом. Це може бути використано, щоб обмежити перевірку методами, яким ви більше довіряєте. Наприклад, якщо ви хочете обмежити використання ЦС лише методом TLS-ALPN-01, ви можете додати ;validationmethods=tls-alpn-01 до значення запису CAA.

Let’s Encrypt розпізнає наступні методи валідації рядків:

• http-01
• dns-01
• tls-alpn-01

Параметр accounturi

Цей параметр можна розмістити після ідентифікаційного доменного імені центру сертифікації, щоб контролювати, які облікові записи ACME можуть запитувати видачу для цього домену. Це може бути використано для того, щоб хтось, хто тимчасово захопив ваш домен, але не має доступу до ключа вашого облікового запису ACME, не зміг випустити зловмисні сертифікати.

Нехай URL облікового запису Let’s Encrypt має вигляд https://acme-v02.api.letsencrypt.org/acme/acct/1234567890, де цифри в кінці - це ваш ідентифікатор облікового запису.

Приклади

Простий CAA-запис, який дозволяє Let’s Encrypt видавати для “example.org”, може виглядати так:

example.org         CAA 0 issue "letsencrypt.org"

Складніший набір рекордів CAA може виглядати так:

example.org         CAA 0 issue "myca.org;validationmethods=dns-01"
example.org         CAA 0 issuewild "myca.org"
example.org         CAA 128 issue "otherca.com;accounturi=https://otherca.com/acct/123456"

У цьому прикладі MyCA може видавати для “example.org”, але тільки з використанням методу перевірки DNS-01. Він також може випускати wildcard-сертифікати, використовуючи будь-який метод перевірки. Нарешті, OtherCA також може видавати сертифікати, але тільки якщо запит надходить з номера облікового запису 123456, і тільки якщо OtherCA розпізнає і знає, як правильно обробляти обмеження accounturi.

CAA помилки

З того моменту, як Let’s Encrypt перевіряє записи CAA, перед кожним виданим нами сертифікатом, іноді ми отримуємо помилки навіть для доменів, у яких не встановлено жодних записів CAA. Коли ми отримуємо помилку, то неможливо визначити, чи нам дозволено видавати її для відповідного домену, оскільки можуть бути присутні записи CAA, які забороняють видачу, але не відображаються через помилку.

Якщо ви отримуєте помилки, пов’язані з CAA, спробуйте ще кілька разів порівняти з нашим середовищем постановки, щоб перевірити, чи є вони тимчасовими чи постійними. Якщо вони постійні, вам потрібно буде звернутися до свого DNS-провайдера або змінити провайдера. Якщо ви не впевнені, хто ваш DNS-провайдер, то зверніться до свого хостинг-провайдера.

Деякі DNS-провайдери, які не знайомі з CAA, спочатку відповідають на повідомлення про проблеми: “Ми не підтримуємо записи CAA.” Вашому DNS-провайдеру не потрібно спеціально підтримувати записи CAA; він повинен лише відповідати NOERROR для невідомих типів запитів (включно з CAA). Повернення інших кодів операцій, включаючи NOTIMP, для невизнаних q-типів є порушенням RFC 1035 і воно має бути виправлене.

SERVFAIL

Однією з найпоширеніших помилок, з якими стикаються люди є SERVFAIL. Найчастіше це свідчить про помилку перевірки DNSSEC. Якщо ви отримуєте помилку SERVFAIL, першим кроком має стати використання налагоджувача DNSSEC, такого як dnsviz.net. Якщо це не спрацює, можливо, ваші сервери імен генерують неправильні підписи лише тоді, коли відповідь порожня. А відповіді CAA зазвичай порожні. Наприклад, у PowerDNS була ця помилка у версії 4.0.3 і нижчих.

Якщо у вас не ввімкнено DNSSEC і ви отримуєте SERVFAIL, другою імовірною причиною є те, що ваш авторитетний сервер імен повернув NOTIMP, що, як описано вище, є порушенням RFC 1035; натомість він має повернути NOERROR з порожньою відповіддю. У цьому випадку надішліть повідомлення про помилку або запит у службу підтримки своєму DNS-провайдеру.

Тож, SERVFAIL може бути спричинений перебоями на ваших авторитетних серверах імен. Перевірте записи NS для ваших серверів імен і переконайтеся, що кожен сервер доступний.

Час очікування

Іноді CAA запитує час очікування. Себто, авторитетний сервер імен не відповість навіть після декількох спроб. Найчастіше це стається, коли на вашому сервері імен стоїть неправильно налаштований брандмауер, який відкидає DNS-запити з невідомими q-типами. Зверніться до служби підтримки вашого DNS-провайдера і запитайте, чи налаштовано у нього такий брандмауер.