Revocare HARICA: verifică serviciile TLS după 25 iulie

Acesta este un update operațional publicat pe 26 iulie, după termen. GWDG a avertizat pe 21 iulie că anumite certificate de server HARICA emise între 27 martie și 20 iulie 2026 trebuiau înlocuite până pe 25 iulie. Potrivit informării, certificatele afectate rămase urmau să fie revocate automat de la 10:00 UTC în 25 iulie, ceea ce poate face indisponibile servicii protejate TLS sau poate genera avertismente de certificat.

Populația afectată descrisă de GWDG este precisă: certificate de server fără metodă AIA OCSP URI, inclusiv certificate care fuseseră deja înlocuite în exercițiul de revocare anterior. Certificatele de utilizator și certificatele de server emise înainte de 27 martie sau după 20 iulie nu sunt incluse în acea descriere. Nu deduce impactul doar din dată; validează emitentul și certificatul servit efectiv de fiecare endpoint.

De ce este un eveniment de securitate și disponibilitate

Un certificat poate exista încă în configurație, dar să nu mai fie de încredere. Simptomul poate fi un avertisment în browser, un API care nu mai răspunde, o integrare mTLS eșuată, o alertă de monitorizare sau blocarea unui flux de business. Managementul ciclului de viață al certificatelor este deci un control de reziliență: problema nu este criptografia, ci incapacitatea de a descoperi, înlocui și verifica rapid o dependență de încredere.

Și TU Berlin a avertizat că certificatele afectate care nu sunt înlocuite înainte de suspendare pot produce avertismente de certificat sau probleme de conexiune. În ziua de după termen, postura corectă este validarea sănătății serviciilor, nu presupunerea că automatizarea s-a încheiat cu succes.

Ce verifici astăzi

• Construiește lista tuturor endpoint-urilor HTTPS publice, reverse proxy, load balancere, portaluri VPN, API gateway și integrări mTLS care ar putea folosi un certificat de server emis de HARICA
• Inspectează certificatul prezentat efectiv de fiecare endpoint: emitent, serie, valabilitate, extensia AIA, status de încredere și hostname acoperit
• Compară certificatul din producție cu job-ul de reînnoire sau ACME; un certificat nou emis nu este util până nu este instalat pe fiecare listener relevant
• Testează separat traseele de utilizator și de mașină: browser, API, clienți mobili, TLS între servicii, job-uri programate și integrări cu parteneri pot eșua diferit
• Verifică logurile agentului de renew și de deploy, apoi alertează pentru expirări apropiate, renew eșuat, reload eșuat și schimbări neașteptate de emitent
• Păstrează un incident record concis: serviciu afectat, seriile veche și nouă, owner, timestamp-uri, rezultat de validare, impact și acțiunea de follow-up

Automatizarea ajută numai când este observabilă

GWDG notează că clienții ACME compatibili cu ACME Renewal Information pot reînnoi automat, în timp ce cei fără suport necesită acțiune manuală. Distincția contează, dar nu este o garanție pentru mediul tău. Reînnoirea trebuie urmată de deploy, reload al serviciului și validare externă a endpoint-ului live.

Pentru organizațiile aliniate NIS2, dovada utilă este un registru repetabil de certificate legat de ownerii serviciilor și un traseu de excepție pentru furnizori sau sisteme legacy. Un screenshot din dashboardul de renew este mai slab decât o evidență datată care arată că endpoint-ul public și integrările dependente au acceptat certificatul înlocuit.

Transformă urgența într-un control durabil

Adaugă evenimentele de emitere și reînnoire a certificatelor în același flux care urmărește activele expuse și vulnerabilitățile. Atribuie owner, criticitatea serviciului, metoda de renew, ținta de deploy și regula de verificare. Testează procedura înainte ca următoarea revocare forțată sau ciclurile mai scurte de certificate să transforme un renew eșuat neobservat în downtime.

Awarely Monitor poate păstra remedierea legată de certificate alături de activele afectate, responsabili, termene și dovezi de validare. Rezultatul trebuie să fie o recuperare demonstrată, nu doar un ticket închis.