3.2.2. Аутентифікація організації та імені домену

Якщо Замовник подає запит на сертифікат, який буде містити інформацію про ідентифікацію суб'єкта, що складається лише з поле countryName, тоді Сертифікаційний центр SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) перевірити країну, пов'язану з суб'єктом, використовуючи процесс перевірки який відповідає вимогам розділу 3.2.2.3 і описаний в Полісі сертифікатів CA (CA’s Certificate Policy) і / або Положенні про сертифікацію (Certification Practice Statement - CPS). Якщо Заявник подає запит на сертифікат, який буде містити поле назва країни (countryName) та іншу інформацію про Суб'єкт, то Сертифікаційний центр SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) перевіряти особу Заявника, а також всі дані які вказані і запиті на сертифікат за допомогою процесу перевірки, що відповідає вимогам цього розділу 3.2.2.1, які описані в Полісі сертифікації (CA’s Certificate Policy) та / або Положенні про сертифікацію (Certification Practice Statement - CPS). Сертифікаційний центр SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) перевіряти будь-який документ, на який посилаються згідно з даним розділом, для виявлення змін або фальсифікації.

3.2.2.1. Ідентичність

Якщо інформація про ідентифікацію Суб'єкта включає назву або адресу організації, CA SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) перевіряти ідентифікацію та адресу організації та адресу заявника на приналежність Заявителю та її дійсність. CA SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) перевіряти особу та адресу Заявника, використовуючи документацію, надану, або шляхом спілкування з, принаймні, одним з наступних:

1.Державне управління, що є юрисдикцією територіі, де Замовник був офіційно зареєстрований, існуванє та визнається;
2.База даних третьої сторони, яка періодично оновлюється та вважається надійним джерелом даних;
3.Відвідування сайта Сертифікаційним центром або третьою стороною, яка виступає в якості агента для СЦ; або
4. Атестаційний лист

СЦ MAY (ВОЗМОЖНО, МОЖЕТ) використовувати ту саму документацію чи зв'язок, описані вище в пунктах 1-4, для ідентифікації Заявника та перевірки адреси заявника.

Альтернативно, СЦ MAY (ВОЗМОЖНО, МОЖЕТ) перевірити адресу Заявника (але не ідентичність Заявника) за допомогою рахунків за комунальні послуги, банківські виписки, виписки з кредитної картки, податковий документ, виданий урядом, або іншу форму ідентифікація, яку Сертифікаційний центр визначає як надійну.

3.2.2.2. DBA/ Торговая марка

Якщо інформація про ідентифікацію Суб'єкта включає в себе ідентифікаційний номер або торгову марку, CA SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) перевіряти право заявника використовувати DBA / торгову назву, використовуючи принаймні одне з наступного:

1. Документація видана або надана шляхом спілкування з державною установою, під юрисдикцією якої Заявника було створено, а також визнається його існування;
2. Надійне джерело даних;
3. Спілкування з державною установою, відповідальною за управління такими базами даних або торговими назвами;
4. Атестаційний лист у супроводі документальної підтримки; або
5. Рахунок за отримані послуги, банківська виписка, виписка по кредитній картці, державний податковий документ або інша форма ідентифікації, що ЦС визначає як надійний.

3.2.2.3. Верифікація країни

Якщо заповнено поле назви країни countryName то сертфікаційний центр SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) перевірити звя'зок країни з Суб'єктом, використовуючи одне з наведених нижче:
(a) приналежність діапазону IP-адрес за країною для (i) або IP-адреси веб-сайту, як зазначено в запису DNS для веб-сайту (ii) або IP-адреса заявника;
(b) ccTLD запитуваного доменного імені;
(c) інформація, надана реєстратором доменного іменв;
(d) метод, визначений у розділі 3.2.2.1.

Центр сертифікації SHOULD (ДОЛЖЕН) реалізовувати процес екранування проксі-серверів, щоб запобігти приналежність IP-адрес іншим країнам, крім тих, де фактично знаходиться заявник.

3.2.2.4. Підтвердження володіння або контролю домену

Цей розділ визначає дозволені процедури та процедури для підтвердження права власності заявника або контролю над доменом.

ЦС SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) підтвердити, що до видачі сертифіката ЦС перевірив кожне окреме доменне ім'я (FQDN) перелічене в сертифікаті за допомогою принаймні одного з методів, перерахованих нижче.

Вже проведена перевірка повноважень Заявника може бути дійсною для видачі декількох сертифікатів протягом певного часу. Але в будь-якому випадку, перевірка обов'язково повинна бути ініційована протягом періоду часу, відповідно до вимог (розділ 4.2.1 цього документа) до видачі сертифіката. В процедурі перевірки домену термін «Заявник» включає материнську компанію заявника, дочірню компанію або афілійовану особу.

CA SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) вести облік того, який метод перевірки домену було проведено, включаючи відповідний номер версії BR, який вони використовували для затвердження кожного домену.
Примітка. FQDN можуть бути вказані в сертифікатах абонента з використанням dNSNames в розширенні subjectAltName або в сертифікатах Підпорядкованого CA в dNSNames в Name Constraints extension.

3.2.2.4.1 Перевірка заявника як доменного контакту

Підтвердження того, що заявник контролює FQDN та/або безпосередньо пов'язаний з доменним контактом у реєстратора доменних імен. Цей метод може використовуватися тільки в тому випадку, якщо:

1. СА посвідчує особу заявника відповідно до розділу 3.2.2.1 і повноваженнями представника заявника відповідно до розділу 3.2.5 або
2. СА посвідчує особу заявника відповідно до розділу 11.2 Правил видання EV SSL сертифікатів і агенціі підтвердження Сертифіката відповідно до розділу 11.8 Інструкції для EV сертифікатів; або
3. CA також є реєстратором доменних імен або філією реєстратора базового доменного імені.

Примітка. Після того, як FQDN було перевірено за допомогою цього методу, CA MAY (ВОЗМОЖНО, МОЖЕТ) також видавати сертифікати для інших субдоменних FQDN, які закінчуються цим FQDN. Цей метод підходить для перевірки домену для wildcard сертіфікатів. Для сертифікатів, випущених 1 серпня 2018 року або після цієї дати, цей метод SHALL NOT (НЕ РАЗРЕШАЕТСЯ, не должно быть) використовуватися для валідація і завершення перевірки з використанням цього методу SHALL NOT (НЕ РАЗРЕШАЕТСЯ, не должно быть) використовуватися для видачі сертифікатів.

3.2.2.4.2 Email, Fax, SMS, або паперовий лист, відправленний доменному контакту

Підтвердження контролю Заявником FQDN шляхом відправки коду у вигляді випадкового числа електронною поштою, факсом, SMS або поштовим відправленням і потім отримує підтверджуючу відповідь, використовуючи надісланий код. Згенеровний код MUST (НЕОБХОДИМО, обязательно должно быть) бути відправлений на адресу електронної пошти, номер факсу / SMS або поштову адресу, вказану як контакт домену.

Кожен електронний лист, факс, SMS або паперовий лист MAY (ВОЗМОЖНО, МОЖЕТ) підтвердити контроль та авторизацію над кількома доменними іменами.

CA MAY (ВОЗМОЖНО, МОЖЕТ) відправити електронну пошту, факс, SMS або поштові повідомлення, визначені в цьому розділі, кільком одержувачам за умови, що реєстр доменних імен визначає кожного одержувача як представника доменного імені FQDN, що підтверджується електронною поштою, факсом, SMS або поштою.

Випадкове значення коду SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) унікальним для кожного електронного листа, факсу, SMS або поштової пошти.

CA MAY (ВОЗМОЖНО, МОЖЕТ) повторно відправити електронну пошту, факс, SMS або поштову пошту повністю, включаючи повторне використання випадкового числа, за умови, що весь вміст і одержувач (адреси) зв'язку залишаються незмінними.

Значення коду SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) залишатися дійсним для використання в підтвердженні відповіді не більше ніж на 30 днів після його створення. Положення CPS MAY (ВОЗМОЖНО, МОЖЕТ)> вказати більш короткий термін дії для випадкових значень коду, і в цьому випадку CA MAY (ВОЗМОЖНО, МОЖЕТ) слідувати даним, які вказано в документі CPS.

Примітка. Після того, як FQDN було перевірено за допомогою цього методу, CA MAY (ВОЗМОЖНО, МОЖЕТ) також видавати сертифікати для субдоменів цього FQDN. Цей метод підходить для перевірки доменного імені для випуска субдоменного wildcard сертифіката SSL.

3.2.2.4.3 Телефонний зв'язок із доменним контактом

Підтвердженням Заявника контролю над FQDN, шляхом контакту за номером телефону реєстратора доменного імені та отримання відповіді, що підтверджує запит заявника на перевірку FQDN. CA MUST (НЕОБХОДИМО, обязательно должно быть) зробити дзвінок на номер телефону, який ідентифікується реєстратором імені домену як доменний контакт. Кожен телефонний дзвінок SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) зроблений на один номер, і MAY (ВОЗМОЖНО, МОЖЕТ) підтвердити контроль над кількома FQDN, якщо це передбачено що номер телефону визначається реєстрантом домену як діючий спосіб контакту для кожного базового домену

Примітка. Після того, як FQDN було перевірено за допомогою цього методу, CA MAY (ВОЗМОЖНО, МОЖЕТ) також видавати сертифікати для субдоменів цього FQDN. Цей метод також підходить для перевірки доменного імені для випуска wildcard сертифіката ССЛ.

3.2.2.4.4 Конструкція Email для доменного контакта

Підтвердження контролю Заявника над FQDN шляхом (i) надсилання повідомлення електронної пошти на одну або декілька адрес, створених використовуючи 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster' @FQDN (ii) яке включає значення випадкового числа в електронному листі та (iii)та отримання підтвердженої відповіді від Заявника з використанням цього випадкового числа.

Кожен електронний лист MAY (ВОЗМОЖНО, МОЖЕТ) підтвердити керування над кількома FQDN, за умови, що ім'я домену використовується в електронній пошті - це ім'я домену авторизації для кожного підтвердженого FQDN.

Випадкове значення SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) бути унікальним в кожному листі.

електронний лсит MAY (ВОЗМОЖНО, МОЖЕТ) повторно надісланий повністю, включаючи повторне використання випадкового числа, за умови, що зміст і одержувач SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) незмінними.

Значення випадкового числа SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) залишатися дійсним для використання в підтвердженні відповіді не більше ніж на 30 днів після його створення. Положення CPS MAY (ВОЗМОЖНО, МОЖЕТ) вказати більш короткий термін дії для випадкових значень, і в цьому випадку CA MAY (ВОЗМОЖНО, МОЖЕТ) слідувати даним, які вказано в документі CPS.

Примітка. Після того, як FQDN було перевірено за допомогою цього методу, CA MAY (ВОЗМОЖНО, МОЖЕТ) також видавати сертифікати для субдоменів цього FQDN. Цей метод підходить для перевірки доменного імені для випуска wildcard сертифіката ССЛ.

3.2.2.4.5 Документ авторизації домену

Підтвердження контролю Заявника над FQDN, спираючись на документальне підтвердження того що Заявник дійсно запитує сертифікат, що міститься в Документі авторизації домену. Документ авторизації домену MUST (НЕОБХОДИМО, обязательно должно быть) підтверджувати, що повідомлення надійшло з доменного контакту. Сертифікаційний центр MUST (НЕОБХОДИМО, обязательно должно быть) перевіряти, чи документ авторизації домену (i) датований відповідно до дати перевірки домену або після неї або (ii) дані WHOIS домену істотно не змінилися з моменту створення Авторизаційного документу

Для сертифікатів, випущених 1 серпня 2018 року або після цієї дати, цей метод SHALL NOT (НЕ РАЗРЕШАЕТСЯ, не должно быть) використовуватися для валідації і завершення перевірки з використанням цього методу SHALL NOT (НЕ РАЗРЕШАЕТСЯ, не должно быть) використовуватися для видачі сертифікатів.

3.2.2.4.6 Підтвердження на веб-сайті

Підтвердженням того, що заявник контролює FQDN, підтверджуючи одне з наще наведеного в директорії "/.wellknown/pki-validation "або за іншим шляхом, зареєстрованим в IANA з метою перевірки домену на ім'я домену авторизації, доступне CA через HTTP / HTTPS через авторизований порт:

1. Обов'язкова наявність всього змісту необхідного контенту, що міститься у файлі. Весь Необхідний зміст веб-сайту MUST_NOT (НЕДОПУСТИМО, обязательно не должно быть) міститись у запиті, який використовується для завантаження файлу чи веб-сторінки, або
2. Наявність токена запиту або випадкової величини, що міститься у вмісті файлу, де є Токен запиту або випадкове значення MUST_NOT (НЕДОПУСТИМО, обязательно не должно быть) з'являтися в запиті.

Якщо використовується випадкове значення, CA SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) надавати випадкове число, унікальне для запиту сертифіката та SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) не використовувати випадкове число після більш (i) 30 днів або (ii) якщо заявник подав запит на сертифікат и часові рамки, дозволені для повторного використання перевіреної інформації, відповідного Сертифікату (наприклад, в Розділ 4.2.1 цих Правил або розділ 11.14.3 Керівних принципів EV).

Примітка. Приклади Токенів запиту включають, але не обмежуються: (i) хеш відкритого ключа; (ii) хеш інформації про відкритий ключ [X.509]; та (iii) хеш CSR PKCS # 10. Ідентифікатор запиту також може бути об'єднано з міткою часу або іншими даними. Якщо ЦС вирішив завжди використовувати хеш PKCS # 10 CSR як Токен запиту, при цьому не бажає використовувати мітку часу, але хоче дозволити повторне використання ключа сертифіката Заявник повинен використовувати пароль при створенні CSR під час його генерування через OpenSSL для забезпечення унікальності навіть якщо суб'єкт та ключ ідентичні для наступних запитів. Ця спрощена команда створюэ Токензапиту, що мыститиь мытку часу та хеш запиту CSR. Наприклад echo date -u +% Y% m% d% H% M sha256sum Примітка. Після того, як FQDN було перевірено за допомогою цього методу, CA MAY (ВОЗМОЖНО, МОЖЕТ) також видавати сертифікати для субдоменів цього FQDN. Цей метод також підходить для перевірки доменного імені для випуска wildcard SSL сертифіката.

3.2.2.4.7 DNS записи

Підтвердженням того, що заявник контролює FQDN, є наявність спеціального коду, що являє собою випадкове значення або Токена запиту для запису в DNS CNAME, TXT або CAA для 1) доменного імені авторизації; або 2) доменне ім'я авторизації, яке попередньо позначено міткою, яка починається з символу підкреслення.

Якщо використовується випадкове значення, CA SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) надати випадкове число, унікальне для запиту сертифіката яке не може бути використано якщо з його надання минуло (і) 30 днів або (ii) якщо Заявник підтвердив запит на отримання сертифікату, часові рамки, дозволені для повторного використання перевіреної інформації, відповідного Сертифікату (наприклад, у Розділі 3.3.1 цих Правил або розділу 11.14.3 Керівних принципів EV).

Примітка. Після того, як FQDN було перевірено за допомогою цього методу, CA MAY (ВОЗМОЖНО, МОЖЕТ) також видавати сертифікати для субдоменів цього FQDN. Цей метод також підходить для перевірки доменного імені для випуска wildcard SSL сертифіката.

3.2.2.4.8 IP адреса

Підтвердженням того, що Заявник контролює FQDN, підтверджуючи, що Заявник контролює IP-адресу відкликаєтсья з DNS-пошуку для записів A або AAAA для FQDN відповідно до розділу 3.2.2.5.

Примітка. Після того, як FQDN було перевірено за допомогою цього методу, CA MAY_NOT також видавати сертифікати для іншіх FQDN, які закінчуються усіма мітками перевіреного FQDN, якщо тільки CA не виконує окрему перевірку для цього FQDN за допомогою авторизованого методу. Цей метод НЕ придатний для перевірки імен Wildcard (субдоменних) сертифікатів.

3.2.2.4.9 Test Certificate

Підтвердженням, що заявник контролює FQDN, підтверджуючи наявність тестового сертифікату, термін якого ще не закінчився виданий ЦС по доменному імені авторизації і доступний ЦА через TLS по авторизованому порту для випуску сертифіката з тим самим відкритим ключем, що і в тестовому сертифікаті.

Примітка. Після того, як FQDN було перевірено за допомогою цього методу, CA MAY (ВОЗМОЖНО, МОЖЕТ) також видавати сертифікати для субдоменів цього FQDN. Цей метод підходить для перевірки доменного імені для випуска wildcard SSL сертифіката.

3.2.2.4.10. TLS за допомогою випадкового числа

Підтвердження того що Заявник контролю домен через наявність спеціального коду (випадкового числа) що пов'язане з сертифікатов на авторизоване доменне ім'я, який є доступним для сертифікаційного центру через TLS over за авторизованим портом.

3.2.2.4.11 Будь-який інший метод

Цей метод було видалено і він більше MUST_NOT (НЕДОПУСТИМО, обязательно не должно быть) використовуватись.

3.2.2.4.12 Перевірка заявника як доменного контакту

Підтвердження того, що заявник контролює FQDN, підтверджуючи, що заявником є контакт домену. Цей метод може використовуватися тільки в тому випадку, якщо ЦС також є Реєстратором доменних імен або Афілійованою особою Реєстратора

Примітка. Після того, як FQDN було перевірено за допомогою цього методу, CA MAY (ВОЗМОЖНО, МОЖЕТ) також видавати сертифікати для субдоменів цього FQDN. Цей метод підходить для перевірки доменного імені для випуска wildcard SSL сертифіката.

3.2.2.5. Аутентификация для IP-адреса

Для кожної IP-адреси, зазначеної в Сертифікаті, CA SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) підтверджувати, що на дату видачі Сертифіката Заявник має контроль над IP-адресою за допомогою:

1. Наявність у заявника практичного контролю над IP-адресою шляхом демонструється виконанням узгодженої зміни інформації на веб-сторінці в Інтернеті, визначеної єдиним ідентифікатором ресурсу, що містить IP-адресу;
2. Отримання документації щодо присвоєння IP-адрес з авторитетного центру Інтернету (IANA) або Регіональний інтернет-реєстр (RIPE, APNIC, ARIN, AfriNIC, LACNIC)
3. Виконання пошуку по зворотному IP-адресою, а потім перевірка контролю над отриманими доменним ім'ям в розділі 3.2.2.4; або
4. Використовуючи будь-який інший метод підтвердження, за умови, що CA веде документально підтверджені докази того, що метод підтвердження встановлює, що Заявник має контроль над IP-адресою, по крайней мере, такий же рівень впевненості, як і наведені раніше методи.

Примітка. IP-адреси можуть бути перераховані в кліентських сертифікатах за допомогою IP-адреси в розширенні subjectAltName або в підпорядкованих сертифікатах CA через IPAddress в permittedSubtrees в розширенні імен.

3.2.2.6. Перевірка для субдоменних ДВ сертификатів Wildcard Domain Validation

Перед видачею SSL сертифікату з міткою Wildcard (*) в CN або subjectAltName типу DNS-ID, CA MUST (НЕОБХОДИМО, обязательно должно быть) встановити і слідувати документованої процедурі [^ pubsuffix], яка визначає, чи є символ субдомена відбувається в позиції першого рівня зліва від мітки з контролем реєстру або «відкритого суфікса», що представляють собою доменну зону (наприклад, «* .com», «* .co.uk», див. RFC 6454 Розділ 8.2

Якщо wildcard мітка знаходиться одразу від доменної зони (контрольованого реєстру або публичного суфіксу), CAs MUST (НЕОБХОДИМО, обязательно должно быть) відмовити від випуску сертифіката, якщо тільки Заявник не доведе що він законно та офіційно контролює всю доменну зону. (наприклад ЦС MUST_NOT (НЕДОПУСТИМО, обязательно не должно быть) видати сертифікат для «* .co.uk» або «* .local», але MAY (ВОЗМОЖНО, МОЖЕТ) видати дійсний сертифікат для «* .example.com» для Example Co..). До 1 вересня 2013 року кожен CA MUST (НЕОБХОДИМО, обязательно должно быть) відмінити будь-який дійсний сертифікат якщо він не відповідає вимогам цього пункту.

[^pubsuffix] Визначення того, що «контролюється реєстром» в порівнянні з зареєстрованої частиною коду країни простір імен верхнього рівня не стандартизовано на момент написання і не є властивістю DNS. Поточна найкраща практика полягає в тому, щоб проконсультуватися з «публічним списком суфікса», таким як http://publicsuffix.org/ (PSL), і регулярно отримувати нову копію. Якщо ви використовуєте PSL, CA SHOULD (ДОЛЖЕН) проконсультуватися тільки з розділами «ICANN DOMAINS», а не розділ «ПРИВАТНІ ДОМЕНИ». PSL регулярно оновлюється, щоб утримувати нові gTLD, делеговані ICANN, які перераховані в розділі «ДОМЕНИ ICANN». CA не забороняє видавати сертифікат Регистранту всього gTLD, за умови, що контроль над всім простором імен продемонстрований належним чином.

3.2.2.7.Точність джерела даних

Перед використанням будь-якого джерела даних, як надійного джерела даних, CA SHALL (РАЗРЕШАЕТСЯ, НУЖНО, должно быть) оцінювати джерело для його надійності, точності, і стійкість до змін чи фальсифікацій. CA SHOULD (ДОЛЖЕН) розглядати наступне під час його оцінки:

1. Як давно розміщено інформацію, що надається,
2. Частота оновлень джерела інформації,
3. Постачальник даних і мета збирання даних,
4. Доступність даних для громадськості та
5. Відносна складність для фальсифікації або зміні даних.

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

3.2.2.8. CAA запис

Цей розділ набрав чинності з 8 вересня 2017 року.

Як складова частина процесу видачі сертифікату, CA MUST (НЕОБХОДИМО, обязательно должно быть) перевіряти записи CAA і слідувати інструкціям з обробки, для кожного з них dNSName у розширенні subjectAltName виданого сертифікату, як зазначено в RFC 6844 із змінами, внесеними Errata 5065 (Додаток А). Якщо ЦС видає, він MUST (НЕОБХОДИМО, обязательно должно быть) робити це в межах TTL запису CAA, або протягом 8 годин, залежно від того, що більше.

Це положення не перешкоджає ЦС перевіряти записи CAA в будь-який інший час.

Під час обробки записів CAA, ЦС MUST (НЕОБХОДИМО, обязательно должно быть) обробляти теги властивостей issue, issuewild та iodef, як зазначено в RFC 6844, хоча вони не зобов'язані діяти на вміст тегу властивості iodef. Додаткові властивості тегів MAY (ВОЗМОЖНО, МОЖЕТ) підтримуватися, але MUST_NOT (НЕДОПУСТИМО, обязательно не должно быть) конфліктувати або замінювати обов'язкові властивості тегів, наведені в цьому документі. ЦС MUST (НЕОБХОДИМО, обязательно должно быть) дотримуватись критичної позначки, та не випускати сертифікат, якщо вони зіткнулися з невизначеними тегами із встановленою позначкою. ЦС MAY (ВОЗМОЖНО, МОЖЕТ) розглядати непустий набр записів CAA Resource Record, що не містить жодних властивих тегів (і також не містить тегів issueswild при обробці CAA для доменного імені "Wildcard") як дозвіл на видачу, за умови, що жоден із записів в наборі записів ресурсів CAA забороняє видавати сертифікат.

RFC 6844 містить вимогу що ЦС MUST_NOT (НЕДОПУСТИМО, обязательно не должно быть) видавати сертифікат за виключенням випадків коли (1) запит сертифіката відповідає застосованому ресурсу набору записів CAA (Resource Record) або (2) застосовується виняток, зазначений у відповідній заяві про сертифікатну політику або сертифікацію ". Для випусків, що відповідають цим Базовим вимогам, ЦС MUST_NOT (НЕДОПУСТИМО, обязательно не должно быть) покладатися на будь-які винятки, зазначені в їх CP або CPS, якщо вони не є одним з наступних:

• Перевірка CAA необов'язкова для сертифікатів, для яких було створено попередній сертифікат прозорості сертифікатів та зареєстровано принаймні два загальнодоступні журнали, для яких було перевірено CAA.
• Перевірка CAA є необов'язковою для сертифікатів, виданих технічно обмеженим субординованим сертифікатом CA, як зазначено в розділі 7.1.5 Базових вимог. де відсутність перевірки CAA є явним договірним положенням у контракті з заявником
• Перевірка CAA не є обов'язковою, якщо CA або Affiliate CA є DNS-оператором (як визначено в RFC 7719) DNS домену.

ЦС дозволяється розглядати запит на відмову в пошуку як дозвіл на випуск, якщо:

• Відмова виходить за межі інфраструктури ЦА;
• Пошук було повторено, принаймні один раз; і
• У зоні домену немає домену перевірки DNSSEC на корінь ICANN.

ЦС MUST (НЕОБХОДИМО, обязательно должно быть) документувати потенційну видачу, якщо вона не відбулася через запобіжний запит CAA, достатньо докладно, щоб надати зворотний зв'язок CAB Forum з обставин і SHOULD (ДОЛЖЕН) відправляти повідомлення про такі запити про видачу контактним особам, зазначеним у CAA iodef запис (и), якщо є. Очікується, що CA не підтримувати інші схеми URL у запису iodef, окрім mailto: або https :.