Компромитирани CA-клучеви на eMudhra: што компаниите треба да проверат и поправат сега

Во сабота, 17 октомври 2026 година, еден безбедносен истражувач пријави дека осум посреднички сертификациски тела што ги води eMudhra, индиско сертификациско тело (CA), имаат приватни клучеви што секој може да ги пресмета од јавните сертификати. Секој од клучевите беше број помал од 256. Еден од нив беше бројот 4. Шест од осумте можеа да издаваат TLS-сертификати на кои им веруваат Apple, Google, Microsoft и Mozilla; другите два можеа да потпишуваат софтвер за Windows.

Chrome ги блокираше шесте TLS-клучеви еден час и четириесет минути по пријавата, а Firefox истата вечер. За луѓето што прелистуваат веб-страници, опасноста помина до сабота навечер.

За сè друго не помина. Серверите, контејнерите, Java-апликациите, Python-скриптите, интеграциите за плаќање и поврзаните уреди ги проверуваат сертификатите според сопствена копија од листата на доверливи сертификациски тела, а повеќето од тие копии се менуваат само кога некој ќе инсталира ажурирање. Дотогаш сертификат за кој било домен, потпишан со еден од овие клучеви, поминува како автентичен, а клучевите се јавни од 20 октомври.

Истата недела GoDaddy почна да отповикува 404.607 сертификати, бидејќи информациите за политиката во нив не се совпаѓаа со неговите сопствени објавени документи. Клиентите на GoDaddy мораа сами да ги преземат и инсталираат замените.

Овој водич е за луѓето што треба да одговорат на прашањето „дали сме засегнати?“: раководителите на ИТ и на оперативата, техничките директори (CTO) и основачите чиј бизнис зависи од веб-сајт, API или поврзан производ. Опфаќа што се случи, според записите за инцидентот што ги објавија Mozilla, Google, eMudhra, GoDaddy и добавувачите на софтвер; што да проверите денес; што да ажурирате оваа недела; и што да воспоставите за следниот ваков инцидент да биде рутина. Сè што е напишано тука е според состојбата на 22 октомври 2026 година, а инцидентот сè уште не е затворен.

Што се случи

eMudhra ги создаде осумте посреднички сертификати на церемонија за генерирање клучеви (key ceremony) на 30 април 2025 година. Објаснувањето на eMudhra, објавено на 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; другиот е вкрстениот сертификат (cross-certificate) на Sectigo од AAA Certificate Services. Втората патека е важна, бидејќи некои складишта на сертификати (trust store) што никогаш не содржеле коренски сертификат на eMudhra сè уште му веруваат на тој стар коренски сертификат на Sectigo.

Дали некој беше нападнат?

Никој не пријавил злоупотреба, а за прелистувачите има добра причина да се верува дека немало. Chrome, како и другите клиенти што спроведуваат Certificate Transparency (CT, јавни дневници во кои се запишува секој издаден сертификат), прифаќа сертификат само ако е запишан во јавните CT-дневници. Google: пред блокирањето во дневниците не бил запишан ниту еден TLS-сертификат што води до овие шест посреднички сертификати, па „ниту еден лажен сертификат издаден од овие CA не можел да биде употребен против клиенти што спроведуваат 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, на пример, им верува на двата синџира.
• Извршни околини (runtime) на програмските јазици што носат сопствена листа: 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 gateway-и, 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. Од сопствените посреднички сертификати на eMudhra потекнуваат 18. eMudhra вели дека треба да се мигрираат околу 30.000 сертификати, од кои околу 97% се издадени преку ACME, и дека издава замени од друга хиерархија.

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

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

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

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

Засегнати беа 404.607 сертификати, од кои 396.055 со валидација на доменот. GoDaddy отповика 170.566 до рокот, 18 октомври во 23:45 UTC, а до следното утро 227.422; неговото известување за клиентите наведува дека останатите се отповикани на 21 октомври. GoDaddy ги издава сертификатите повторно, но нивното инсталирање е обврска на клиентот: „посетителите на вашиот веб-сајт може да гледаат безбедносни предупредувања, а вашиот сајт може да стане недостапен додека не се инсталира нов сертификат.“

Што да проверите денес

1. Што испраќаат вашите сопствени сервери? За секое јавно име на хост (hostname), излистајте ги издавачите во синџирот што го испраќа:

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) и соодветната порта. Вклучете ги и внатрешните хостови, балансерите на оптоварување и изворните сервери зад 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-клиентите на своите корисници да ги обноват сертификатите предвреме, а другите сертификати самостојно ги издаде повторно; кај поголемото од двете отповикувања на HARICA, 87% од засегнатите имиња беа заменети до истекот на рокот. GoDaddy, чии клиенти сами ја преземаат и инсталираат секоја замена, до својот рок имаше отповикано 42% од засегнатите сертификати.

Циклусот на обновување во секој случај се скратува:

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

При 100 дена, а потоа при 47, рачното инсталирање сертификати престанува да биде реална опција. Компанија што ќе автоматизира според тој распоред е подготвена и за следното масовно отповикување. Што е потребно за тоа:

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

Ако правите производи што ги користат други

Ако вашиот производ содржи складиште на сертификати (уред, инсталирана апликација, SDK), вашите клиенти се заштитени дури кога вашето ажурирање ќе стигне до нив. Објавете го и кажете им на клиентите кои верзии се поправени. Советот на Mozilla за операторите на складишта на сертификати: блокирајте ги осумте посреднички сертификати ако вашиот софтвер може, а ако не, „размислете дали е соодветно да се отстрани довербата во коренските сертификати што ги потпишаа овие посреднички сертификати“.

Cyber Resilience Act тука се применува на два начина. Неговата обврска за пријавување, која важи од 11 септември 2026 година, опфаќа активно искористени ранливости, а во овој случај не е пријавено искористување. Неговите суштински барања, кои се применуваат од 11 декември 2027 година, вклучуваат ранливостите да можат да се отстранат преку безбедносни ажурирања; производ чија листа на доверливи сертификати не може да се ажурира не би ги исполнил. Клиентите опфатени со NIS2 ќе ги прашаат своите добавувачи колку брзо го решиле ова, и добро е одговорот да го имате напишан.

Што сè уште е отворено

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

Каде да побарате помош

Проблемот со сертификат ретко се најавува како таков. Се појавува како наплата што престанува да се вчитува, интеграција што престанува да се синхронизира или уред што престанува да испраќа податоци, обично за време на викенд. Им помагаме на компаниите да поминат низ недели како оваа без прекин во работата и ги поставуваме работите така што следната ќе биде рутина:

• Проверка на изложеноста. Наоѓаме каде вашите системи воспоставуваат или прифаќаат TLS-врски, кое складиште на сертификати користи секој од нив и кои сертификати ги испраќаат вашите сервери, вклучувајќи контејнери, Java-услуги, интеграции со банки, даватели на платежни и логистички услуги и уреди.
• Поправките. Ажурирања, повторно изградени слики, блокирани клучеви или заменети сертификати, спроведени преку вашиот процес за управување со промени и потврдени со тест-серверите на Mozilla.
• Автоматизација за 2027 година. ACME со ARI на серверите, балансерите на оптоварување и наменските уреди, второ сертификациско тело, CAA-записи, следење на CT и оперативен прирачник, подготвени за сертификати од 100 дена од 15 март 2027 година.
• Системите што никој не сака да ги допре. Старите Java-апликации, наменските уреди и вградените клиенти со сопствени складишта на сертификати се токму она за што е наменета нашата услуга за одржување наследени системи и код.

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