Brauserid ja sertifikaatide kontrollimine

Sissejuhatus

HTTPS (SSL-i kaudu /TLS) kasutab avaliku võtme krüptimine kaitsta brauseri suhtlust Interneti kaudu edastamise eest lugemise või muutmise eest. Serverid pakuvad külastavatele brauseritele avaliku võtme, mida kasutatakse krüptitud ühenduse loomiseks kõigi järgnevate andmevahetuste jaoks.

Kuid just a töö avalik võti üksi ei taga, et see (ja laiendusena server) tõesti kuulub õigele puldile teema (st isik, ettevõte või organisatsioon). Man-in-the-middle ründajad saavad võrkudega manipuleerida omaenda võtmete teenimiseks, seades sellega ohtu igasuguse suhtluse.

Brauserid takistavad seda autentimine HTTPS-serverid, mis kasutavad tunnistused, mis on digitaalsed dokumendid siduda avalik võti üksikule subjektile. Sidumine kinnitatakse usaldusväärse võtme olemasoluga.sertifitseerimisasutus (CA), näiteks SSL.com kontrollige kvalifitseeritud andmebaaside automaatse ja käsitsi kontrolli abil võimalike sertifikaadiomanike identiteeti.

See usaldussuhe tähendab, et veebikasutaja turvalisus ei ole absoluutne; pigem nõuab see kasutajatelt brauserite ja sertimisasutuste usaldamist oma turvalisuse kaitsmiseks. Seetõttu on iga kasutaja huvides omada põhiteadmisi sertifikaatide valideerimise toimimisest.

Pane tähele, et sertifikaadi valideerimise protsess (mida on üksikasjalikult kirjeldatud standarddokumendis RFC 5280) on üsna keerukas. Selles artiklis proovime teid mööda ühte teed minna (brauser, mis kontrollib hosti SSL-i /TLS sertifikaat) ja liikuda keerukates üksikasjades, mis on enamiku kasutajate jaoks ebaolulised.

Märge: Alates 2024. aasta augustist RFC 9618, Interneti-tehnika töörühma (IETF) dokument, on uuendanud RFC 509-st pärit X.5280 digitaalsete sertifikaatide poliitikapiirangute valideerimise algoritmi.

Sertifikaadid ja vorming X.509

Sertifikaadid on igas mõttes digitaalsed failid, mis tähendab, et teabe (nt allkirjad, võtmed, väljastajad jne) salvestamiseks peavad need järgima failivormingut. Kuigi privaatsed PKI konfiguratsioonid saavad rakendada oma sertifikaatide jaoks mis tahes vormingut, mis on avalikult usaldusväärne PKId (st need, mida brauserid usaldavad) peavad vastama RFC 5280-le, mis nõuab järgmise kasutamist: X.509 v3 formaadis.

X.509 v3 võimaldab sertifikaatidel lisada täiendavaid andmeid, näiteks kasutuspiiranguid või teavet poliitika kohta laiendused, kusjuures iga pikendus on kas kriitiline or mittekriitiline. Kui klient kohtab tundmatut mittekriitilist laiendust, võib ta seda ignoreerida. Kui laiendus on kriitiline ja tundmatu või seda ei saa töödelda, tuleb sertifikaat tagasi lükata.

Sertifitseerimise teed ja teede töötlemine

Sertifikaatide asutused kasutavad kõigi väljastatud sertifikaatide krüptograafiliseks allkirjastamiseks privaatvõtit. Sellised allkirjad võivad... krüptograafiliselt tõendama, et sertifikaadi väljastas konkreetne CA ja et seda ei ole pärast allkirjastamist muudetud.

CA kinnitavad oma allkirjastamisvõtme omandiõiguse, omades ise väljastatud sertifikaati (nn juur) vastava avaliku võtme jaoks. CA-d peavad juurkataloogi loomiseks, haldamiseks ja kasutamiseks järgima rangelt kontrollitud ja auditeeritud protseduure ning kokkupuute minimeerimiseks kasutavad nad tavaliselt juurkataloogi väljastamiseks. kesktaseme sertifikaadid. Neid vahendajaid saab seejärel kasutada oma klientidele sertifikaatide väljastamiseks. Juur-CA sertifikaat on iseallkirjastatud ja privaatvõtit kaitstakse rangete protseduuride abil. Väljastamine toimub tavaliselt vahendajate kaudu, mitte otse juurtest.

Brauseritele tarnitakse sisseehitatud usaldusväärsete juurte loend. (Need juured pärinevad CA-delt, kes on läbinud brauseri ranged kaasamise kriteeriumid.) Sertifikaadi kinnitamiseks hangib brauser järjestuste sertifikaadid, millest igaüks on allkirjastanud järjestuse järgmise sertifikaadi, ühendades allkirjastava CA juur serveri serveriga. tunnistus.

Seda sertifikaatide jada nimetatakse a-ks sertifitseerimise tee. Tee juurt nimetatakse a usalda ankrut ja serveri sertifikaati nimetatakse leht or lõppüksus tunnistus.

Tee ehitus

Veebibrauserid ja tarkvarakliendid võivad sageli luua mitu usaldusankru kandidaati (nt ristmärkide tõttu) ja tuua ahela lõpuleviimiseks AIA kaudu puuduvaid vaheühendeid. Isegi kui tee võib sisaldada sertifikaate, mis on korralikult teadaoleva ankruga ühendatud, võidakse tee ise tagasi lükata tee pikkuse, domeeninime, sertifikaatide kasutamise või poliitika piirangute tõttu.

Kõigi võimalike teede ehitamine ja hindamine on kallis protsess, mida viiakse läbi iga uue sertifikaadi jaoks, mida brauser kohtab. Brauserid on rakendanud erinevaid optimeerimisi, et minimeerida tagasilükatud kandidaaditeede arv, kuid selliste üksikasjade uurimine jääb selle artikli ulatusest kaugemale.

Tee valideerimine

Pärast kandidaatide sertifitseerimise tee koostamist kontrollivad brauserid seda sertifikaatides sisalduva teabe abil. Tee on kehtiv, kui brauserid suudavad krüptograafiliselt tõestada, et alates otse usalduse ankru allkirjastatud sertifikaadist kasutati iga järgmise sertifikaadi vastavat privaatvõtit teele järgmise väljaandmiseks kuni lehesertifikaadini.

Baasnõuded nõuavad, et subjekti ja väljastaja nimed oleksid kõikjal kõik võimalikud teed be bait-baidilt identne, mis lihtsustab usaldusväärse tee ehitamist.

Sertifitseerimise tee valideerimise algoritm

Nagu varem märgitud, siis seisuga august 2024. RFC 9618, Interneti-tehnika töörühma (IETF) dokument, on uuendanud RFC 509-st X.5280 digitaalsete sertifikaatide poliitikapiirangute valideerimise algoritmi. Põhimõtteliselt käivad brauserid läbi kõik teel olevad sertifikaadid, alustades usaldusankrust (st juursertifikaadist), valideerides iga sertifikaadi põhiteavet ja kriitilisi laiendusi.

Kui protseduur lõpeb vigadeta viimase sertifikaadiga teel, loetakse see tee kehtivaks. Vigade korral märgitakse tee kehtetuks.

Põhitunnistuse töötlemine

Olenemata laienditest peavad brauserid alati kontrollima põhilisi sertifikaatide andmeid, nagu näiteks allkiri või väljaandja. Järgmistes jaotistes on toodud brauserite kontrollide jada.

1. Brauser kontrollib sertifikaadi terviklikkust

. allkiri sertifikaadil saab kontrollida tavalise avaliku võtme krüptograafia abil. Kui allkiri on vale, loetakse sertifikaat pärast selle väljaandmist muudetuks ja lükatakse seetõttu tagasi.

2. Brauser kontrollib sertifikaadi kehtivust

Tunnistuse oma kehtivusaeg on ajavahemik, mille jooksul allkirjastav CA tagab, et säilitab teavet oma oleku kohta. Brauserid lükkavad tagasi kõik sertifikaadid, mille kehtivusaeg lõpeb enne valideerimise kontrolli kuupäeva ja kellaaega või algab pärast seda.

3. Brauser kontrollib sertifikaadi tühistamise olekut

Sertifikaadi väljastamisel eeldatakse, et see on kasutusel kogu selle kehtivusaja jooksul. Muidugi võivad erinevad asjaolud põhjustada sertifikaadi kehtetuse enne selle loomulikku kehtivusaega.

Sellised asjaolud võivad hõlmata subjekti nime muutmist või kahtlustatavat privaatvõtme rikkumist. Sellistel juhtudel peab CA tühistama vastava sertifikaadi ja kasutajad usaldavad ka CA-sid, et teavitada brausereid nende sertifikaatide tühistamise olekust.

Sertifikaadi tühistamise loendid (CRL)

Sertifikaatide tühistusloendid (CRL-id) on alates 2024. aastast saanud sertifikaatide tühistuskontrolli valdkonna standardiks. Sertifikaatide asutused väljastavad perioodiliselt allkirjastatud ja ajatempliga varustatud tühistussertifikaatide nimekirju, mida brauserid saavad alla laadida ja lokaalselt vahemällu salvestada.

Kuigi varem peeti CRL-e vähem tõhusaks kui reaalajas kontrollimeetodeid, on tööstusharu tunnistanud olulisi eeliseid, mis muudavad need eelistatud lähenemisviisiks:

• Täiustatud privaatsusSertifikaatide tühistamisloendid (CRL-id) kaitsevad kasutajate privaatsust, välistades vajaduse pärida välistelt serveritelt konkreetsete sertifikaatide kohta, mis võivad paljastada sirvimismustreid.
• Töö efektiivsusCA-d saavad tühistamisi tõhusamalt hallata ilma reaalajas reageerimisteenuseid pakkuvaid kõrge kättesaadavusega teenuseid säilitamata.
• Vähendatud infrastruktuurikuludÖöpäevaringselt töötavate OCSP-reageerijate vajaduse kaotamine vähendab oluliselt tegevuskulusid.
• Parem vahemällu salvestamineKaasaegsed brauserid saavad CRL-e tõhusalt vahemällu salvestada ja uuendada, minimeerides latentsusprobleeme, mis varem eelistasid reaalajas meetodeid.

Alates 2024. aasta märtsist CA/Browser Forum nõuab kõigilt avalikult usaldusväärsetelt CA-delt CRL-ide esitamist, muutes muud tühistamismeetodid valikuliseks.Mõned suuremad sertifitseerimiskeskused on loobunud alternatiivsetest tühistamisteenustest ja eelistanud ainult CRL-idel põhinevaid lähenemisviise.

Veebisertifikaadi oleku protokoll (OCSP)

Veebipõhise sertifikaadi staatuse protokoll (OCSP), mida on kirjeldatud artiklis RFC 6960, loodi reaalajas sertifikaatide tühistamise kontrollimiseks, võimaldades brauseritel OCSP-serveritelt (vastajatelt) konkreetsete sertifikaatide kohta päringuid esitada. Kuigi OCSP võeti 2010. aastatel laialdaselt kasutusele perioodiliste CRL-ide allalaadimiste täiustusena, on tööstusharu sellest lähenemisviisist suures osas loobunud.

• OCSP on nüüd avalikult usaldusväärsete CA-de jaoks valikuline (jõustub alates 2024. aasta märtsist). OCSP olulisus on langeb; näiteks, Let's Encrypt eemaldas OCSP URL-id 2025. aasta mais ja sulges vastajad august 2025.
• Mõned brauserid on OCSP kontrollimise keelanud või rakendanud seda viisil, mis pakub minimaalset turvalisuse kasu.

OCSP klammerdamineVariant nimega OCSP klammerdamine jääb kasulikuks mõnes olukorras, kus serverid lisavad OCSP-vastused otse TLS käepigistus, vältides eraldi kliendipäringute saatmist OCSP-vastajatele. See nõuab aga spetsiifilist serveri konfiguratsiooni. Enamik servereid/CDN-e toetab klammerdamist, kuid selle kasulikkus väheneb, kuna suured CA-d OCSP-st loobuvad.

Kuidas see tänapäeval brauserites töötab: Alates 15. märtsist 2024 nõuab CA/B foorum avalikult usaldusväärsetelt CA-delt CRL-ide avaldamist, samas kui OCSP on valikuline. Kaasaegsed brauserid üldiselt ei päri OCSP-d ega laadi CRL-e alla saidi kaupa. Selle asemel kasutavad nad CA avaldatud CRL-idest loodud koondmehhanisme: Chrome'i CRLSets ja Firefoxi CRLite edastavad klientidele kiireid ja privaatsust kaitsvaid tühistamisandmeid. Selle tulemusel OCSP roll avalikus veebis väheneb; näiteks Let's Encrypt eemaldas OCSP URL-id 2025. aasta mais ja sulges OCSP vastajad 2025. aasta augustis.

4. Brauser kontrollib väljaandjat

Sertifikaadid on tavaliselt seotud kahe üksusega:

1. . emitent, mis on allkirjastamisvõtit omav üksus ja
2. . teema, mis viitab selle avaliku võtme omanikule, mida sertifikaat autentib.

Kliendid kontrollivad, kas iga teel olev sertifikaat on allkirjastatud eelmise sertifikaadi avaliku võtmega ja kas väljastaja/subjekti nimed vastavad teel täpselt. Lisaturvalisuse tagamiseks enamik PKI Rakendused kontrollivad ka, et väljastaja võti oleks sama, mis võti, millega kehtiv sertifikaat allkirjastati. (Pange tähele, et see ei kehti usaldusankru kohta, kuna juured on ise väljastatud – st neil on sama väljastaja ja subjekt.)

Piirangute töötlemine

Vorm X.509 v3 võimaldab CA-l määratleda piirangud või piirangud iga sertifikaadi valideerimisele ja kasutamisele kriitiliste laienditena. Iga teel olev sertifikaat võib seada täiendavaid piiranguid, mida kõik järgnevad sertifikaadid peavad järgima.

Sertifikaatide piirangud mõjutavad keskmist Interneti-kasutajat harva, ehkki need on ettevõtte SSL-lahendustes üsna tavalised. Funktsionaalsed piirangud võivad olla mitmel operatiivsel eesmärgil, kuid nende kõige olulisemaks kasutuseks on teadaolevate julgeolekuprobleemide leevendamine.

5. Brauser kontrollib nimepiiranguid

Eraomandis olev (kuid avalikult usaldusväärne) vahepealne CA koos asjakohastega nimepiirangud võib anda organisatsioonile sertifikaatide haldamise ja väljastamise üle täpse kontrolli. Sertifikaate saab piirata ettevõtte või organisatsiooni domeeninime kindla domeeni või domeenipuuga (st. alamdomeenid kaasa arvatud). Nimepiiranguid kasutatakse sageli avalikult usaldusväärselt CA-lt ostetud vahepealsete CA-sertifikaatide puhul, et takistada vahepealsel CA-l väljastamast täiesti kehtivaid sertifikaate kolmandate osapoolte domeenidele (nt google.com).

6. Brauser kontrollib poliitika piiranguid

Sertifikaadipoliitika on CA avaldatud juriidiline dokument, milles kirjeldatakse ametlikult protseduure, mida nad järgivad oma sertifikaatide väljastamiseks ja haldamiseks. Asutused võivad väljastada sertifikaadi ühe või mitme poliitika alusel ja lingid nendele on lisatud iga väljaantud sertifikaati, et lootvad osapooled saaksid neid põhimõtteid enne sertifikaadi usaldamise otsustamist hinnata.

Juriidilistel ja operatiivsetel põhjustel võivad sertifikaadid seada piiranguid nende poliitikate suhtes. Kui leitakse, et sertifikaat sisaldab kriitilisi poliitikapiiranguid, peavad brauserid need enne jätkamist valideerima. (Kuid kriitilisi poliitilisi piiranguid kohtab reaalses maailmas harva ja seetõttu eiratakse seda ülejäänud artiklis.)

7. Brauser kontrollib põhipiiranguid (ehk tee pikkust)

Vorming X.509 v3 võimaldab väljaandjatel määrata maksimaalse tee pikkuse, mida sertifikaat toetab. See võimaldab kontrollida, kui kaugele saab iga sertifikaadi sertifitseerimisteele panna. See on tegelikult oluline - brauserid eirasid sertifitseerimistee pikkust seni, kuni teadlane 2009. aastal demonstreeris esitlus, kuidas ta kasutas oma veebisaidi lehesertifikaati, et võltsida kehtiv sertifikaat suurele e-kaubanduse veebisaidile.

8. Brauser kontrollib võtmete kasutamist

Laiendus „võtme kasutamine” märgib sertifikaadis sisalduva võtme eesmärgi. Selliste eesmärkide hulka kuuluvad näiteks krüpteerimine, allkirjad, sertifikaatide allkirjastamine ja nii edasi. Brauserid lükkavad sertifikaadid tagasi, rikkudes nende võtmekasutuse piiranguid, näiteks serverisertifikaadi leidmine võtmega, mis on mõeldud ainult CRL-i allkirjastamiseks.

9. Brauser jätkab kõigi allesjäänud kriitiliste laienduste töötlemist

Pärast ülalnimetatud laienduste töötlemist jätkavad brauserid kõigi järgmiste laienduste valideerimist, mille praegune sertifikaat määrab kriitiliseks, enne kui jätkate järgmisega. Kui brauser jõuab tee lehesertifikaadini veata, aktsepteeritakse tee kehtivana. Vigade ilmnemisel märgitakse tee kehtetuks ja turvalist ühendust pole loodud.

Kaasaegne sertifikaatide haldus: lühem eluiga ja automatiseerimine

SSL /TLS tööstusharu on viimastel aastatel läbi teinud mitmeid muutusi, mis on põhjalikult muutnud sertifikaatide väljastamise ja haldamise viisi. Nende muutuste mõistmine on ülioluline PKI juhid, IT-spetsialistid ja/või kõik teised, kes töötavad digitaalsete sertifikaatidega.

Lühemad sertifikaatide kehtivusajad

2025. aasta aprillis kiitis CA/Browser Forum heaks ajaloolise otsuse (Hääletussedel SC-081v3) sertifikaatide kehtivusaegade dramaatiliseks lühendamiseks etappide kaupa:

• Praegune (kuni märtsini 2026)Maksimaalselt 398 päeva (umbes 13 kuud)
• Märtsil 15, 2026Maksimaalselt 200 päeva
• Märtsil 15, 2027Maksimaalselt 100 päeva
• Märtsil 15, 2029Maksimaalselt 47 päeva

Domeenikontrolli valideerimise (DCV) muudatused

Lisaks sertifikaatide eluea pikkusele lüheneb ka domeeni valideerimisteabe taaskasutamise periood:

• märtsil 2026Maksimaalne taaskasutusaeg 200 päeva
• märtsil 2027Maksimaalne taaskasutusaeg 100 päeva
• märtsil 2029Maksimaalne taaskasutusaeg 10 päeva

See tähendab, et organisatsioonid peavad domeeni omandiõigust palju sagedamini valideerima, mistõttu on automatiseerimine praktilise sertifikaatide haldamise jaoks hädavajalik.

Miks need muudatused on olulised

Turvalisuse eelised:

• Lühem sertifikaatide kehtivusaeg vähendab ohtu võtmete ohtu sattumisel
• Sagedasem valideerimine tagab domeeni omandiõiguse kehtivuse
• Turvalisuse täiustuste kiirem juurutamine kogu veebis

Operatiivne mõju:

• Sertifikaatide käsitsi haldamine muutub praktiliselt võimatuks
• Organisatsioonid peavad rakendama automatiseeritud sertifikaatide elutsükli haldust
• Vaja on sagedasemaid domeeni valideerimise protseduure

Automatiseerimise nõuded

Need muudatused muudavad sertifikaatide automatiseerimise mitte ainult kasulikuks, vaid ka hädavajalikuks. Organisatsioonid peaksid tõsiselt kaaluma järgmist:

• Täitma ACME (automaatne sertifikaatide haldamise keskkond) või sarnased protokollid
• juurutada sertifikaatide elutsükli halduslahendused
• Valmistage infrastruktuur ette sagedaseks uuendamiseks ja valideerimiseks
• Valmistuge üleminekuks lühemale sertifikaatide kehtivusajale

Sertifikaatide läbipaistvuse integreerimine

Tänapäeva brauserid nõuavad või valideerivad üha enam sertifikaatide läbipaistvuse (CT) logisid, mis pakuvad avalikke ja auditeeritavaid andmeid kõigi väljastatud sertifikaatide kohta. See aitab tuvastada:

• Valesti väljastatud sertifikaadid
• Volitamata sertifikaadi väljastamine
• CA vastavusprobleemid

Järeldus

Digitaalmaastik on endiselt keerukas omavahel ühendatud komponentide süsteem ning brauseri turvalisus on jätkuvalt aktiivne arendusvaldkond, mis hõlmab järgmist: 

• Lühem sertifikaatide eluigaTööstusharu liigub 47. aastaks 2029-päevaste sertifikaatide kehtivusaegade suunas, mistõttu on automatiseerimine praktilise sertifikaatide haldamise jaoks hädavajalik.
• Tühistamismeetodi muudatusedÜleminek OCSP-lt tagasi CRL-idele peegeldab valdkonna prioriteetsust kasutajate privaatsusele ja tegevuse efektiivsusele.
• Rangem CA järelevalveBrauserid on muutunud agressiivsemaks vastavuse tagamisel ja usalduse eemaldamisel ebapiisavalt toimivatelt sertifitseerimisasutustelt.

Need muudatused kujutavad endast põhimõttelist nihet automatiseeritud, privaatsust arvestava ja turvalisusele keskenduva sertifikaatide haldamise suunas. Organisatsioonid peaksid juba praegu hakkama valmistuma sertifikaatide lühemaks kehtivusajaks ja automatiseeritud uuendamisprotsessideks.

Usaldus mängib jätkuvalt olulist rolli kasutajate turvalisuse tagamisel veebis. Soovitame teil olla kursis nende arenevate standarditega ning vaadata üle oma sertifitseerimisasutuse poliitika ja vastavusaruanne. Nagu need muudatused näitavad, kohandub sertifitseerimisökosüsteem aktiivselt turvalisuse ja privaatsuse kaitse parandamiseks.

Sertifikaatide haldamise parimate tavade ja SSL.com-i lähenemisviisi kohta nendele valdkonna muudatustele leiate meie veebisaidilt sertifikaatide võrdlusleht.

Täname, et valisite SSL.com, kus usume a ohutum Internet on a parem Internet.