Hvis du nogensinde har undret dig over hvordan certifikatovervågningsværktøjer kan opdage certifikater til dine domæner uden at du manuelt uploader noget — er dette svaret. Certificate Transparency, almindeligvis forkortet CT, er et åbent framework der kræver at hvert offentligt betroet TLS-certifikat logges i en offentligt tilgængelig, kryptografisk verificerbar post. I det øjeblik en Certificate Authority (CA) udsteder et certifikat til dit domæne, skrives det certifikat til en CT-log som alle kan læse.

Dette er ikke et privatlivsproblem — det er en bevidst sikkerhedsmekanisme. At forstå hvordan det virker hjælper dig med at forstå både trusselmodellen det forsvarer mod og hvordan værktøjer som CertControl bruger det til at give dig et komplet billede af din eksterne certifikatoversigt.

Det problem CT var designet til at løse

Inden Certificate Transparency eksisterede, var certifikatudstedelsesprocessen i det væsentlige en sort boks. Når en CA udstedte et certifikat, var det kun CA'en og certifikatindehaveren der vidste om det. Der var ingen måde for en domæneejer at finde ud af om en uærlig CA — eller en kompromitteret — havde udstedt et certifikat til deres domæne uden deres viden.

Dette var et reelt og udnyttet problem. I 2011 blev den hollandske CA DigiNotar kompromitteret, og angribere brugte det til at udstede falske certifikater til Google, Mozilla og andre. Certifikaterne blev brugt til man-in-the-middle-angreb rettet mod iranske internetbrugere. DigiNotar blev ikke opdaget fordi nogen spottede certifikatet — det blev opdaget på grund af mistænkelig netværkstrafik. Skaden var da allerede sket.

Google-ingeniørerne Ben Laurie og Adam Langley foreslog Certificate Transparency i 2012 som en måde at gøre certifikatudstedelse reviderbar og transparent. RFC'en (6962) blev publiceret i 2013. I 2018 krævede Chrome at alle nye certifikater skulle logges i CT-logs — ellers ville browseren nægte at stole på dem.

Hvordan CT-logs fungerer

En CT-log er en offentligt tilgængelig, append-only datastruktur — et Merkle-træ — hvor certifikater gemmes på en måde der gør manipulation kryptografisk påviselig. Her er hvad der sker når en CA udsteder et certifikat:

  1. CA'en indsender certifikatet til én eller flere CT-logs inden eller umiddelbart efter signering.
  2. Loggen returnerer et Signed Certificate Timestamp (SCT) — et kryptografisk løfte om at certifikatet er logget. SCT'en indlejres i selve certifikatet eller leveres via TLS-udvidelse eller OCSP-stapling.
  3. Når din browser forbinder til en hjemmeside, kontrollerer den at en gyldig SCT er til stede. Ingen SCT betyder at certifikatet ikke er korrekt logget, og moderne browsere vil afvise det.
  4. Log-posten er permanent. Når et certifikat er i en CT-log, kan det ikke fjernes eller ændres. Selv efter at certifikatet udløber, forbliver posten.

Append-only-strukturen håndhæves matematisk. Hver ny post i loggen inkorporeres i et Merkle-træhash. Ethvert forsøg på at ændre en eksisterende post ville ændre hashen, hvilket gør det umiddelbart påviseligt for alle der auditerer loggen.

Hvad CT ikke dækker

Kun offentligt betroede certifikater kræves logget. Det betyder:

  • Interne/private CA-certifikater — certifikater udstedt af din egen interne CA er ikke i CT-logs.
  • Selvsignerede certifikater — heller ikke logget.
  • Kodesignerings- og e-mail-certifikater — CT dækker aktuelt TLS-certifikater; andre certifikattyper håndteres separat.

Hvad dette gør dine certifikater til offentlig information

Konsekvensen af CT er ligetil: hvert certifikat udstedt til et offentligt betroet domæne er en sag af offentlig rekord. Alle kan forespørge CT-logs og se:

  • Hvilke domæner og underdomæner du har certifikater til
  • Hvilken CA der udstedte hvert certifikat
  • Den præcise gyldighedsperiode (not-before og not-after datoer)
  • Alle Subject Alternative Names (SAN'er) — den fulde liste over domæner certifikatet dækker
  • Den offentlige nøgle og certifikat-fingerprint

Disse oplysninger er synlige ikke kun for dig og dine overvågningsværktøjer — de er synlige for alle, inklusiv sikkerhedsforskere, konkurrenter og angribere der laver rekognoscering. CT-log-aggregeringstjenester som crt.sh gør det trivielt nemt at søge efter alle certifikater nogensinde udstedt til et givet domæne.

Praktiske trin

Med ovenstående in mente er her de ting der er værd at gøre:

  1. Søg CT-logs for dine domæner nu. Gå til crt.sh og søg efter dit primære domæne. Kig på hvert underdomæne der dukker op. Er de alle forventede? Er nogen allerede udløbet? Er nogen udstedt af CA'er du ikke genkender?
  2. Opsæt CAA-records. Tilføj DNS CAA-records til dine domæner for at begrænse hvilke CA'er der kan udstede certifikater. Dette er en indsats med høj værdi og lav indsats.
  3. Overvåg for nye udstedelser. Opsæt overvågning så ethvert nyt certifikat udstedt til dine domæner udløser en advarsel. Dette bør være en del af ethvert eksternt attack surface-overvågningsprogram.
  4. Auditér underdomæner med certifikater. Hvert underdomæne i CT-logs er et potentielt indgangspunkt. Bekræft at alle er tilsigtede, vedligeholdte og ikke kører forældet software eller udløbne certifikater.

Hvordan CertControl bruger CT-logs

Når du tilføjer et domæne til CertControls eksterne scanner, er en af de første ting platformen gør at forespørge CT-log-aggregeringstjenester for at finde hvert certifikat nogensinde udstedt til det domæne og alle dets underdomæner. Dette giver dig en øjeblikkelig oversigt over dit eksterne certifikatfodaftryk uden agentinstallation eller manuel input.

Sådan kan CertControl vise underdomæner du måske har glemt, certifikater udstedt af CA'er du ikke autoriserede, og certifikater der allerede er udløbet men stadig synlige i log-historikken. CT-data kombineres med aktiv DNS-opløsning og portscanning for at bekræfte hvilke certifikater der aktuelt er i brug.