Defaults.Exposed › Поправки › CAA records

Как да поправите CAA records

CAA запис е кратка инструкция в настройките на домейна ви, назоваваща кои сертификатни компании имат право да издават 'катинар' сертификат за сигурност за вашия уебсайт. С активиран, никоя друга компания не може тихо да създаде валиден сертификат от ваше наименование.

Заключение за вашия бизнес: Без CAA запис, почти всяка от стотиците сертификатни компании по света може да издаде истински, напълно доверен катинар сертификат за вашия домейн — позволявайки на измамник да постави безупречен, напълно 'сигурен' клонинг на сайта ви, събиращ данните за влизане и картите на клиентите ви, без нищо на екрана да ги предупреди.

Какво може да ви струва това

Измамник получава реален сертификат за копие на сайта ви, така че показва зеления катинар и HTTPS — клиентите ви не виждат нищо нередно, въвеждат паролите и номерата на картите си, а вие разбирате само когато започнат жалбите за измама и ядосаните обаждания.
Клиентите ви биват фишингвани чрез пиксел-перфектен клонинг на страницата ви за влизане; последствията — възстановявания, товар за поддръжка, репутационна щета — падат върху марката ви, въпреки че реалният ви сайт никога не е бил докосван.
Екипът по сигурност или обществени поръчки на потенциален клиент прави бърза проверка на домейна ви преди подписване, вижда липса на CAA защита и тихо ви отбелязва надолу като 'слаби в основите' — излагайки на риск сделка заради настройка, отнемаща пет минути за добавяне.
Една от сертификатните компании в света е компрометирана (случило се е многократно — DigiNotar, Comodo, Symantec) и тъй като никога не сте указали кой има право да действа от ваше наименование, домейнът ви е изложен на каквато и да е оказала се най-слабото звено.

Защо има значение. В момента вратата е широко отворена: всяка сертификатна компания на Земята може да ръчи за сайт, твърдящ, че е ваш, независимо дали сте имали работа с тях или не. CAA запис заключва онази врата, така че само избраният от вас доставчик може да издава сертификати — той е най-простата, най-евтина защита срещу онлайн имперсонация на вашия бизнес.

Как да го поправите, стъпка по стъпка

Отбележете сертификатните служби. Изброете кои CA(s) издават сертификатите ви — напр. Let's Encrypt или CA-то на хоста ви.
Добавете CAA запис. Създайте CAA запис при корена на домейна, упълномощаващ само онези CA-та, напр. 0 issue "letsencrypt.org".
Покрийте wildcard-и и сигнали. Добавете issuewild ако използвате wildcard сертификати, и iodef mailto за уведомяване при нарушения.
Не блокирайте подновяванията. Уверете се, че всяко CA, реално използвано от вас, е изброено, иначе бъдещите подновявания на сертификати ще се провалят.
Верифицирайте, че е проработило. Проверете отново, за да потвърдите, че CAA записът е налице и добре оформен.

CAA записи с прости думи

Всеки защитен уебсайт има сертификат — нещото зад катинара в браузъра и „https” в началото на адреса. Тези сертификати се раздават от специализирани фирми, наречени сертификатни служби (CAs): наименования като Let’s Encrypt, DigiCert, Sectigo, Google Trust Services. Когато браузърът види валиден сертификат, показва катинара и казва на клиента, че връзката е истинска и сигурна.

Ето частта, за която повечето собственици на бизнес никога не са чували: по подразбиране, стотици сертификатни служби по целия свят всяка може да издаде сертификат за вашия домейн — независимо дали сте чували за тях или не. CAA запис (Certification Authority Authorization) е едноредова бележка, добавена в DNS настройките на домейна, казваща на практика: „само тези доставчици имат право да издават сертификати за мен.” Всяка легитимна сертификатна служба е задължена по правилата на индустрията да провери онази бележка преди издаване — и да откаже ако не са в списъка.

Разликата между отключена предна врата, през която всеки може да мине, и такава, при която само хората, избрани от вас, притежават ключ. И не струва нищо за добавяне.

Какво може да ви струва това

Рискът, затваряния от CAA запис, е убедителна имперсонация. Когато измамник може да получи реален сертификат за копие на сайта ви, обичайните предупредителни знаци изчезват — няма счупен катинар, няма банер „не е сигурно”, няма грешка за сертификат. Всичко изглежда правилно, което е именно онова, правещо го опасно.

Безупречният фалшификат. Измамник регистрира адрес-подобие (или компрометира маршрут към клиентите ви), получава истински сертификат и постави перфектен клонинг на страницата ви за влизане или плащане — с катинар и всичко. Клиентите въвеждат пароли и номера на карти нормално. Първото, което чувате, е вълна от жалби за измама и ядосани обаждания.
Фишинг кампанията от ваше наименование. Нападателите изпращат имейли „моля потвърдете акаунта си”, свързващи към техния сертифициран клонинг на сайта ви. Тъй като страницата изглежда напълно сигурна, повече хора се хващат. Почистването — уведомяване на клиенти, възстановявания, часове поддръжка, неудобното публично обяснение — пада изцяло върху вас, въпреки че реалните ви сървъри никога не са били докосвани.
Сделката, спряна на контролен списък. По-голям клиент сканира домейна ви преди подписване. „Без CAA запис” се появява като червен или кехлибарен елемент до вашето наименование. Технически е малко нещо, но звучи като „не покрива основите” и може да забави или потопи договор, иначе спечелен от вас.
Хванати от чуждо пробиване. Сертификатна служба, с която никога не сте имали работа, е компрометирана — не е хипотетично; DigiNotar, Comodo и Symantec са имали сериозни инциденти. Тъй като никога не сте ограничили кой може да действа от ваше наименование, нападателят може да получи валиден сертификат за домейна ви чрез онзи слаб CA. CAA запис щеше да ги откаже.
Слепото петно за wildcard-и. Дори бизнеси, внимателни за основния сайт, нерядко забравят поддомейните. Без правило issuewild, нападател, способен да получи wildcard сертификат, ефективно получава ключ за всеки поддомейн, който ще имате изобщо.

Нито един от тях не изисква сложна атака срещу сървърите ви. Те експлоатират факта, че без CAA запис, по-широката сертификатна система е просто прекалено доверчива от ваше наименование.

Какво всъщност е и как изглежда „добро”

CAA запис живее в DNS-а на домейна ви — същите настройки, насочващи домейна ви към уебсайта и имейла. Всеки запис има три части: флаг, таг и стойност. Важните тагове са:

issue — назовава сертификатна служба, разрешена да издава нормални сертификати за домейна. Можете да имате няколко, по един за всеки легитимно използван от вас доставчик.
issuewild — контролира wildcard сертификатите (един сертификат, покриващ всеки поддомейн, напр. *.example.com). Ако не използвате wildcard-и, препоръчваната настройка ги блокира изцяло.
iodef — незадължителен адрес за контакт, на който ще бъдете уведомявани ако сертификатна служба откаже заявка поради CAA политиката. Това е ранното предупреждение, че някой е опитал.

Как изглежда „добро”: поне един запис issue (или issuewild) е налице, назоваващ доставчика(ите), реално използвани от вас, с wildcard-ите или ограничени до назован доставчик или блокирани. Това е летвата, измервана от тази проверка — тя търси CAA записите на домейна ви при няколко независими разрешители и преминава когато намери реална issue или issuewild политика на място. Домейн без CAA записи изобщо се третира като отворената врата, каквато е.

Влияе ли на оценката? Да. Липсващ CAA запис е оценяван елемент и е маркиран при средна тежест — истинска пропаст, а не просто приятна добавка, тъй като оставя реален маршрут за имперсонация отворен. Добавянето на записа затваря пропастта и изчиства находката.

Как да го поправите (безплатно, ~5 минути)

Дайте тази секция на когото управлява домейна или уебсайта ви — поправката е безплатна. Малка DNS промяна, а не преизграждане. Таксуваме само ако по-късно искате да следим, че записът остава на място; добавянето не струва нищо.

Стъпка 1 — Разберете коя сертификатна служба реално използвате. Това е единствената стъпка, заслужаваща да бъде направена правилно, тъй като изброяването на грешния доставчик може да блокира следващото подновяване. Обичайни случаи:

Let’s Encrypt — използван от много хостове и контролни панели (cPanel, Plesk) → letsencrypt.org
Cloudflare (ако издава edge сертификата ви) → letsencrypt.org, digicert.com, comodoca.com, pki.goog и ssl.com (Cloudflare използва множество backend CA-та; изброете тези, показани от таблото му, или пълния набор, за да не се счупват подновяванията)
Google Workspace / Google Trust Services → pki.goog
DigiCert → digicert.com
Sectigo / Comodo → sectigo.com (и comodoca.com)
Microsoft 365 / Azure — Microsoft обикновено използва DigiCert за управлявани сертификати → digicert.com (потвърдете в портала)

При несигурност, погледнете текущия сертификат в браузъра (кликнете катинара → детайли за сертификата → „Издаден от”), за да видите кой го е издал.

Стъпка 2 — Влезте в DNS доставчика. Това е където живеят записите на домейна ви — обикновено регистраторът, уеб хостът или Cloudflare. Намерете раздела с DNS записи и изберете да добавите нов запис от тип CAA (някои интерфейси го означават като тип 257).

Стъпка 3 — Добавете запис issue за всеки доставчик, използван от вас. За Let’s Encrypt например:

example.com.   CAA   0 issue "letsencrypt.org"

Добавете по един issue ред за всеки легитимен доставчик. Повечето DNS табла ви дават отделни кутии за флага (0), тага (issue) и стойността (домейна на CA-то), така че не е нужно да пишете целия ред ръчно.

Стъпка 4 — Контролирайте wildcard сертификатите. Ако не използвате wildcard-и, блокирайте ги изцяло, за да не може никой тихо да получи такъв:

example.com.   CAA   0 issuewild ";"

Ако използвате wildcard-и, назовете доставчика вместо: 0 issuewild "letsencrypt.org".

Стъпка 5 — (Препоръчано) Добавете адрес за уведомление. За да бъдете уведомявани при всяко отказване от страна на CA — вашето ранно предупреждение, че някой е опитал:

example.com.   CAA   0 iodef "mailto:[email protected]"

Стъпка 6 — Запишете и верифицирайте. Изпълнете dig CAA example.com (или използвайте онлайн инструмент за DNS справка) и потвърдете, че записите се появяват. Промените могат да отнемат от няколко минути до няколко часа, за да се разпространят в интернет. Съществуващият сертификат и всички подновявания продължават да работят — CAA управлява само новото издаване.

Бърза бележка за платформите: При Cloudflare, DNS → Records → Add record → тип CAA. При Google Workspace, управлявате DNS при регистратора (или Cloud DNS ако го използвате) — добавете CAA записите там с pki.goog. При Microsoft 365, CAA не се задава в административния център на M365; добавете го там, където е хостнат DNS-ът на домейна ви, изброявайки CA-то за управляван сертификат (обикновено DigiCert). При обичайни хостове (GoDaddy, Namecheap, Blacknight и т.н.), намирате го в същия DNS панел, където са A и MX записите.

Чести грешки

Изброяване на грешен CA — или забравяне на такъв. Най-голямото практическо бизнес рискуване не е сигурността, а блокирането на собствените ви подновявания. Ако използвате повече от един издател (напр. един за основния сайт и друг зад Cloudflare), изброете всичките. При несигурност, изброете повече от доверени, а не по-малко.
Задаване на issue, но игнориране на wildcard-ите. Домейн, ограничаващ нормалните сертификати, но без нищо за wildcard-ите, все пак оставя по-мощния wildcard маршрут отворен. Винаги задавайте и issuewild — или към доставчика или ";" за блокиране.
Поставяне на CAA при грешно наименование. CAA се чете от сертификатната служба за точното наименование, сертифицирано, вървейки нагоре по дървото. Задаването при върха на домейна (т.нар. „apex”, напр. example.com) е правилната стъпка — покрива поддомейните по подразбиране освен ако поддомейн не зада свой.
Приемане, че платформата го е направила вече. Cloudflare, Google и Microsoft управляват сертификати, но не добавят CAA записи вместо вас. Освен ако не сте ги добавили, домейнът ви все още е отворен.
Третиране като еднократно без мониторинг. По-късна DNS миграция, смяна на регистратор или „почистване” на записи може тихо да свали CAA защитата. Заслужава проверка, че е все още там след всяка DNS промяна.

Техническият слой (дайте на IT специалиста)

CAA е дефиниран в RFC 8659 и наложен под Изискванията за базова линия на CA/Browser Forum — всяко публично доверено CA е задължено да проверява CAA при издаване. Записите са с формат <flags> <tag> <value>, с тагове issue, issuewild и iodef. Непразна политика issue или issuewild е онова, удовлетворяващо тази проверка; само наличието на iodef не е достатъчно (то е докладване, а не упълномощаване).

Добра базова линия при apex-а:

example.com.   CAA   0 issue "letsencrypt.org"
example.com.   CAA   0 issuewild ";"
example.com.   CAA   0 iodef "mailto:[email protected]"

Бележки за имплементатора:

CAA tree-climbing: CA-тата оценяват CAA от заявения FQDN нагоре към apex-а, спирайки при първото наименование с CAA запис. Запис при apex-а следователно защитава всички поддомейни освен ако поддомейн не публикува свой — което може, полезно ако конкретен поддомейн използва различен издател.
Стойността ; в issuewild означава „никое CA не може да издава wildcard-и” — изрично отказване. Използвайте я когато wildcard-ите не са част от настройката ви.
Флагът 0 е флагът от решаващо значение на издателя; 0 (некритичен) е правилен за нормална употреба. Избягвайте задаването на критичния бит освен ако напълно не го разбирате, тъй като неразбран критичен таг може да накара съответстващи CA-та да откажат издаването.
Множество издатели: разрешени са няколко issue записа и са адитивни — изброявайте всяко CA, легитимно в стека ви (включително backend CA-тата, използвани от CDN/edge доставчика ви), за предотвратяване на провали при подновяване.
Верификация: dig CAA example.com +short, или проверете чрез инструментите за тестване на CAA на CA/Browser Forum. Тази проверка сама по себе си търси CAA при няколко независими разрешители (локален DNS, след това Google, Cloudflare и Quad9 DNS-over-HTTPS като резервен) и приема първия авторитетен отговор, така че единична авария на разрешител не произвежда фалшиво „без CAA” резултат.
Сдвояване с DNSSEC: CAA казва на CA-тата кой може да издава; DNSSEC спира самия CAA отговор да бъде фалшифициран при пренос. Те се допълват — за домейни с висока стойност, изпълнявайте и двете.

Настройте го при вашия хост

Стъпка по стъпка за популярни доставчици:

ЧЗВ

Не съм технически — мога ли сам да се справя с това?

Нямате нужда да разбирате детайлите, но поправката е малка промяна в DNS настройките на домейна ви, така че е най-добре да бъде дадена на когото управлява уебсайта или домейна ви. Изпратете им раздела 'Как да го поправите' по-долу — петминутна, безплатна промяна. Таксуваме само ако по-късно искате да следим, че записът остава на място; самата поправка е винаги безплатна.

Добавянето на CAA ще счупи ли уебсайта или сертификата ми?

Не — стига да изброите сертификатния доставчик, реално използван от вас, всичко продължава да работи точно по старому. CAA запис не пипа или замества съществуващия сертификат; той само управлява кой е разрешен да създава нови. Единственият начин да причините проблеми е да оставите реалния доставчик извън списъка, което може да блокира следващото автоматично подновяване — именно затова стъпките по-долу са написани конкретно да избегнат това.

Ако сертификатите се издават автоматично в наши дни, защо все пак ми трябва?

Автоматичните сертификати са добри и удобни — проблемът е, че системата по подразбиране е отворена за всички, включително за някой, преструващ се на вас. CAA запис просто назовава кой е разрешен, превръщайки отворена врата в такава с ваша ключалка. Работи наред с автоматичното издаване, а не срещу него.

Влияе ли на класирането ми в Google или на оценката в този доклад?

Влияе на оценката ви тук — липсващ CAA запис е оценяван елемент, маркиран като пропаст с средна тежест, тъй като оставя реален маршрут за имперсонация отворен. Не е директен фактор за класиране в Google, но имперсонацията и фишингът, предотвратявани от него, са именно видът инциденти, нанасящи щета на доверието и трафика. Така или иначе е бърза, безплатна победа.

Каква е разликата между 'issue' и 'issuewild'?

Запис 'issue' контролира нормалните сертификати за домейна и поддомейните му. Запис 'issuewild' контролира wildcard сертификатите — единствения сертификат, покриващ всеки възможен поддомейн наведнъж (като *.example.com). Wildcard-ите са по-мощни и следователно по-рискови в грешните ръце, така че е добра практика да ги контролирате отделно: ако не използвате wildcard-и, блокирайте ги изцяло.

Използваме Cloudflare / Google Workspace / Microsoft 365 — не покрива ли го вече?

Не автоматично. Онези платформи управляват сертификатите ви, но освен ако изрично не сте добавили CAA записи, домейнът ви все пак казва на света 'всяка сертификатна служба може да издава'. Добрата новина е, че поправката е еднаква проста DNS промяна за всички тях, и там където Cloudflare или хостът ви издава сертификата, просто изброявате онзи доставчик. Бележките за платформата в раздела за поправка по-долу покриват обичайните случаи.