Компрометираните ключове на удостоверяващия орган eMudhra: какво компаниите трябва да проверят и поправят сега

В събота, 17 октомври 2026 г., изследовател по сигурността съобщи, че осем междинни удостоверяващи органа на eMudhra, индийски удостоверяващ орган, имат частни ключове, които всеки може да изчисли от публичните сертификати. Всеки от ключовете беше число, по-малко от 256. Един от тях беше числото 4. Шест от осемте можеха да издават TLS сертификати, на които имат доверие Apple, Google, Microsoft и Mozilla; другите два можеха да подписват софтуер за Windows.

Chrome блокира шестте TLS ключа час и четиридесет минути след доклада, а Firefox го направи същата вечер. За хората, които разглеждат уебсайтове в браузъра, опасността беше отминала до събота вечерта.

За всичко останало тя не беше отминала. Сървърите, контейнерите, Java приложенията, скриптовете на Python, интеграциите за плащания и свързаните устройства проверяват сертификатите спрямо собствено копие на списъка с доверени удостоверяващи органи, а повечето от тези копия се променят само когато някой инсталира обновление. Дотогава сертификат за който и да е домейн, подписан с един от тези ключове, минава за истински, а ключовете са публични от 20 октомври.

През същата седмица GoDaddy започна да анулира 404 607 сертификата, защото информацията за политиките в тях не съответстваше на документите, които самата компания е публикувала. Клиентите ѝ трябваше сами да изтеглят и инсталират новите сертификати.

Това ръководство е за хората, които трябва да отговорят на въпроса „засегнати ли сме?“: ръководителите на ИТ и експлоатацията, техническите директори (CTO) и основателите, чийто бизнес зависи от уебсайт, API или свързан продукт. В него ще намерите какво се случи според записите за инцидента, публикувани от Mozilla, Google, eMudhra, GoDaddy и доставчиците на софтуер; какво да проверите днес; какво да обновите тази седмица; и какво да въведете, така че следващият инцидент от този вид да бъде рутина. Всичко тук е актуално към 22 октомври 2026 г., а инцидентът още не е приключил.

Какво се случи

eMudhra е създала осемте междинни сертификата на церемония по генериране на ключове (key ceremony) на 30 април 2025 г. Обяснението на компанията, публикувано на 19 октомври в записа за инцидента в Bugzilla на Mozilla: тест на стъпката за опаковане и разопаковане на ключ (key wrap и unwrap), одобрен като отклонение от обичайната ѝ процедура, е имал дефект, който е създал втори, слаб комплект ключове в хардуерния модул за сигурност (HSM) редом с предвидените. Етикетите са били сходни, слабите ключове по погрешка са били използвани за създаването на заявките за сертификати и кореновият сертификат на eMudhra ги е подписал. Същите заявки са отишли и при Sectigo, която на 14 май 2025 г. е подписала кръстосано и осемте с кореновия си сертификат AAA Certificate Services. eMudhra казва, че „все още не е потвърдила точната първопричина“.

Mozilla описа резултата така: „Частните ключове P384 са случайно избрани цели числа между 1 и реда на групата. Всичките 8 засегнати ключа са използвали цели числа, по-малки от 256.“ Mozilla получи доклада в 20:06 UTC и сама възстанови ключовете в 21:48, „без да знае какъв метод е използвал първоначалният докладващ“. Изследователят казва, че ги е открил с библиотеката с отворен код paranoid_crypto на Google, „без никакви допълнителни настройки“. Слабите ключове са били част от публично доверени вериги почти 18 месеца.

Осемте сертификата:

Всеки ключ се намира в два сертификата. Единият е издаден от emSign Root TLS CA - G3 или emSign Root CS CA - G3 на eMudhra, чиято верига води до emSign ECC Root CA - G3; другият е кръстосаният сертификат на Sectigo от AAA Certificate Services. Вторият път е важен, защото някои хранилища за доверени сертификати (trust stores), в които никога не е имало коренов сертификат на eMudhra, все още имат доверие на този стар коренов сертификат на Sectigo.

Имало ли е атаки?

Никой не е съобщил за злоупотреба, а при браузърите има добро основание да се смята, че такава не е имало. Chrome, както и другите клиенти, които прилагат Certificate Transparency (CT, публичното вписване на всеки издаден сертификат), приема сертификат само ако той е вписан в публичните CT журнали. Според Google преди блокировката не е бил вписан нито един TLS сертификат, чиято верига води до тези шест междинни сертификата, така че „никакви измамни сертификати, издадени от тези удостоверяващи органи, не биха могли да бъдат използвани срещу клиенти, които прилагат CT“.

Извън браузъра картината е различна. На страницата на Mozilla за инцидента пише: „много клиенти извън екосистемата на браузърите не прилагат Certificate Transparency. Не знаем дали нападатели са използвали дефектното генериране на ключове, за да атакуват тези клиенти.“ Този прозорец се отвори през пролетта на 2025 г. и за всеки клиент се затваря едва когато той бъде обновен. eMudhra казва, че не знае за доказателства ключовете да са били възстановени преди оповестяването, а Cloudflare казва, че проверката ѝ не е открила активно експлоатиране в нейните услуги.

Сега, когато ключовете са публични, фалшифицирането на сертификат не изисква никакви умения. Страницата на Mozilla за инцидента изброява тестови сървъри, които представят сертификати, издадени с компрометираните ключове, за да може всеки да провери клиентите си срещу тях (командите са по-долу).

Какво позволява един фалшив сертификат: някой, който може да прихване трафика между вашия софтуер и услуга, която той извиква (в споделена мрежа, през компрометиран рутер или с подправен DNS отговор), може да се представи за тази услуга, да чете това, което софтуерът ви изпраща, включително API ключове и лични данни, и да променя това, което той получава. Софтуер, подписан с един от двата ключа за подписване на код, би преминал проверката на подписа в Windows, докато блокировката на Microsoft не стигне до съответната машина.

Кой е засегнат

Става дума за три отделни проблема и една компания може да има и трите.

1. Софтуер, който все още има доверие на компрометираните ключове

Този проблем го има почти всяка компания: всяка програма, която прави HTTPS заявки, чието хранилище за доверени сертификати все още съдържа emSign ECC Root CA - G3 или AAA Certificate Services и която не е получила блокировка за осемте ключа. Типични места:

• Linux сървъри и образи на контейнери, изградени преди 20 или 21 октомври. Debian 12 без корекции например има доверие и на двете вериги.
• Среди за изпълнение на езици за програмиране, които доставят собствен списък: Node.js, certifi на Python, cacerts на Java, пакетът със сертификати на Composer за PHP, webpki-roots на Rust.
• Инструментите за командния ред на macOS. Страницата на Mozilla за инцидента посочва, че вградените curl, git, python3, perl, ruby и openssl проверяват сертификатите спрямо /etc/ssl/cert.pem, без да проверяват дали са анулирани, и че Apple не е обновила този файл.
• Машини с Windows, които не получават автоматичните обновления на Microsoft за списъка със забранени сертификати, обикновено защото Group Policy ги изключва или мрежата няма връзка с интернет.
• Готови устройства (appliances), други устройства и софтуер на трети страни, които носят собствен CA файл, например балансьори на натоварването, VPN шлюзове, SDK и вградени контролери.

Всяка среда за изпълнение трябва да се провери поотделно. При тест, който направихме на 22 октомври, машина с Debian 12 без корекции и Node.js 24.18 прие веригата, която завършва с кореновия сертификат на eMudhra, и отхвърли тази, която завършва с кореновия сертификат на Sectigo, докато Python на същата машина прие и двете.

2. Компании, чиито собствени сертификати водят до премахнатия коренов сертификат

Mozilla и Linux дистрибуциите премахнаха emSign ECC Root CA - G3, а Chrome ще го направи на 27 октомври. Валидните сертификати под този коренов сертификат спират да работят във всеки клиент, когато той бъде обновен. Указанието на Google: операторите на уебсайтове с такива сертификати „трябва незабавно да придобият и инсталират нов TLS сертификат от друга PKI йерархия, включена в Chrome Root Store“.

На 21 октомври Chrome преброи в CT около 30 800 неизтекли сертификата под него. 30 791 от тях идват от два междинни сертификата на InCommon, сертификатната услуга, която Internet2 поддържа за университетите и научноизследователските институции в САЩ и която издава ECC сертификати чрез CERTInext, платформата на eMudhra. 18 идват от собствените междинни сертификати на eMudhra. eMudhra казва, че около 30 000 сертификата трябва да бъдат мигрирани, около 97% от тях издадени чрез ACME, и че издава заместващи сертификати от друга йерархия.

Ако сайтът ви е зад Cloudflare в режим Full (strict) и origin сървърът представя сертификат под този коренов сертификат, Cloudflare казва, че отнемането на доверието „би довело до прекъсвания“, и призовава клиентите: „Прегледайте собствените си сертификати за origin сървъра и конфигурациите на сървърите“.

RSA сертификатите от другия коренов сертификат на eMudhra, emSign Root CA - G1, засега не са засегнати. Mozilla казва, че „на този етап“ не премахва този коренов сертификат; Chrome „внимателно проучва по-нататъшното включване на останалите CA сертификати на eMudhra“. Ако зависите от сертификати на eMudhra или CERTInext от какъвто и да е вид, осигурете си още сега втори удостоверяващ орган.

3. Клиенти на GoDaddy

Случаят с GoDaddy няма нищо общо с eMudhra, но удари същата седмица и засегна много повече сайтове. На 15 октомври GoDaddy докладва на Mozilla, че сертификатите от йерархиите ѝ GoDaddy и Starfield съдържат информация за политиките на сертификатите (OID на политиките и връзки към CPS), която не съответства на профилите в собствения ѝ CP/CPS, документа, в който удостоверяващият орган посочва какво издава. Това не е пропуск в сигурността на сертификатите. Според Baseline Requirements, правилата, които спазва всеки публичен удостоверяващ орган, това все пак е основание за анулирането им в срок от пет дни.

Засегнати са 404 607 сертификата, 396 055 от тях с валидиране на домейна (DV). GoDaddy анулира 170 566 до крайния срок, 18 октомври, 23:45 UTC, и 227 422 до следващата сутрин; според известието ѝ до клиентите останалите са анулирани на 21 октомври. GoDaddy издава сертификатите наново, но инсталирането им е грижа на клиента: „посетителите на уебсайта ви може да виждат предупреждения за сигурност, а сайтът ви може да стане недостъпен, докато не бъде инсталиран нов сертификат.“

Какво да проверите днес

1. Какво изпращат собствените ви сървъри? За всяко публично име на хост изведете издателите във веригата, която той представя:

h=www.example.com
openssl s_client -connect "$h:443" -servername "$h" -showcerts </dev/null 2>/dev/null | grep -E '^ +i:'

Ред, в който се споменава eMudhra, emSign, някой от органите EM ... G3B или G3C или InCommon Intermediate CA - DVG3C, OVG3C или EVG3C, означава, че сертификатът трябва да бъде сменен преди 27 октомври. AAA Certificate Services сам по себе си е нормален, защото много обикновени вериги на Sectigo все още го включват. За пощенските и директорийните услуги добавете -starttls smtp (или imap, ldap) и правилния порт. Включете и вътрешните хостове, балансьорите на натоварването и origin сървърите зад CDN.

2. Какво е издадено за вашите домейни? В CT е вписан всеки сертификат, който публичен удостоверяващ орган е издал за вашите имена, включително такива, за които никой в компанията не помни да ги е поръчвал:

curl -s 'https://crt.sh/?q=%25.example.com&output=json&exclude=expired' | jq -r '.[].issuer_name' | sort | uniq -c

Резултатът показва и кои удостоверяващи органи компанията ви действително използва, а това е началото на описа, за който става дума по-долу.

3. Имат ли клиентите ви доверие на компрометираните ключове? Тестовите сървъри на Mozilla представят сертификати, издадени с компрометираните ключове, така че грешката в сертификата е добрият резултат. Тествайте и двете семейства: първият хост води до кореновия сертификат на eMudhra, вторият до този на Sectigo, а едно хранилище за доверени сертификати може да не издържи единия тест и да издържи другия.

curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"
curl -sS -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"

curl отговаря само за curl. Изпълнете същата заявка през собствения TLS стек на всяко приложение, в средата, в която то работи:

node -e "require('https').get('https://dv-g3b-emudhra.we-have-a-problem.com/', () => console.log('TRUSTED')).on('error', e => console.log('rejected:', e.code))"
python3 -c "import urllib.request; urllib.request.urlopen('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"
python3 -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"

Двата реда за Python не се дублират: urllib използва хранилището на операционната система, а requests използва certifi. Повторете всеки ред с хоста dv-g3b-aaa-emudhra. За Java направете произволна HTTPS заявка към тестовите сървъри от съответната JVM и проверете дали хранилището ѝ съдържа някой от двата коренови сертификата (Java 9 или по-нова; на Java 8 използвайте -keystore $JAVA_HOME/jre/lib/security/cacerts):

keytool -list -v -cacerts -storepass changeit | grep -E 'Owner: .*(emSign ECC Root CA - G3|AAA Certificate Services)'

Коренов сертификат в хранилището сам по себе си не доказва изложеност, защото Go, Node.js, Deno и rustls-webpki на Rust вече блокират осемте ключа независимо от съдържанието на хранилището. Тестовите сървъри дават окончателния отговор.

4. Компютърният парк с Windows. Microsoft не е публикувала нищо за инцидента, но списъкът със забранени сертификати, който Windows изтегля автоматично, блокира и осемте ключа от 20 октомври. Изключения са машините, на които Group Policy изключва автоматичното обновяване на кореновите сертификати, и мрежите без достъп до Windows Update; при тях списъкът трябва да бъде доставен по друг начин. certutil -verifyCTL Disallowed показва копието, кеширано на дадена машина. Страницата на Mozilla за инцидента предлага скрипт за отделни машини и казва, че той „не се препоръчва за устройства, управлявани от организация“.

5. Сертификатите от GoDaddy. Проверете кой сертификат всъщност представя всеки сървър:

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -issuer -serial -startdate

Ако издателят е GoDaddy или Starfield, сравнете серийния номер със сертификатите в акаунта си в GoDaddy. Там, където GoDaddy показва „Install your new certificate“ (инсталирайте новия си сертификат), сървърът все още използва анулирания.

Едно правило важи навсякъде: не премахвайте грешката, като изключите проверката на сертификатите. Както казва Cloudflare: „Важно е тези грешки да не се решават чрез изключване на проверката.“ Клиент, който не проверява, има доверие на всеки фалшив сертификат, а не само на тези.

Какво да обновите тази седмица

Корекциите са два вида. Премахването на двата коренови сертификата затваря всеки път за клиент, който използва това хранилище, но чупи и валидните сертификати под тях. Блокирането на осемте ключа по хеша на публичния им ключ, както правят Go, Node.js, Deno, Electron, rustls-webpki, Composer и Windows, затваря дупката и не чупи нищо друго. Където платформата ви предлага втория вариант, предпочетете него.

„Все още“ означава, че до 22 октомври нищо не е било публикувано. Проверете отново, преди да планирате нещо въз основа на това.

Четири неща често подвеждат екипите:

• Образите на контейнери запазват стария списък. Образ, изграден преди 20 или 21 октомври, има доверие на ключовете, докато не бъде изграден наново върху обновен базов образ, а изтеглянето на същия таг помага едва след като базовият образ е изграден наново. Изградете образите наново, внедрете ги отново и попитайте доставчиците, чиито образи използвате.
• Процесите пазят това, което са заредили. Програмата чете хранилището си за доверени сертификати при стартиране, затова рестартирайте дълго работещите услуги след обновяването. Node.js добавя, че TLS сесиите, възобновени от времето преди обновяването, не се проверяват отново.
• Приложенията носят собствени CA файлове. SDK и приложенията често доставят собствен cacert.pem или ca-bundle.crt. Потърсете ги в хранилищата с код и в образите, например с find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null, и очаквайте повече от един: pip например носи собствено копие на certifi.
• Устройствата чакат своя доставчик. Попитайте всеки доставчик писмено кое хранилище за доверени сертификати използва продуктът и кога ще излезе обновлението. Докато не излезе, устройството има доверие на фалшиви сертификати за всяка услуга, която извиква, затова ограничете до какво има достъп.

Ако премахнете AAA Certificate Services ръчно, както правят Debian, Ubuntu ESM, Fedora и временното решение на Red Hat, след това тествайте връзките към услуги със сертификати на Sectigo: някои по-стари сървъри все още изпращат верига, която завършва с този коренов сертификат.

Какво да въведете преди следващия инцидент

Удостоверяващ орган да остави толкова слаби ключове е рядкост. Масовите анулирания не са. Ето големите от 2026 г., записани в бъг тракера на Mozilla:

Нито един от тези пет случая не е бил провал в сигурността. Във всеки от тях сертификатът е противоречал на собствения документ на удостоверяващия орган, а Baseline Requirements (раздел 4.9.1.1) въпреки това изискват анулиране в срок от пет дни. Когато ключ е компрометиран или на валидирането на домейна не може да се разчита, срокът е 24 часа. Никой не може да го удължи заради вас. При анулирането на 83 267 сертификата от DigiCert през 2024 г. Chrome Root Program написа, че „няма правомощия да предоставя изключения“; един клиент получи съдебна заповед за спиране на анулирането на сертификатите си, а заповедта беше отменена четири дни по-късно.

Начинът, по който протече смяната, говори много. През юли HARICA използва ACME Renewal Information (ARI), за да каже на ACME клиентите, които клиентите ѝ използват, да подновят по-рано, а други сертификати издаде наново сама; при по-голямото от двете ѝ анулирания 87% от засегнатите имена бяха сменени, когато настъпи крайният срок. GoDaddy, чиито клиенти сами изтеглят и инсталират всеки нов сертификат, беше анулирала до крайния си срок 42% от засегнатите си сертификати.

Цикълът на подновяване и без това се скъсява:

• Съгласно решението SC-081 на CA/Browser Forum публичните TLS сертификати са ограничени до 200 дни от 15 март 2026 г. Ограничението пада на 100 дни на 15 март 2027 г. и на 47 дни на 15 март 2029 г., когато валидирането на домейна ще може да се използва повторно само в рамките на 10 дни.
• Let's Encrypt преминава по подразбиране към 64-дневни сертификати на 10 февруари 2027 г., а година по-късно към 45-дневни.
• Публичните TLS сертификати губят удостоверяването на клиенти. Let's Encrypt спря да го предлага на 8 юли 2026 г., а Chrome Root Program изисква сертификатите, издадени от 15 март 2027 г., да бъдат само за удостоверяване на сървъри. Ако използвате публични сертификати като клиентски сертификати за mutual TLS (взаимно удостоверяване), което е често срещано в B2B интеграциите чрез API, за тези връзки ще ви трябва частен удостоверяващ орган.

При 100 дни, а после и при 47, ръчното инсталиране на сертификати престава да бъде реалистичен вариант. Компания, която автоматизира процеса за този график, е готова и за следващото масово анулиране. Какво е нужно за това:

1. Знайте какво имате, и в двете посоки. Един списък с всеки сертификат, който сървърите ви представят, с име на хост, издател, срок на валидност, начин на подновяване и отговорник. Втори списък с всяко хранилище за доверени сертификати, на което разчита софтуерът ви: пакетът на операционната система, всеки пакет със сертификати на отделните езици за програмиране, всеки CA файл в приложение или устройство. Търсенето в CT по-горе е началото на първия списък; спецификацията на софтуерните компоненти (SBOM) или описът на зависимостите е началото на втория.
2. Автоматизирайте издаването и инсталирането. ACME навсякъде, където може да работи, с ARI (RFC 9773), за да може удостоверяващият орган да каже на клиентите ви да подновят по-рано. Където устройство не може да изпълнява ACME, използвайте автоматизацията на доставчика или терминирайте TLS пред него на нещо, което може.
3. Дръжте в готовност втори удостоверяващ орган. Работещ и тестван ACME акаунт при втори удостоверяващ орган и CAA записи в DNS, които разрешават и двата. Когато единият орган загуби доверие или анулира масово, преминаването към другия става промяна в конфигурацията.
4. Наблюдавайте CT за домейните си. Получавайте известие за всеки нов сертификат за вашите имена. Така научавате за неочаквано издаване в деня, в който се случи.
5. Третирайте хранилищата за доверени сертификати като зависимости. Обновявайте ги с обичайното прилагане на корекции и изграждайте образите наново по график, а не само когато се промени кодът.
6. Напишете наръчника за действие (runbook) според двата срока. 24 часа и пет дни: кой решава, кой има достъп до всяка система, кои системи изискват ръчни стъпки, как се стига до всеки доставчик. Упражнявайте го веднъж годишно, като сменяте сертификата на услуга, която може да си позволи грешка. От 2025 г. публичните удостоверяващи органи са длъжни да поддържат и тестват собствен план за масово анулиране; клиентите им имат нужда от другата половина.

Ако правите продукти, които други използват

Ако продуктът ви съдържа хранилище за доверени сертификати (устройство, инсталирано приложение, SDK), клиентите ви са защитени едва когато обновлението ви стигне до тях. Издайте го и кажете на клиентите кои версии съдържат корекцията. Съветът на Mozilla към операторите на хранилища за доверени сертификати: блокирайте осемте междинни сертификата, ако софтуерът ви може, а иначе „преценете дали е подходящо да премахнете доверието в кореновите сертификати, които са подписали тези междинни сертификати“.

Актът за киберустойчивост се отнася до случая по два начина. Задължението му за докладване, в сила от 11 септември 2026 г., обхваща активно експлоатираните уязвимости, а в този случай не е съобщено за експлоатиране. Съществените му изисквания, които се прилагат от 11 декември 2027 г., включват уязвимостите да могат да се отстраняват чрез обновления за сигурност; продукт, чийто списък с доверени сертификати не може да бъде обновен, не би ги изпълнил. Клиентите, които попадат в обхвата на NIS2, ще питат доставчиците си колко бързо са се справили с това и е добре отговорът да е записан.

Какво още не е решено

• Оставащият коренов сертификат на eMudhra. На 21 октомври Chrome публикува дванадесет въпроса към eMudhra и не е обявил решение за emSign Root CA - G1. Mozilla не го премахва „на този етап“.
• Пътят за миграция на eMudhra. Пред Mozilla компанията заяви, че ще прехвърли клиентите към своята йерархия G1 (RSA); страницата ѝ за статуса говори за „алтернативна, независимо управлявана, публично доверена CA йерархия“. Chrome е попитал коя.
• Microsoft и Apple. Никоя от двете компании не е публикувала изявление и не е премахнала нито един от двата коренови сертификата от хранилището си.
• Чакащи корекции. До 22 октомври Red Hat, Amazon Linux, Temurin и Corretto не бяха издали нищо; корекцията на Bun беше слята, но не и издадена.
• Първопричината. eMudhra не я е потвърдила и е заявила, че ще провери отново всяка церемония по генериране на ключове, която е провела.
• Sectigo. В отделен случай, открит от 5 септември, Sectigo отказва да анулира сертификати, чието разширено използване на ключа (extended key usage) не съответства на едно изречение в нейния CPS, с аргумента, че изречението е двусмислено. На 18 октомври тя преброи около 72 милиона такива сертификата, които все още са активни. Някои участници в публичната дискусия призовават за отнемане на доверието; нито една програма за коренови сертификати не е обявила решение. Компаниите със сертификати на Sectigo е добре да следят случая.

Къде да потърсите помощ

Проблемът със сертификат рядко се представя като такъв. Той се проявява като страница за плащане, която спира да се зарежда, интеграция, която спира да се синхронизира, или устройство, което спира да изпраща данни, обикновено през уикенда. Помагаме на компаниите да преминат през седмици като тази без прекъсване на услугите и да подготвят нещата така, че следващия път всичко да бъде рутина:

• Проверка на изложеността. Откриваме къде системите ви правят или приемат TLS връзки, кое хранилище за доверени сертификати използва всяка от тях и кои сертификати представят сървърите ви, включително контейнери, Java услуги, интеграции с банки, доставчици на плащания и логистика, и устройства.
• Корекциите. Обновления, наново изградени образи, блокирани ключове или сменени сертификати, направени през вашия процес за управление на промените и потвърдени чрез тестовите сървъри на Mozilla.
• Автоматизация за 2027 г. ACME с ARI на сървърите, балансьорите на натоварването и готовите устройства, втори удостоверяващ орган, CAA записи, наблюдение на CT и наръчник за действие, готови за 100-дневните сертификати от 15 март 2027 г.
• Системите, които никой не иска да пипа. Старите Java приложения, готовите устройства и вградените клиенти със собствени хранилища за доверени сертификати са точно това, за което е нашата услуга за поддръжка на наследени системи и код.

Ако не сте сигурни дали сте засегнати, пишете ни на office@c9group.dev с домейните и платформите, които използвате, или запазете час за разговор. Ще ви кажем какво да проверите първо.