Proprietarul unui site solicită un certificat TLS de la o Autoritate de Certificare (CA). Certificatul leagă domeniul de cheia publică folosită pentru conexiunea HTTPS.Certificate Transparency funcționează împreună cu Web PKI: jurnalul append-only face emiterea verificabilă, navigatorul poate verifica consistența criptografică a jurnalelor, iar monitoarele urmăresc certificate sau jurnale suspecte.De reținut: CT nu înlocuiește validarea domeniului; adaugă transparență și verificare procesului de emitere.
2
Generare precertificat
CA verifică dreptul proprietarului de a solicita certificatul și creează un precertificat care leagă domeniul de cheia publică. Precertificatul conține informațiile certificatului final.El include extensia specială „poison”, astfel încât navigatorul să nu îl accepte drept certificat TLS. Precertificatul rezolvă dependența CT: certificatul are nevoie de SCT înainte de emitere, iar SCT-ul poate fi obținut numai după trimiterea unui obiect către jurnal.De reținut: precertificatul este folosit pentru publicare și verificare, nu pentru instalarea pe server.
3
Trimitere către CT Logs
Oricine poate trimite un certificat către un jurnal, însă majoritatea obiectelor sunt trimise de Autoritățile de Certificare. CA trimite precertificatul către unul sau mai multe jurnale CT publice.La acceptare, jurnalul răspunde cu un Signed Certificate Timestamp (SCT): promisiunea semnată că obiectul va fi inclus înainte de expirarea intervalului Maximum Merge Delay (MMD).Transfer: Autoritatea de Certificare → jurnalele CT → dovada SCT.
4
Înregistrare în CT Log
Jurnalul păstrează certificatele într-un registru public append-only: intrările pot fi adăugate, dar nu șterse, modificate sau inserate retroactiv. Registrul este verificabil criptografic și auditabil public.Hash-urile certificatelor formează frunzele unui arbore Merkle, iar nodurile sunt hash-urile perechilor de copii. Jurnalul semnează rădăcina și creează un Signed Tree Head (STH). Periodic, intrările noi sunt combinate cu arborele existent și este semnat un STH nou.De reținut: oricine poate verifica includerea unei intrări și consistența dintre versiunile jurnalului.
5
Returnare SCT
Fiecare jurnal returnează imediat CA-ului un SCT și se angajează să includă obiectul în Maximum Merge Delay (MMD). Documentația sursă indică de regulă un MMD de 24 de ore, interval care permite remedierea problemelor fără blocarea emiterii sau folosirii certificatelor.CA atașează SCT-urile certificatului, în mod obișnuit printr-o extensie X.509v3, apoi semnează certificatul. Alte mecanisme sunt OCSP stapling și extensia TLS. CT nu impune modificarea administrării obișnuite a serverului.De reținut: SCT-ul este promisiunea semnată; dovada de includere confirmă ulterior respectarea ei.
6
Emitere certificat final
CA semnează certificatul final și îl livrează proprietarului domeniului pentru instalarea pe server. SCT-urile însoțesc certificatul pe întreaga lui durată de viață.În timpul handshake-ului TLS, serverul livrează certificatul împreună cu SCT-ul. Handshake-ul este etapa în care clientul și serverul se verifică și stabilesc algoritmii și cheile folosite pentru conexiunea criptată.Transfer: jurnale CT → CA → proprietarul domeniului → serverul HTTPS.
7
Verificare în navigator
Navigatoarele și ceilalți user agents contribuie la aplicarea Certificate Transparency. Ele verifică certificatul și dovezile SCT prezentate de server în conexiunea HTTPS.Numărul și alegerea jurnalelor sunt stabilite prin politica fiecărui user agent. Documentația sursă precizează că politicile Chrome și Safari cer cel puțin două SCT-uri, în funcție de durata certificatului; cerințele exacte pot evolua odată cu politicile navigatoarelor.De reținut: navigatorul verifică dovada CT și poate refuza certificatele care nu respectă politica aplicabilă.
8
Monitorizare și detectare
Monitoarele sunt servicii publice care contactează periodic toate jurnalele și urmăresc certificate suspecte. Ele îi ajută pe operatorii site-urilor să observe certificate neautorizate sau obiecte cu extensii și permisiuni neobișnuite.Monitoarele calculează dovezi de consistență pentru a confirma că o versiune nouă conține întreaga versiune anterioară și dovezi de audit pentru a confirma prezența unui certificat. Companii, organizații, servicii de abonament și persoane individuale pot opera monitoare.De reținut: CT nu blochează singur emiterea greșită; o face publică, auditabilă și mult mai ușor de detectat.
SCT = Signed Certificate Timestamp
Proprietar domeniu Autoritate de Certificare (CA) CT Log Server Browser / User Agent Monitoare CT
02
Ce se întâmplă la fiecare pas
Când un site își obține certificatul, autoritatea de certificare nu îl poate considera final până nu obține
o dovadă de timp de la un jurnal recunoscut. Dovada este o promisiune criptografică:
„acest certificat a fost acceptat și va apărea public”.
Jurnalul organizează toate înregistrările într-un arbore Merkle — o structură în care
fiecare nod este o amprentă a copiilor săi. Astfel, orice înregistrare are o amprentă unică, iar jurnalul
nu poate șterge sau modifica trecutul fără să rupă lanțul de dovezi de consistență.
Monitorul urmărește jurnalele și semnalează certificate noi pentru domenii importante.
Auditorul verifică periodic că arborele este corect construit și că jurnalul nu a rescris istoricul.
Navigatorul refuză să considere de încredere un certificat fără dovezile cerute de politică.
03
Rolurile din ecosistem
Jurnal
Registru public în care certificatele se adaugă, nu se șterg și nu se modifică.
Autoritate de certificare
Entitatea care emite certificatul și îl înregistrează la jurnal.
Navigator
Programul care verifică dovezile de timp înainte de a afișa site-ul.
Monitor și auditor
Entități care supraveghează jurnalele și detectează abateri.
04
De ce contează pentru SSL.RO
Pentru SSL.RO, jurnalele CT sunt sursa de istoric a domeniilor .ro. Deoarece înregistrările
sunt publice și imutabile, putem reconstrui cronologic ce certificate au existat pentru un domeniu, inclusiv
precertificate care nu au ajuns niciodată în producție.
Registrul nostru filtrează aceste date pentru spațiul .ro, leagă certificatele de domenii și de numele
alternative, separă precertificatele de certificatele finale și le integrează cu verificarea TLS live —
astfel încât un utilizator să vadă atât istoricul CT, cât și starea actuală a site-ului.
05
Unde se află dovezile de timp într-un certificat
Certificatul final poate conține una sau mai multe dovezi de timp într-o extensie X.509 dedicată,
numită „lista de dovezi de timp”. Navigatorul o citește la validarea lanțului:
Element
Rol
Certificat final
Certificatul semnat de autoritate, cu domeniul și numele alternative.
Lista de dovezi
Extensia care conține dovezile de timp obținute de la jurnale.
Precertificat
Varianta de dinaintea finalizării, înregistrată la jurnal în avans.
Lanț
Șirul autorității intermediare până la rădăcină, folosit la validare.
Dacă dovezile nu sunt în certificat, ele pot ajunge la client prin răspunsul OCSP sau ca
extensie TLS separată în timpul conectării.
06
Cum funcționează un jurnal CT, în practică
Un jurnal este un serviciu cu o politică strictă: înregistrările se adaugă, dar nu se șterg și nu se
modifică. Operațiunile de bază sunt:
Adăugarea unui certificat — înregistrarea unui certificat final;
Adăugarea unui precertificat — înregistrarea înainte de finalizare;
Cererea unei dovezi — dovada de includere sau de consistență.
Jurnalul publică periodic antetul semnat al arborelui. Oricine poate descărca întregul conținut al
jurnalului și poate reconstrui arborele local, pentru a verifica dacă antetul este corect. Această
verificare independentă este exact ceea ce face un auditor.
07
Cum verifică navigatorul
Primește certificatul și dovezile de timp (din extensie, din răspunsul OCSP sau din TLS).
Validează lanțul criptografic până la o rădăcină de încredere.
Verifică semnătura fiecărei dovezi cu cheia publică a jurnalului.
Aplică politica CT: numărul minim de dovezi și lista de jurnale acceptate.
Dacă orice pas eșuează, certificatul este tratat ca neîncredere.
08
Ce extrage SSL.RO din jurnale
Domeniul principal și toate numele alternative;
Emitentul și perioada de valabilitate;
Tipul înregistrării: precertificat sau certificat final;
Momentul observării și jurnalul sursă;
Amprenta certificatului, pentru corelare unică.
09
Exemplu practic
Să presupunem că un domeniu exemplu.ro primește un certificat nou:
Autoritatea trimite un precertificat la jurnal; acesta devine vizibil imediat.
Jurnalul semnează o dovadă de timp și o întoarce.
Autoritatea emite certificatul final cu dovada inclusă.
Jurnalul publică și certificatul final, cu câteva minute mai târziu.
SSL.RO detectează ambele înregistrări, le leagă de exemplu.ro și le păstrează în istoric.
10
Limitări și nuanțe
CT nu spune cine deține domeniul; spune ce certificate au fost observate public.
Un certificat poate exista în jurnal, dar să nu fi fost niciodată servit în producție.
Înregistrările apar cu o mică întârziere față de emitere, specifică fiecărui jurnal.
Certificatele private (interne, de întreprindere) pot lipsi din jurnalele publice.
11
Cum citește SSL.RO jurnalele, pas cu pas
1. Lista jurnalelorMenținem jurnalele publice acceptate de ecosistem.
→
2. SincronizareFiecare jurnal este citit de la ultima poziție procesată.
→
3. LoturiDescărcăm înregistrări în loturi.
→
4. ParsareDecodăm certificate și precertificate.
→
5. Filtrare .roPăstrăm doar numele cu relevanță pentru spațiul românesc.
→
6. IndexareScriem în istoric cu sursă, jurnal și moment.
→
7. CorelareLegăm de verificarea TLS live și monitorizare.
Fiecare înregistrare primește jurnalul sursă, poziția în arbore și momentul observării — deci știm exact de unde a apărut.
După parsare, domeniul principal și toate numele alternative sunt indexate separat.
Precertificatele și certificatele finale sunt păstrate separat, dar corelate prin conținut.
Istoricul este definitiv: nu suprascriem nicio observație veche.
12
Incidente care au dus la CT
DigiNotar (2011): autoritatea olandeză a fost compromisă, iar atacatorii au emis certificate frauduloase pentru domenii critice (Google, Yahoo, Mozilla). Compromiterea a rămas nedetectată aproximativ o lună.
Comodo (2011): un partener de înregistrare compromis a emis nouă certificate pentru domenii importante, fără autorizația proprietarilor.
Răspunsul Google: în 2011–2013 a propus Transparența Certificatelor, standardizată în 2013 prin RFC 6962.
Adoptarea navigatoarelor: Chrome a început să ceară dovezile în etape (2015–2018), iar Apple și Mozilla au urmat cu politici proprii.
RFC 9162 (2021): revizuirea standardului, folosită astăzi de întreg ecosistemul.
13
Întrebări frecvente
De ce apar mai multe certificate pentru același domeniu?
Pentru reînnoiri, emitenți diferiți, domenii cu mai multe nume alternative sau precertificate plus certificate finale.
Poate cineva să ascundă un certificat?
Poate folosi un jurnal neinclus în politicile navigatoarelor, dar atunci navigatoarele îl pot respinge; pentru spațiul .ro, SSL.RO urmărește jurnalele publice importante.
Ce înseamnă „observat în jurnal”?
Înseamnă că un jurnal public a acceptat și a publicat înregistrarea, cu o dovadă criptografică de includere.
Cât de repede apare o înregistrare?
De obicei în câteva minute de la emitere; unele jurnale publică în loturi.
