Sistemi, infrastruktura in odpornost
POTRDILO JE NOVO, STORITEV PA PONUJA STARO
Kako krajša veljavnost javnih TLS-potrdil spreminja obnovo, distribucijo in preverjanje resnične produkcijske konfiguracije
Novo potrdilo je že v centralni shrambi. Izdajatelj je potrdil uspešno naročilo, avtomatizacija ni javila napake in datum poteka se je premaknil za več mesecev. Na enem od robnih strežnikov pa naslednja povezava še vedno prejme staro potrdilo. Njegova veljavnost se izteka, čeprav je iz vidika sistema za obnovo delo opravljeno. To je ponazoritev možne odpovedi, ne poročilo o konkretnem incidentu.
Takšna razlika med evidenco in dejansko storitvijo postaja pomembnejša. CA/Browser Forum je s sprejetjem glasovanja SC081v3 določil postopno krajšanje največje veljavnosti javno zaupanja vrednih strežniških TLS-potrdil. Od 15. marca 2026 je zgornja meja 200 dni, od 15. marca 2027 bo 100 dni, od 15. marca 2029 pa 47 dni. Pred prvo spremembo je znašala 398 dni. Meje veljajo glede na datum izdaje potrdila; že izdanemu potrdilu se ob začetku nove stopnje njegova zapisana veljavnost ne skrajša za nazaj. [1][2]
Krajši rok spremeni pogostost, ne merila uspeha
Veljavne Baseline Requirements ločeno urejajo še ponovno uporabo podatkov, dokumentov ali že opravljenega preverjanja nadzora nad domeno oziroma naslovom IP. Za potrdila, izdana od 15. marca 2026, je to obdobje največ 200 dni, od marca 2027 največ 100 dni, od marca 2029 pa samo še 10 dni. Leta 2029 torej 47-dnevna veljavnost potrdila ne bo pomenila, da sme izdajatelj enako dolgo ponovno uporabljati staro preverjanje domene. Gre za dve različni omejitvi. [2]
Obnovitveni postopek mora zato ohraniti sposobnost ponovnega dokazovanja nadzora nad domeno tudi takrat, ko potrdilo, ki je trenutno nameščeno na strežniku, še deluje. Pri validaciji z ACME je to lahko odvisno od dostopnosti DNS, pravic API-računa, pravilne objave izziva ali dosegljivosti strežnika, odvisno od izbrane metode. Samodejna izdaja odpove že pred prevzemom novega potrdila, če odpove katera od teh odvisnosti. Protokol ACME opisuje mehanizem avtomatiziranega naročanja in preverjanja, ne pa celotnega obratovalnega postopka v organizaciji. [3]
Te zahteve veljajo za javno zaupanja vredna strežniška potrdila, zajeta v pravilih CA/Browser Forum. Niso splošna omejitev življenjske dobe vsakega potrdila. Interna storitev, ki uporablja zasebno PKI z lastnim korenskim potrdilom zaupanja, ima lahko drugačne roke in postopke; enako ni dopustno brez dodatne podlage posploševati teh rokov na podpisovanje programske opreme ali druge vrste potrdil. Tudi pri zasebni PKI pa ostane vprašanje, ali storitev dejansko uporablja pravilno poverilnico. [2]
Potrdilo se mora prebiti do povezave
Med uspešno izdajo in uspešno zamenjavo v produkciji je več samostojnih korakov. Izdajatelj izda potrdilo. Sistem za obnovo ga prevzame ter poveže z ustreznim zasebnim ključem in verigo vmesnih potrdil. Distribucijski postopek ga dostavi na predvidene sisteme. Tam mora biti nameščeno na pravo mesto, nato pa ga mora TLS-proces dejansko aktivirati. Šele naslednja povezava pokaže, ali odjemalec prejme novo potrdilo. Potrditev prejšnje faze ne dokazuje naslednje.
Centralna certifikatna shramba ni isto kot konfiguracija poslušalca HTTPS. Njen novi zapis lahko čaka na sinhronizacijo, lokalni spletni strežnik pa še vedno bere stare datoteke. Nekatere storitve potrdila naložijo šele ob ponovnem nalaganju konfiguracije ali ponovnem zagonu, druge uporabljajo neposredno povezavo z upravljano shrambo oziroma časovno omejen predpomnilnik. Pri slednjih je treba razumeti, kdaj in pod kakšnimi pogoji se aktivna različica dejansko zamenja.
V večjem okolju TLS morda sploh ne zaključuje aplikacijski strežnik. Povezavo lahko sprejme upravljalnik prometa, povratni posrednik ali robno vozlišče ponudnika CDN, za njim pa nastane nova povezava TLS do aplikacije. Na zunanji in notranji strani sta lahko uporabljeni različni potrdili, vključno z internim potrdilom zasebne PKI. Pregled certifikatne shrambe aplikacijskega vozlišča v takšni arhitekturi ne pove, kaj je prejel uporabnik na internetu. Enaka težava nastane pri geografsko razpršenih vozliščih ali pri ponudniku, ki zamenjavo upravlja ločeno od naročnika.
Kaj pove resnična vzpostavitev TLS
Zaključni preizkus mora potekati na ravni storitve, ki jo uporablja odjemalec. Vzpostaviti je treba TLS-povezavo z ustreznim imenom SNI (Server Name Indication), zajeti predstavljeno končno potrdilo in preveriti njegovo veljavnost, ujemanje identitete storitve, verigo zaupanja ter pričakovano različico. RFC 9525 določa pravila preverjanja identitete storitve; ogled serijske številke ali prstnega odtisa sam zase ni nadomestilo za veljavno preverjanje zaupanja. [6][7]
SNI ni malenkost. Na istem naslovu IP je lahko več navideznih strežnikov, zato lahko povezava brez pravilnega imena prikaže privzeto potrdilo in ustvari napačen zaključek. Za ciljno diagnostiko je mogoče uporabiti denimo openssl s_client z možnostma -connect in -servername, vendar rezultat enega poskusa velja samo za preverjeno pot. Povezava prek običajnega DNS lahko večkrat doseže isto vozlišče, druga pot po IPv6, druga javna IP-vstopna točka ali druga regija pa lahko še vedno ponuja starejšo različico. [7]
Nadzor mora zato poznati inventar dejanskih TLS-terminacij: imena storitev, javne naslove, poslušalce, prometne skupine, regije in zunanje upravljavce, pri katerih je razlikovanje izvedljivo. Kjer različna vozlišča namenoma uporabljajo različna potrdila, merilo ni enak prstni odtis povsod, ampak skladnost vsakega vozlišča s pričakovano in dovoljeno konfiguracijo. Posebej je treba preveriti še pot po ponovni vzpostavitvi storitve ali povrnitvi predhodne konfiguracije, saj lahko uspešen rollback znova aktivira potrdilo, ki bo kmalu poteklo.
ARI pove, kdaj poskusiti, ne kaj je že zamenjano
ACME Renewal Information (ARI), standardiziran v RFC 9773 junija 2025, izdajatelju omogoča, da odjemalcu za konkretno potrdilo predlaga časovno okno obnove (suggestedWindow). Odjemalec lahko poskuse ustrezno razporedi, spremlja spremembe priporočila in pri težavah uporablja predpisano obravnavo napak ter nadomestni urnik. Z navedbo replaces v naročilu lahko označi potrdilo, ki ga novo naročilo nadomešča. To pomaga tudi ob izredni potrebi po zgodnejši obnovi, ni pa samo po sebi dokaz, da je nova različica že aktivna na produkcijskih vstopnih točkah. [4]
Prakso v velikem obsegu je marca 2026 opisal inženir Shopifyja v tehničnem prispevku pri Let's Encrypt. Njihov sistem je statični prag za obnovo zamenjal z upoštevanjem priporočil ARI pri upravljanju potrdil za številne trgovske domene. To je relevanten primer boljšega časovnega usklajevanja izdaje, ne univerzalno zagotovilo, da vsaka aplikacija, posrednik ali CDN po uspešnem naročilu samodejno uporablja pravo potrdilo. Podpora ARI je poleg tega odvisna od izdajatelja in različice odjemalca ACME. [5]
Zadnji korak potrebuje lastnika
Dober nadzor ločeno beleži vsaj datum poteka potrdila v upravljani shrambi in datum poteka potrdila, ki ga določena produkcijska vstopna točka dejansko predstavlja. Razlika med njima je signal za preverjanje, ne samodejen dokaz incidenta. Ob spremembi je koristno zapisati tudi identifikator naročila, čas dostave, rezultat namestitve, uspešnost aktivacije ter rezultat neodvisnega omrežnega testa. Opozorila morajo upoštevati čas do izteka in omogočati ponovno izvajanje, eskalacijo ter obravnavo delnega uspeha.
Odgovornost mora segati čez mejo med ekipo za PKI, skrbniki omrežja, lastnikom aplikacije in zunanjim ponudnikom. Izdajatelj lahko zagotovi novo potrdilo, ne more pa potrditi, da je naročnikov upravljalnik prometa osvežil konfiguracijo. Samodejna distribucija zasebnih ključev prav tako zahteva omejene pravice in ustrezno zaščito ključnega materiala; razpoložljivosti ni smiselno izboljševati z nekontroliranim razširjanjem zasebnih ključev.
Pri javnih potrdilih bo leta 2029 dovoljeni rok lahko znašal največ 47 dni. To ne spremeni pomena uspešne obnove, poveča pa pogostost trenutkov, ko se mora veriga izdaje, distribucije in aktivacije izkazati. Postopek je zaključen šele, ko so vsa predvidena mesta uporabe preverjeno prešla na ustrezno potrdilo oziroma je razlika evidentirana in pravočasno obravnavana. Zapis »potrdilo obnovljeno« je dokaz le za tisti del postopka, ki ga je sistem dejansko preveril.
EVIDENCE PROFILE
Dokazni profil članka
Profil pokaže vrsto dokazne podlage in omejitve osrednjega argumenta.
Viri
- 01PRIMARY DOCUMENTATIONCA/Browser Forum, *Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods*, 11. april 2025.Odpri vir ↗
- 02PRIMARY DOCUMENTATIONCA/Browser Forum, *Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates*, različica 2.3.1, 4. oktober 2026, razdelka 4.2.1 in 6.3.2.Odpri vir ↗
- 03PRIMARY DOCUMENTATIONIETF, *RFC 8555: Automatic Certificate Management Environment (ACME)*, marec 2019.Odpri vir ↗
- 04PRIMARY DOCUMENTATIONIETF, A. Gable, *RFC 9773: ACME Renewal Information (ARI) Extension*, junij 2025.Odpri vir ↗
- 05PRIMARY DOCUMENTATIONLet's Encrypt, N. Silverman, *Simplifying Certificate Renewals for Millions of Domains with ACME Renewal Information (ARI)*, 17. marec 2026.Odpri vir ↗
- 06PRIMARY DOCUMENTATIONIETF, *RFC 9525: Service Identity in TLS*, november 2023.Odpri vir ↗
- 07PRIMARY DOCUMENTATIONOpenSSL, *openssl-s_client*, dokumentacija za različico 3.5, možnosti `-connect`, `-servername` in preverjanje identitete.Odpri vir ↗