Sariling sertipiko ng Cloudflare at ang panganib ng iisang libreng CA

Ilang taon nang umaasa ang Cloudflare sa 16 na katuwang na pampublikong CA nang hindi kailanman naglalabas ng sarili nitong pinagkakatiwalaang sertipiko. Balak na nitong maging isa, at ang kawili-wili ay ang disenyo: klasikong sertipiko at Merkle Tree Certificates sa ilalim ng iisang CA, na may pagkontrol sa pinsala mula pa sa simula.

Ang gumagamit ng sertipiko ay nagiging tagapaglabas nito #

Karamihan sa mga kumpanya ng imprastraktura ay nananatili sa iisang panig ng ugnayan sa sertipiko. Humihingi sila ng sertipiko, ini-install ito, at nagrereklamo kapag may insidente ang isang CA. Matatag na nasa panig ng gumagamit ang Cloudflare. Ayon sa sarili nitong salaysay, hindi pa ito kailanman naglabas ng kahit isang pampublikong pinagkakatiwalaang sertipiko.

Malapit nang magbago iyon, o kahit paano iyon ang sinasabi ng Cloudflare na balak nito. Inaanunsyo ng kumpanya ang balak nitong maging pampublikong certificate authority. Maingat ang anunsyo tungkol sa kung nasaan na ang mga bagay ngayon, at ganoon din dapat ang artikulong ito. Hindi pa naglalabas ng sertipiko ang Cloudflare. Lahat ng tungkol sa pagkilos ng serbisyo, mula sa ACME interface nito hanggang sa mga patakaran sa renewal at sa suporta nito sa Merkle Tree Certificates, ay pahayag ng plano at hindi paglalarawan ng isang tumatakbong sistema.

Ang nagpapakapani-paniwala sa anunsyo ay hindi ambisyon kundi ang paghahandang nakikita na. Nag-apply ang Cloudflare para maisama sa mga root program ng Chrome, Apple, Microsoft at Mozilla. Sinasabi nitong dumadaan ito sa proseso ng aplikasyon at pag-apruba sa bawat isa sa mga pangunahing root key program ng web, at binabanggit nitong bukas sa publiko ang mga prosesong ito. Sa prinsipyo, kahit sino ay maaaring magbantay kung magtatagumpay ang aplikasyon.

Bakit nasa posisyon ang Cloudflare para itanong ito #

Nagsisimula ang katwiran ng Cloudflare para sa pagbuo ng CA sa posisyon nito bilang customer. Nakatayo ito sa harap ng mahigit 20 porsiyento ng pandaigdigang trapiko ng mga request sa Internet. Tinatapos nito ang TLS para sa milyun-milyong domain at umaasa sa milyun-milyong sertipiko bawat taon. Nagbibigay ito ng mga certificate pack sa pamamagitan ng Universal SSL para sa mga customer nito, at gumagamit din ito ng mga sertipiko mula sa maraming iba't ibang CA para patakbuhin ang sarili nitong mga sistema at panloob na operasyon.

Para manatiling gumagana ang mga serbisyo ng customer, kumukuha ang Cloudflare ng mga sertipikong iyon mula sa maraming CA, na may pangunahin at reserbang daan para manatiling gumagana ang mga serbisyo sa kabila ng mga outage ng CA at mga revocation. Umaabot sa 16 ang network ng mga katuwang na pampublikong CA na inaasahan nito sa loob ng maraming taon.

Nararapat tingnang mabuti ang mekanismong reserba dahil ipinapakita nito kung paano nag-iisip ang Cloudflare tungkol sa pagkabigo. Bawat sertipiko ng Universal SSL ay may kasama nang reserbang sertipiko, na nakabalot sa hiwalay na susi at inilabas ng ibang awtoridad. Kung ma-revoke o makompromiso man ang pangunahin, handa nang awtomatikong i-deploy ang reserba. Iyon ay proteksyon laban sa pagkakamali ng alinmang CA, na binuo mula sa panig ng customer sa ugnayan.

May hangganan din ang proteksyong iyon. Makakapag-diversify ka lamang sa mga CA na umiiral, at iginigiit ng pinagmulan na mas manipis ang suplay ng mga may kakayahang CA kaysa sa inaakala.

Ang problema ng konsentrasyon #

Kapansin-pansin ang mga numero sa likod ng argumentong iyon. Naglalabas ang Let's Encrypt ng humigit-kumulang sampung milyong sertipiko bawat araw. Naglilingkod ito sa mahigit 500 milyong site at lumampas sa apat na bilyong aktibong sertipiko noong 2025. Mga numero iyan para sa iisang libreng CA, at inilalarawan nito ang isang web na ang encryption ay lubhang nakasandal sa iisang organisasyon.

Hinango ng pinagmulan ang malinaw na konklusyon, na may angkop na pag-iingat: kung magkaroon ng masamang linggo ang nangingibabaw na libreng certificate authority, walang maihahambing na libre at awtomatikong alternatibo na handang sumalo sa bigat para sa malaking bahagi ng web. Pahayag ito tungkol sa isang haka-haka, at ganoon ito inihaharap ng Cloudflare. Hindi nito sinasabing nangyari na ang ganoong linggo, o na may darating.

Gayunpaman, madaling sundan ang lohika. Ang isang libre at awtomatikong CA ay opsyon lamang para sa katatagan kung umiiral na ito bago ang emerhensiya. Ang alok ng Cloudflare ay kaya nitong magbigay ng pangalawa sa malaking saklaw. Sa tingin ko, iyon ang pinakamatibay na komersiyal at teknikal na dahilan sa anunsyo, at hindi ito nakasalalay sa alinman sa mas haka-hakang bahagi ng plano. Ang web na may iisang nangingibabaw na libreng CA at kaunti pang iba ay web na may iisang punto ng pagkabigo, gaano man kahusay ang operasyon ng CA na iyon.

Dimensyon	Tradisyonal na libre at awtomatikong CA (Let's Encrypt)	Iminumungkahing pampublikong CA ng Cloudflare
Estratehiya ng trust anchor	ISRG Root X1 / X2 (sariling mga root mula 2015 pataas)	Biniling root ng GlobalSign (pinagkakatiwalaan mula 2012) + bagong root
Protocol ng paglalabas	Karaniwang ACME (RFC 8555)	ACME na may sapilitang pagpapatupad ng ARI (RFC 9773)
Paradigma ng revocation	CRL / OCSP + emerhensiyang maramihang pagpapalit ng subscriber	Pinag-ugnay na pagpapaaga ng renewal sa pamamagitan ng mga ARI endpoint
Daan sa post-quantum	Sinusuri pa ang hybrid na X.509 signature	Katutubong Merkle Tree Certificates (MTC) kasabay ng klasikong X.509
Saklaw at unang workload	~10M sertipiko/araw sa mahigit 500M site	Pagpapatunay bilang Customer Zero sa mahigit 20% ng pandaigdigang trapiko sa web

Pagbili ng root sa halip na maghintay ng bago #

Ang pinakapraktikal na desisyon sa anunsyo ay tungkol sa root. Sinasabi ng Cloudflare na pumirma ito ng tiyak na kasunduan para bilhin ang isang matatag at malawak na pinagkakatiwalaang root mula sa GlobalSign. Tuwirang ibinibigay ng pinagmulan ang dahilan: ilang taon bago maging malawak na kapaki-pakinabang ang isang bagong root. Sa kabilang banda, pinagkakatiwalaan na ang umiiral na root ng GlobalSign sa mga browser, operating system at device mula pa noong 2012.

Mabagal ang tiwala sa root dahil naka-install ito sa mga device, at mabagal mag-update ang mga device. Maaaring tanggapin ng bawat program ang isang bagong root pero mabigo pa ring ma-validate ito sa isang lumang telepono o embedded system. Ang pagbili ng root na nasa larangan na mula 2012 ay umiiwas sa paghihintay na iyon, kahit man lang sa paraan ng paglalahad ng pinagmulan.

Hindi tuluyang tinatalikuran ng Cloudflare ang daan ng bagong root. Magsusumite rin ito ng bagong root para maisama sa mga root key program, na inilalarawan nitong binuo para sa direksyon ng ekosistema, kabilang ang mga program na nagsisimulang maglagay ng limitasyon sa edad ng isang pinagkakatiwalaang root. Kapaki-pakinabang na paalala ang huling detalyeng iyon na may dalawang mukha ang edad. Asset ang edad ng isang pinagkakatiwalaang root para sa saklaw ng device, at may mga program na papalapit sa mga limitasyon sa edad ng pinagkakatiwalaang root. Ang pagpapatakbo ng biniling root at ng bagong isinumite ay mukhang tugon sa tensyong iyon, bagaman hindi tahasang ipinapaliwanag ng pinagmulan ang katwiran sa ganitong mga salita.

Serbisyong ACME muna, na may mga kondisyon #

Sa adopsyon kadalasang nagiging malabo ang maraming anunsyo ng CA. Tiyak ang Cloudflare. Magiging ACME-first ang pampublikong CA nito, ibig sabihin ay gagamitin nito ang Automated Certificate Management Environment protocol na ginagamit na ng umiiral na automation. Ang pahayag ay sinumang nakaturo na sa isang umiiral na libreng CA ay makakalipat sa CA ng Cloudflare sa pagpapalit ng isang directory URL, nang walang bagong tooling at walang kailangang baguhin sa arkitektura. Plano iyon, hindi nasubok na daan ng paglipat, at dapat itong basahin nang ganoon. Pero tamang target ang isang linyang pagbabago sa configuration, dahil ang gastos sa paglipat ang nagpapanatili sa mga tao sa default.

Ang kapalit ay isang kahingian na hindi pa kinailangang tuparin ng karamihan sa mga gumagamit ng ACME. Maglalabas lamang ang Cloudflare sa mga client na sumusuporta sa ACME Renewal Information, o ARI, na na-standardise sa RFC 9773. Kailangang panatilihin ng mga subscriber ang automation na nagtatanong sa renewal endpoint ng Cloudflare, kumikilos ayon sa mga renewal window na inilalathala ng Cloudflare, at tumutukoy sa sertipikong pinapalitan nito.

Matatag na posisyon ito, at sa tingin ko ito ang tama. Nagtataas din ito ng makatwirang tanong tungkol sa adopsyon: mas makitid ang isang CA na naglilingkod lamang sa mga client na may kakayahang ARI kaysa sa CA na naglilingkod sa sinumang may ACME library. Hindi sinasabi ng pinagmulan kung ilang client ang hindi kasama ngayon, kaya hindi ako manghuhula. Ang sinasabi nito ay kung bakit gusto ng Cloudflare ang limitasyong ito.

Revocation nang hindi sinisira ang mga site #

Sinasabi ng Cloudflare na may mga napansin ito sa nakalipas na 16 na taon, at may isang obserbasyong nagtutulak sa disenyong ito. Nakita nito ang mga certificate authority na naiipit sa pagitan ng napapanahong revocation at ng pagpapanatiling bukas ng mga site ng kanilang mga subscriber.

Totoo ang tensyong iyon para sa anumang CA. Pinoprotektahan ng mabilis na revocation ng sertipiko ang publiko, pero maaari nitong pabagsakin ang bawat site na umaasa sa sertipikong iyon kung hindi ito mapalitan agad ng subscriber. Ang CA na naiipit sa gitna ay alinman sa mahuhuli sa revocation o makasisira sa mga customer.

Ang ARI ang sagot ng Cloudflare. Kapag kailangang iretiro ang mga sertipiko, sinasabi ng Cloudflare na kaya nitong paagahin ang mga renewal window para sa mga apektadong sertipiko. Dahil kinakailangan ng mga subscriber na magtanong sa renewal endpoint at kumilos ayon sa mga window na inilalathala nito, kayang gabayan ng CA ang mga ito patungo sa pagpapalit bago dumating ang isang matigas na revocation. Inilalarawan ang mekanismong ito bilang kakayahang balak magkaroon ng Cloudflare, hindi bilang naipakita na nito bilang CA. Gayunpaman, magkakaugnay ang lohika: umiiral ang kahingian sa pagtatanong para gumana ang panggatilyong ito.

Makikita rin ang parehong pag-iisip sa mas malawak na layunin ng disenyo. Balak ng Cloudflare na bumuo ng certificate authority na ang pagiging maaasahan ay nakasalalay hindi lamang sa pag-iwas sa mga pagkakamali kundi, gaya ng iba pang produkto ng Cloudflare, sa pagkabigo nang maliit at paglilimita sa epekto ng alinmang isyu. Kailangan ng isang CA na umiwas sa mga pagkakamali, at walang CA na makapangangakong gagawin iyon nang perpekto. Ang pagdidisenyo para manatiling nakapaloob ang isang pagkakamali ang mas tapat na paninindigan sa engineering.

Transparency na lampas sa audit #

Karaniwang hinuhusgahan ang mga pampublikong CA sa pamamagitan ng mga audit. Tahasan ang pinagmulan tungkol sa kanilang hangganan: point-in-time ang mga audit at sinasabi lamang nito na pumasa ang isang CA. Hindi nito sinasabi kung ano ang ginagawa ng CA sa isang karaniwang Martes pagkatapos.

Ang tugon ng Cloudflare ay sabihing maglalathala ito ng mga reproducible build ng software na pumipirma sa mga sertipiko. Inihaharap iyon bilang pangako, hindi bilang tapos nang produkto. Pinahihintulutan ng mga reproducible build ang mga tagalabas na tiyaking tumutugma sa inilathalang source ang binary na tumatakbo sa daan ng pagpirma, na isang tuloy-tuloy na katangian sa paraang hindi kayang gawin ng ulat ng audit. Kung sapat ba iyon ay nakasalalay sa kung ano talaga ang ilalathala ng Cloudflare, at kung may ibang susuri dito.

Ang ikalawang kalahati ng anunsyo: Merkle Tree Certificates #

Sa materyal tungkol sa post-quantum pinakamalayo ang tanaw ng anunsyo. Inaanunsyo ng Cloudflare ang planong maging isa sa mga unang CA na maglilingkod ng mga post-quantum na sertipiko, at plano nitong ilabas ang mga unang Merkle Tree Certificates nito sa unang quarter ng 2027. Sa ibang bahagi ng pinagmulan, sinasabing inaasahan ang mga unang MTC sa simula ng 2027. Parehong plano ang mga ito.

Inilalarawan ng pinagmulan ang mga MTC bilang bago at mas siksik na paraan ng paghahatid ng mga pampublikong pinagkakatiwalaang sertipiko. Paglalarawan ang salitang iyon, at hindi nagbibigay ang pinagmulan ng mga sukat sa mga bahaging pinagbabatayan ko, kaya hindi ko masasabi kung gaano kasiksik. Sinasabi ng Cloudflare na matagal na nitong itinataguyod sa IETF ang panukalang batay sa mga pamantayan para sa mga MTC. Iniuulat din nito na pinangalanan ng Chrome ang mga MTC bilang ginustong daan para sa post-quantum na authentication sa unang bahagi ng taong ito. Iyon ay naipakitang pangyayari, at mahalaga ito, dahil ang ipinahayag na kagustuhan ng isang browser vendor ang nagpapabago sa isang panukala tungo sa isang bagay na mapagpaplanuhan ng isang CA.

Hindi inaasahan ng Cloudflare na biglaan ang paglipat. Inaasahan nitong patuloy na aasa ang malaking bahagi ng Internet sa mga klasikong sertipiko at sa umiiral na WebPKI sa loob pa ng maraming taon. Sa panahong iyon, inaasahan nitong unti-unting lalaki ang bahagi ng mga MTC sa paglalabas. Mga inaasahan ang mga iyon, at ganoon ang tawag dito ng pinagmulan.

Iisang CA, iisang lifecycle #

Ang pagpiling pang-arkitektura na sumusunod dito ang pinakanakakukumbinsi sa akin. Idinisenyo ang bagong CA para dalhin ang mga klasikong sertipiko at Merkle Tree Certificates sa ilalim ng iisang CA, na may iisang lifecycle at iisang hanay ng garantiya. Kaya ng mga customer na mag-adopt sa bilis na angkop sa kanila at tulungan ang web na tumawid nang walang matigas na cutover.

Ang alternatibo ay dalawang magkahiwalay na CA, dalawang hanay ng proseso, at sapilitang paglipat sa isang punto. Ang matigas na cutover ang pinakamapanganib na paraan para baguhin ang isang ekosistema ng sertipiko, at ang ipinahayag na layunin ng pinagmulan ay iwasan ito. Maingat ang pananalita, at tama lamang: layunin ito ng disenyo para sa isang CA na hindi pa naglalabas.

Akma rin ito sa larawan ng mga insentibo. Sinasabi ng Cloudflare na inaasahan nitong patuloy na lalaki ang bilang ng mga sertipikong inaasahan nito taun-taon habang umiikli ang pinakamahabang panahon ng bisa, dumarami ang agentic na aktibidad at nagiging pangkaraniwan ang mga post-quantum na sertipiko. Mas maraming sertipiko, na mas madalas inilalabas, ay nangangailangan ng automation at ng CA na itinuturing ang renewal bilang pangunahing operasyon. Makatwirang tugon sa inaasahang iyon ang isang sistemang nakabatay sa ARI at iisang lifecycle, bagaman ang inaasahan mismo ay hula at hindi sukat.

Customer Zero #

Paano mo susubukan ang isang CA bago umasa rito ang publiko? Ang sagot ng Cloudflare ay maging sarili nitong unang customer. Ito ang magiging Customer Zero para sa bagong CA at sa mga sertipiko nito, WebPKI man o MTC. Ang ipinahayag na layunin ay tiyaking natutugunan ng lahat ng aspeto ng mga bagong sistema at proseso ang mataas na panloob na pamantayan ng Cloudflare, at na nasusubok ang imprastraktura ng CA sa saklaw ng Cloudflare.

Dahil sa mga naunang numero, mabigat na panloob na karga iyon: milyun-milyong sertipiko bawat taon, sa isang kumpanyang nakatayo sa harap ng mahigit 20 porsiyento ng pandaigdigang trapiko ng mga request. Hindi masasabi ng mga pahayag kung magiging maayos ang mga unang taon ng operasyon. Ang ipinapakita nila ay isang makatwirang pagkakasunod-sunod. Nagsisimula ang kumpanya bilang mabigat na gumagamit ng binubuo nito, na may kasaysayan ng pagkuha mula sa maraming CA, mga reserbang daan, at 16 na katuwang na CA sa likod nito.

Mabuting maging tapat tungkol sa kung ano ang kulang. Walang iniuulat ang pinagmulan na dami ng paglalabas, antas ng pagkakamali, latency ng validation o kasaysayan ng insidente para sa sariling CA ng Cloudflare, dahil wala pang ganoong kasaysayan. Ang anunsyo ay pahayag ng layunin na sinusuportahan ng mga aplikasyon, isang kasunduan sa pagbili at isang disenyo. Hindi ito isang track record.

Ano ang dapat bantayan #

Tatlong bagay ang magpapasya kung ito ay makabuluhang dagdag sa WebPKI o isa lamang kawili-wiling anunsyo.

Ang una ay ang mga root program. Nag-apply ang Cloudflare sa Chrome, Apple, Microsoft at Mozilla, at bukas sa publiko ang mga proseso. Ang pagbabantay sa mga ito ang pinakatuwirang paraan para makita kung gaano na kalayo ang narating ng plano, at ang kalalabasan ay hindi isang bagay na hinahayaan akong hulaan ng alinman sa mga pahayag.

Ang ikalawa ay ang kahingian sa ARI. Ang CA na nagpupumilit sa suporta sa RFC 9773 ay tumataya na kayang isulong ang automation ng renewal sa buong base ng mga subscriber nito. Kung tama ang taya, mabibigyan nito ang Cloudflare ng kakayahang paagahin ang mga renewal window kapag kailangang iretiro ang mga sertipiko, na siyang ipinahayag na sagot sa dilema ng revocation na nakita nito. Kung mali, mas mabagal ang adopsyon kaysa sa ipinahihiwatig ng kuwento ng isang linyang paglipat.

Ang ikatlo ay ang unang quarter ng 2027. Doon pinaplano ng Cloudflare ang mga unang Merkle Tree Certificates nito. Ang bukas na tanong ay kung gaano kabilis talagang lalaki ang unti-unting lumalaking bahaging inaasahan nito, dahil sa sarili nitong pananaw na mananatili sa mga klasikong sertipiko ang malaking bahagi ng Internet sa loob pa ng maraming taon. Sinabi ng kumpanya na hindi dapat mangailangan ng matigas na cutover ang pagtawid. Ang unang quarter ng 2027 ang unang pagkakataon para makita kung kayang gawing totoo iyon ng iisang CA na may dalang dalawang uri ng sertipiko.

Ano ang kahulugan nito sa bawat sektor #

Ang paglitaw ng isang pampublikong certificate authority na mataas ang dami at awtomatiko, mula sa isang tagapagbigay ng edge na imprastraktura, ay nagbabago sa panganib sa operasyon at sa pagpaplano ng PKI sa ilang teknikal na larangan.

Cloud na imprastraktura at mga edge network #

Ang pagpapatakbo ng pampublikong CA sa saklaw ng edge ay nagbabawas sa panlabas na pag-asa sa mga third-party na verification API at CRL. Sa pagsasama ng pagtatapos sa edge ng reverse proxy at ng awtomatikong ACME ARI renewal, kayang protektahan ng mga tagapagbigay ng imprastraktura ang kanilang mga customer laban sa mga outage ng mga certificate authority sa itaas ng daloy.

Enterprise PKI at mga pangkat ng DevOps #

Ang mga organisasyong umaasa sa Let's Encrypt para sa mga pampublikong endpoint ay nagkakaroon ng kapani-paniwala at awtomatikong alternatibo. Gayunpaman, dahil sapilitang ipinatutupad ang RFC 9773 (ARI), kailangang i-audit ng mga pangkat ang kanilang mga ACME client (Certbot, Lego, Caddy, Traefik) para matiyak na aktibo ang suporta sa ARI bago magpalit ng directory endpoint.

Mga browser vendor at pamamahala ng root #

Humaharap ang mga root program (Chrome, Mozilla, Apple, Microsoft) sa lumalawak na ekosistema ng mga awtomatikong CA na mataas ang dami. Ang dalawahang diskarte sa root (pagbili ng lumang root mula 2012 habang nagsusumite ng modernong root) ay nag-aangkop sa mga patakaran ng browser na lalong naglilimita sa haba ng buhay ng mga root certificate, habang pinananatili ang pagkakatugma sa mga lumang device.

Konklusyon #

Ang hakbang ng Cloudflare na maging pampublikong certificate authority ay tumutugon sa isang tunay na estruktural na kahinaan ng makabagong WebPKI: ang matinding konsentrasyon sa libre at awtomatikong paglalabas ng sertipiko. Sa pagsasama ng isang matatag na root ng GlobalSign, mahigpit na automation ng renewal sa ARI, at tulay pasulong sa post-quantum na Merkle Tree Certificates, tinutugunan ng disenyo ang katatagan ng operasyon at hindi lamang ang pagbibigay ng sertipiko. Ang tagumpay ay matutukoy ng mga pag-apruba ng root program at kung gaano kabilis mag-adopt ng mga pamantayan ng ARI ang mga client tool bago ang paglulunsad sa 2027.

Mga Madalas Itanong #

Maaari ko na bang ilipat ngayon ang aking ACME client sa CA ng Cloudflare?

Hindi pa. Inanunsyo ng Cloudflare ang layunin nito, pumirma sa kasunduan sa pagbili ng root, at nagsumite ng mga aplikasyon sa mga pangunahing root program. Nakatakda ang pampublikong paglalabas pagkatapos ng mga pag-apruba ng root program.

Ano ang ACME Renewal Information (ARI) at bakit ito mahalaga?

Ang ARI (RFC 9773) ay extension ng ACME protocol na nagpapahintulot sa mga certificate authority na payuhan ang mga subscriber kung kailan dapat i-renew ang isang sertipiko. Dahil dito, maayos na maiuugnay ng mga CA ang maagang renewal bago ang nakaplanong revocation, at maiiwasan ang pagbagsak ng mga site.

Paano naiiba ang Merkle Tree Certificates (MTC) sa karaniwang X.509 na sertipiko?

Pinapalitan ng mga MTC ang tradisyonal na indibidwal na cryptographic signature ng mga Merkle inclusion proof na nakaangkla sa isang log na mapapatunayan ng publiko. Malaki ang nababawas nito sa laki ng sertipiko at sa bigat ng pagpapadala, kaya ginugustong kandidato ang mga ito para sa post-quantum na TLS authentication.

Mga Sanggunian #

Cloudflare, (2026). Pagbuo ng Certificate Authority para sa Buong Internet ⧉. Cloudflare Blog.
IETF, (2024). RFC 9773: Automated Certificate Management Environment (ACME) Renewal Information (ARI) ⧉. IETF.
IETF, (2025). Merkle Tree Certificates para sa TLS ⧉. IETF.
Chrome Root Program, (2026). Patakaran at mga konsiderasyon sa post-quantum na authentication ⧉. Chromium Projects.

Huling sinuri 2026-09-20.

Huling sinuri 2026-10-27.

Muling i-publish ang artikulong ito

Sariling sertipiko ng Cloudflare at ang panganib ng iisang libreng CA — Sebastien Rousseau

Balak ng Cloudflare na maging pampublikong certificate authority. Nag-apply ito sa root program ng Chrome, Apple, Microsoft at Mozilla at bibili ng root ng GlobalSign.

Ang artikulong ito ay nakapailalim sa lisensya ng Creative Commons Attribution 4.0 International. Kailangan ng pagkilala sa canonical URL para sa muling pag-publish.

Sariling sertipiko ng Cloudflare at ang panganib ng iisang libreng CA — Sebastien Rousseau

Balak ng Cloudflare na maging pampublikong certificate authority. Nag-apply ito sa root program ng Chrome, Apple, Microsoft at Mozilla at bibili ng root ng GlobalSign.

Originally published at https://sebastienrousseau.com/fil/2026-09-20-sariling-sertipiko-cloudflare-panganib-iisang-libreng/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER