ROOT CAINT 1INT 2site 1site 2site 3site 4site 5site 6

Autoritats de certificació

11 lectura mínimaCriptografia

Quan el vostre navegador mostra un cadenat, assegura la identitat del servidor i, en última instància, aquest aval es basa en un petit conjunt d'organitzacions anomenades autoritats de certificació. Comprendre què fan realment les CA, com es guanyen la seva confiança i com aquesta confiança s'ha trencat i reconstruït al llarg dels anys explica molt per què la web moderna és com és.

El cos complet de l'article es proporciona en anglès a continuació.

A Certificate Authority (CA) és una organització que emet certificats digitals que uneixen les claus públiques a les identitats. El paper més conegut és l'emissió de certificats TLS: quan example.com presenta el seu certificat al vostre navegador, el vostre navegador verifica la signatura de l'AC i, si l'AC es troba al magatzem de confiança, la connexió continua. Tot l'aparell s'anomena Public Key Infrastructure (PKI).

El que conté un certificat

Un certificat X.509 és un document estructurat que conté:

  • Subjecte, per exemple, el certificat . *.example.com per a comodins)
  • Clau pública del subjecte
  • Issuer — la CA que l'ha signat
  • Període de validesa —actualment en dates d'inici i finalització de 25X37 dies navegadors
  • Número de sèrie
  • Extensions — Noms alternatius del subjecte (dominis addicionals), restriccions d'ús de claus, URL CRL/OCSP per a la comprovació de revocació a dalt

Com funciona la cadena de confiança

Els navegadors i sistemes operatius s'envien amb una llista de root CAs de confiança: uns 100 d'ells a Chrome, similars a Mozilla, Apple i Microsoft. Cada CA arrel té una clau pública, i el navegador confia en els certificats signats per aquesta clau arrel (directament o mitjançant CA intermèdies). Això protegeix l'arrel: la clau privada de l'arrel es manté fora de línia, s'utilitza només per signar intermedis; si un intermedi està compromès, l'arrel pot revocar-lo sense eliminar tot el CA.

El flux de verificació quan el vostre navegador es connecta a example.com:

  1. Server envia el seu certificat més qualsevol certificat intermedi.
  2. Browser comprova que el certificat està signat pel servidor. intermediate.
  3. Browser comprova que l'intermedi estigui signat per una arrel al magatzem de confiança.
  4. Browser comprova les dates, el nom de domini del certificat, l'ús de la clau i l'estat de revocació.
  5. I Si passen totes les comprovacions, la connexió continua. ownership

    Abans d'emetre un certificat per example.com, l'AC ha de verificar que el sol·licitant controla realment example.com. Tres nivells de validació:

    Quan les CA s'equivoquen

    El model de confiança es trenca si alguna CA de confiança emet un certificat per a un domini a la part equivocada. Incidents històrics:

    Certificate Transparence: la barana moderna

    Des del 2018, els navegadors requereixen que els certificats apareguin als registres públics de Certificate Transparency (CT) abans que s'acceptinXPLZ10. Tots els certificats emesos per qualsevol CA de confiança es registren públicament a les poques hores de l'emissió. Qualsevol persona pot controlar els certificats inesperats al seu domini mitjançant eines com crt.sh.

    Això restringeix dràsticament el comportament incorrecte de l'AC: es pot detectar un certificat emès incorrectament i la reputació de la CA emissora està en joc. El nombre d'incidents d'emissió fraudulenta ha baixat dràsticament des que el CT es va convertir en obligatori.

    Revocació: la part encara trencada

    Quan la clau privada d'un certificat està compromesa, el certificat s'ha de revocar. Existeixen dos mecanismes:

    Tots dos tenen problemes. Els CRL es van fer massa grans per obtenir-los de manera rutinària. L'OCSP pot tenir un error suau (si el servidor és lent, el navegador permet la connexió de totes maneres, cosa que un atacant explota bloquejant OCSP). Els navegadors moderns s'han traslladat a CRLite, CRLSets i baixades de revocació per lots similars. La revocació l'any 2026 és millor del que era, encara imperfecta.

    Qui gestiona les principals CA avui

Preguntes freqüents

Per què he de confiar en tantes CA?
Històric i operatiu. Les diferents CA donen servei a diferents regions, governs i segments de mercat; la poda trencaria camins de confiança. Els navegadors eliminen regularment les CA que es comporten malament. La llista està seleccionada per Mozilla, Apple, Microsoft i Google; cap d'ells vol confiar en CA innecessàries perquè cadascuna és una superfície d'atac potencial.
Puc executar la meva pròpia CA?
Per a ús intern, sí: moltes organitzacions executen CA privades i instal·len el seu certificat arrel en dispositius gestionats. Per al TLS públic, no, els navegadors no confiaran en la vostra arrel sense passar per anys de verificació del CA Browser Forum. Les CA públiques són una categoria limitada i regulada per una bona raó.
Què passa si una CA deixa de funcionar?
Els navegadors eliminen gradualment la CA dels magatzems de confiança mentre els certificats existents continuen validant-se fins que caduquen. Els titulars de certificats solen rotar a una altra CA abans del venciment. La desconfiança de Symantec es va desenvolupar durant 18 mesos amb fases coordinades pel navegador.
Les CA veuen la meva navegació?
El pas d'emissió és únic. Després d'això, el servidor presenta el certificat al vostre navegador, no cal cap CA d'anada i tornada (tret que es sol·liciti OCSP i el grapat modern encarrega aquesta responsabilitat al servidor). L'AC no veu el vostre trànsit diari.
Per què els certificats estan limitats a 397 dies ara?
Les vides de vida més curtes limiten els danys dels certificats compromesos i la disciplina de rotació forçada. El CA/Browser Forum ha reduït progressivament el màxim de 5 anys a 2 anys a 1 any (397 dies), amb propostes per reduir encara més (90 dies o fins i tot menys). L'automatització mitjançant ACME fa que les vides de vida siguin operatives més curtes.
Explicació de les autoritats de certificació: la infraestructura de confiança que fa que HTTPS funcioni