Ja tens les quatre primitives: xifratge simètric, xifratge asimètric, hash amb MAC, i signatura digital. La lliçó anterior va tancar anunciant una cosa incòmoda, i aquesta la desenvolupa: combinar primitives correctes no garanteix un sistema segur. L'assemblatge —l'ordre dels missatges, què s'autentica, què es negocia, què passa quan alguna cosa falla— té els seus propis modes de fallada, i la història de la criptografia aplicada és plena de protocols fets amb AES impecable i RSA impecable que es van trencar per com estaven muntats. Aquesta lliçó estudia el TLS que fa vuit lliçons que dones per suposat —complint la promesa del mòdul 2—, amb la seva encaixada pas a pas, com verificar-lo i com configurar-lo; i hi afegeix SSH, VPN, mTLS, el correu xifrat i els atacs clàssics contra protocols: downgrade, stripping, MITM i repetició.

1. Què és un protocol criptogràfic i per què pot fallar
2. TLS: què protegeix i què no
3. De SSL a TLS 1.3: què millora cada versió
4. L'encaixada de TLS 1.3 pas a pas
5. Suites de xifratge: com es llegeixen
6. Verificar TLS des de la línia d'ordres
7. Configuració segura del servidor de Nimbus
8. mTLS: TLS mutu i quan té sentit
9. Altres protocols: SSH, VPN, correu i xifratge extrem a extrem
10. Atacs contra protocols i les seves defenses
11. Errors d'implementació amb impacte real

Un protocol criptogràfic és una seqüència acordada de missatges entre dues o més parts que, fent servir primitives criptogràfiques, aconsegueix un objectiu de seguretat concret: establir un canal confidencial, autenticar algú, acordar una clau, provar una possessió.

La diferència amb una primitiva és la mateixa que hi ha entre un maó i un edifici. Un maó s'assaja al laboratori i aguanta; un edifici cau pel disseny, no pel maó. Els modes de fallada típics d'un protocol són aquests, i cap no implica trencar l'àlgebra:

D'aquí la regla de l'apartat, coherent amb tot el mòdul: els protocols tampoc no es dissenyen ni s'implementen a mà. Es fan servir protocols estàndard, amb implementacions madures, actualitzades i ben configurades. La teva feina professional és triar la versió correcta, configurar-la bé i verificar que efectivament fa el que creus.

TLS (Transport Layer Security) és el protocol que converteix HTTP en HTTPS, i també protegeix SMTP, IMAP, connexions a bases de dades i pràcticament qualsevol cosa que viatgi per una xarxa avui. És l'exemple perfecte de xifratge híbrid (03-03) portat a producció.

Dues conseqüències pràctiques que convé dir en veu alta:

• «Va per HTTPS» no significa «és segur». L'IDOR de 01-01, la injecció SQL de 02-02 i la fuita del bucket de 02-06 passarien igual sobre TLS impecable. TLS protegeix el tram, no l'aplicació.
• El cadenat del navegador no acredita honestedat. Acredita que parles amb el domini que hi ha a la barra. Un web de phishing amb domini nimbus-reservas-clientes.example tindrà el seu cadenat perfecte (02-03).

Què millora TLS 1.3, que és el que cal saber explicar:

1. Menys voltes. L'encaixada es completa en 1-RTT (una anada i tornada) davant de les dues de TLS 1.2. Es nota en latència, especialment des del mòbil.
2. Suites reduïdes i sense peces trencades. Es van eliminar de l'estàndard RC4, 3DES, MD5, SHA-1, la compressió, la renegociació i els modes CBC amb MAC-then-encrypt. Només queden suites AEAD (03-02).
3. Forward secrecy obligatòria. Desapareix l'intercanvi de clau per RSA estàtic: tot és ECDHE (03-03). Ja no ho pots configurar malament, perquè l'opció dolenta no existeix.
4. Més part de l'encaixada va xifrada, inclòs el certificat del servidor, cosa que redueix el que un observador aprèn.
5. Menys marge per a errors de configuració. És la millora més subestimada: TLS 1.3 és segur per defecte, mentre que TLS 1.2 exigeix que l'administrador encerti amb la llista de suites.

Hi ha un matís que convé conèixer: TLS 1.3 permet represa en 0-RTT, que envia dades al primer missatge. És ràpid, però aquestes dades són susceptibles de repetició, així que només s'ha de fer servir per a peticions idempotents. Per a l'API de Nimbus, la recomanació és no habilitar 0-RTT.

Els cinc moments, amb el que aporta cadascun:

1. ClientHello. El client proposa versions i suites i —clau per al 1-RTT— ja envia la seva clau pública efímera, avançant l'intercanvi ECDHE. Inclou el SNI, el nom del servidor al qual es vol connectar, necessari perquè una mateixa IP allotja molts dominis.
2. ServerHello. El servidor tria la suite i envia la seva clau pública efímera. Amb les dues meitats, tots dos calculen el mateix secret compartit (03-03) i en deriven les claus de sessió mitjançant HKDF (03-02). Aquí entra ECDHE i aquí neix la forward secrecy.
3. A partir d'aquest punt tot va xifrat, inclòs el certificat.
4. Certificat i CertificateVerify. El servidor envia el seu certificat i la seva cadena, i signa amb la seva clau privada un resum de tota l'encaixada. Això és el que autentica l'intercanvi i tanca la porta al MITM de 03-03: l'atacant pot fer el seu propi ECDHE, però no pot produir aquella signatura sense la clau privada corresponent al certificat. El client valida la cadena fins a una arrel de confiança, el nom del domini, la vigència i la signatura —el que s'emet i com es valida és matèria de 03-06—.
5. Finished en tots dos sentits. Cada extrem demostra que ha vist exactament els mateixos missatges. Això és el que detecta un downgrade: si un atacant hagués alterat el ClientHello per forçar una suite feble, el resum no quadraria.

A partir d'aquí, el trànsit es xifra amb AES-GCM o ChaCha20-Poly1305 i claus simètriques. És exactament el patró híbrid de 03-03: l'asimètric només per acordar i autenticar, el simètric per a les dades.

Una suite de xifratge és la combinació concreta d'algorismes que es fa servir en una sessió. En TLS 1.2 el nom inclou quatre peces:

En TLS 1.3 els noms són molt més curts, perquè l'intercanvi i l'autenticació ja no es negocien a la suite:

Com avaluar una suite d'un cop d'ull: si l'intercanvi no comença per ECDHE (o DHE), no hi ha forward secrecy; si el xifratge és CBC, RC4 o 3DES, queda fora; si el hash és MD5 o SHA (per SHA-1), queda fora. Les tres suites de TLS 1.3 són totes correctes, que és precisament l'avantatge d'aquella versió.

Saber llegir l'estat real d'un servidor és una habilitat operativa bàsica. La Lucía comprova l'API de Nimbus:

Sortida comentada de la primera ordre:

Com es llegeix aquesta sortida, que és l'important:

• depth=2, depth=1, depth=0 són els tres graons de la cadena: arrel, intermèdia i certificat del servidor. verify return:1 a cadascun significa que aquell graó va validar.
• Certificate chain mostra, per a cada certificat, el seu subjecte (s:) i el seu emissor (i:). Fixa't en l'encadenament: l'emissor d'un és el subjecte del següent. La jerarquia completa és matèria de 03-06.
• New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 és la línia que resumeix el resultat: versió negociada i suite. Si aquí aparegués TLSv1.0 o una suite amb CBC, hi hauria troballa.
• Server public key is 256 bit indica una clau ECC de 256 bits (equivalent a RSA-3072, taula de 03-03). Si digués 2048, seria RSA.
• Verify return code: 0 (ok) és la validació completa. Qualsevol altre valor —10 caducat, 18 autosignat, 19 arrel no fiable, 21 no s'ha pogut verificar— és un problema.
• Les opcions: -servername envia el SNI, imprescindible quan la IP allotja diversos dominis; sense ell pots estar veient un certificat que no és el teu. </dev/null tanca l'entrada perquè l'ordre no es quedi esperant.

I la comprovació d'HSTS, que es fa sobre les capçaleres HTTP:

Fragment de configuració de Nginx per al frontal de Nimbus, explicat directiva a directiva:

Què fa cada bloc:

1. ssl_protocols TLSv1.2 TLSv1.3. Deshabilita SSL i TLS 1.0/1.1. Si tota la teva base de clients és moderna, deixar només TLSv1.3 encara és millor; mesura-ho abans amb els registres d'accés.
2. ssl_ciphers. Només suites ECDHE (forward secrecy) amb AEAD. ssl_prefer_server_ciphers off és el recomanat avui: es deixa triar al client dins de la llista permesa, perquè un mòbil sense acceleració AES triarà ChaCha20 i anirà més ràpid amb la mateixa seguretat.
3. ssl_ecdh_curve X25519:prime256v1. Prioritza X25519 (03-03), més ràpida i més difícil d'implementar malament.
4. Represa. La memòria cau accelera reconnexions. ssl_session_tickets off evita el risc que una clau de tiquets mal rotada anul·li la forward secrecy; ssl_early_data off desactiva 0-RTT pel risc de repetició.
5. Grapat OCSP. El servidor adjunta a l'encaixada una prova recent que el seu certificat no està revocat, en lloc d'obligar el client a consultar-la. Millora privacitat i latència; el mecanisme de revocació s'estudia a 03-06.
6. HSTS. max-age=63072000 (dos anys) indica al navegador que només faci servir HTTPS per a aquest domini; includeSubDomains ho estén a tots els subdominis i preload permet incloure'l a la llista precarregada dels navegadors. És la defensa contra l'stripping de l'apartat 10. Compte: includeSubDomains i preload són difícils de revertir; verifica abans que tots els subdominis serveixen HTTPS.
7. Redirecció 301 d'HTTP a HTTPS. Necessària, però no suficient: la primera petició continua viatjant en clar. Per això cal HSTS.

Verifica sempre el resultat amb un analitzador extern de configuració TLS i amb les ordres de l'apartat 6: la configuració escrita i l'efectiva no sempre coincideixen, sobretot amb balancejadors o CDN al davant.

En TLS normal només s'autentica el servidor; el client s'identifica després, dins del canal, amb una contrasenya o un token. En mTLS (mutual TLS), tots dos extrems presenten certificat i tots dos s'autentiquen durant la mateixa encaixada.

El que aporta: l'autenticació passa abans que l'aplicació processi res, així que un atacant sense certificat vàlid ni tan sols arriba a la lògica de negoci. El que costa: cal emetre, distribuir, renovar i revocar un certificat per client, cosa que exigeix una PKI interna —l'assumpte de 03-06—. La regla pràctica: mTLS entre pocs sistemes d'alt valor, tokens per a molts usuaris.

SSH mereix un detall, perquè el seu model de confiança és diferent del de TLS: no hi ha autoritats de certificació, sinó una empremta del host que el client memoritza la primera vegada (trust on first use).

L'essencial: quan SSH avisa que la clau del host ha canviat o és desconeguda, acceptar-ho a cegues equival a acceptar un possible MITM. L'empremta s'ha de comparar amb l'obtinguda per un altre canal. I per a un parc com el de Nimbus, la solució que escala és signar les claus de host amb una CA d'SSH, cosa que substitueix la memorització per una confiança jeràrquica (03-06). A més: autenticació només per clau —PasswordAuthentication no—, clau protegida amb frase de pas i root sense accés directe; l'enduriment complet del servidor és de 05-06.

Sobre les VPN, aquí només interessa què garanteixen: un túnel xifrat i autenticat entre dos punts. No donen control d'accés a les aplicacions ni converteixen en fiable el que hi ha a dins. El desplegament de xarxa es tracta a 05-04.

I el xifratge extrem a extrem com a concepte: les dades es xifren al dispositiu de l'emissor i només es desxifren al del destinatari, de manera que ni el proveïdor del servei no les pot llegir. És la diferència amb TLS, on el servidor sí que veu el contingut. Per a Nimbus, un E2EE complet seria incompatible amb la seva funció —l'aplicació necessita processar les cites—, però el concepte reapareix a 03-07 en parlar del xifratge a nivell de camp.

Dos mereixen desenvolupament:

L'stripping és l'atac més rendible contra un usuari en una wifi pública, i no trenca TLS: l'esquiva. La víctima escriu nimbusreservas.example sense https://, el navegador prova HTTP, i l'atacant intercepta aquella petició inicial i actua de proxy en clar cap a l'usuari mentre parla en HTTPS amb el servidor real. HSTS ho talla perquè el navegador, després de la primera visita legítima, es nega a fer servir HTTP per a aquell domini. I preload tanca també aquella primera visita, en venir la regla de fàbrica al navegador.

El pinning consisteix que el client exigeixi no només un certificat vàlid, sinó un de concret (o una CA concreta). Serveix contra l'escenari d'una CA que emet un certificat indegut per al teu domini. Té un risc seriós: si es rota el certificat sense actualitzar el pin, l'aplicació deixa de funcionar i només s'arregla publicant una versió nova. Recomanació per a Nimbus: valorar-ho a l'app mòbil —on el cicle d'actualització és controlable i el pin pot apuntar a la CA, no a la fulla—, i no al navegador. Per a la resta, la transparència de certificats (03-06) cobreix el mateix risc amb molt menys cost operatiu.

El protocol pot ser impecable i la implementació anul·lar-lo. L'exemple canònic, ja citat a 02-02:

Què significa exactament aquella línia: la connexió continua xifrada, però s'accepta qualsevol certificat, inclòs el d'un atacant. És a dir, es conserva el cost de TLS i se'n perd per complet la garantia, perquè sense autenticar l'altre extrem el xifratge protegeix una conversa amb qui sigui. És el MITM de 03-03 servit en safata, i en aquest cas concret exposaria el trànsit amb la passarel·la de pagament.

La versió correcta, amb les tres situacions que solen provocar la drecera:

Altres errors del mateix grup, tots habituals i tots igual de greus:

La defensa organitzativa és la de sempre: una comprovació al CI (02-04) que rebutgi verify=False, InsecureSkipVerify, rejectUnauthorized: false i curl -k, i revisió obligatòria entre dues persones per a qualsevol excepció justificada, amb data de caducitat i tiquet associat.

Conceptuals

1. Creure que HTTPS fa segura l'aplicació. Protegeix el tram, no la lògica.
2. Prendre el cadenat per una acreditació d'honestedat. Acredita el domini, res més.
3. Pensar que una VPN substitueix el control d'accés. Dona un túnel; dins del túnel encara cal autoritzar.
4. Suposar que el certificat es renova sol perquè «el vam posar amb Let's Encrypt». La renovació automàtica també es trenca, i cal monitorar-la (03-06).

De configuració

5. Deixar habilitats TLS 1.0/1.1 o suites amb CBC, RC4 o 3DES.
6. Redirigir a HTTPS sense HSTS. La primera petició continua viatjant en clar.
7. Activar includeSubDomains i preload sense comprovar tots els subdominis. Difícil de revertir; pot deixar serveis inaccessibles.
8. Habilitar 0-RTT sense analitzar la repetició.
9. No verificar la configuració efectiva quan hi ha CDN o balancejador al davant: el que serveix el frontal pot no ser el que vas configurar.

D'implementació

10. verify=False i equivalents. L'error canònic.
11. Validar la cadena però no el nom del host.
12. Acceptar a cegues una empremta SSH nova o canviada.
13. Fixar un pin de certificat sense pla de rotació. Converteix una renovació rutinària en una caiguda.

Consells

• Configura TLS 1.3 per defecte, deixa 1.2 només amb suites ECDHE-AEAD si tens clients antics, i revisa aquesta decisió amb dades dels teus registres cada sis mesos.
• Monitora la data de caducitat de cada certificat amb alerta a 30 i a 7 dies. Un certificat caducat és una incidència de disponibilitat, i a Equifax (02-06) va encegar a més la detecció.
• Automatitza la verificació: una comprovació programada que executi openssl s_client contra els teus dominis i alerti si canvien la versió, la suite o l'empremta del certificat.
• Recorda la jerarquia de responsabilitat: el protocol el trien els estàndards, la versió i la configuració les tries tu, i la validació la respecta el teu codi. Els tres han d'estar bé.

La Lucía executa openssl s_client contra un servei intern i obté:

Es demana: (a) enumera tots els problemes que revela aquesta sortida i ordena'ls per gravetat; (b) explica quina garantia concreta es perd amb cadascun; (c) indica si el certificat autosignat és sempre una fallada o pot ser acceptable, i sota quines condicions; (d) proposa la configuració objectiu per a aquest servei intern.

Nimbus integra una nova passarel·la de pagament. El proveïdor ofereix: TLS 1.2 o 1.3, mTLS opcional, signatura HMAC dels webhooks i una llista blanca d'IP.

Es demana: (a) decideix quins mecanismes activar i en quina direcció actua cadascun (Nimbus→passarel·la, passarel·la→Nimbus); (b) explica quina amenaça concreta atura cada mecanisme i quins se superposen; (c) indica què passa si la clau privada del certificat de client de Nimbus es filtra, i què ha de passar aleshores; (d) raona si la llista blanca d'IP és un control criptogràfic i quin valor real aporta.

El Rubén pregunta per què, si el web de Nimbus «redirigeix sol a HTTPS», cal configurar res més.

Es demana: (a) descriu pas a pas un atac d'stripping contra un client de Nimbus a la wifi d'una cafeteria; (b) explica per què la redirecció 301 no l'impedeix; (c) explica què fa HSTS i què hi afegeix preload; (d) indica els dos riscos operatius d'includeSubDomains i preload i com es mitiguen abans d'activar-los.

Exercici 1

(a) i (b) Problemes per gravetat:

(c) És sempre una fallada? No necessàriament. Per a un servei intern, l'inacceptable no és que el certificat no el signi una CA pública, sinó que no el signi res en què el client confiï explícitament. És acceptable si existeix una CA interna el certificat arrel de la qual està instal·lat als clients i aquests el validen de debò (verify="/ruta/ca-interna.pem", apartat 11). El que no és mai acceptable és la combinació habitual: certificat autosignat més verify=False als clients, que és xifratge sense autenticació.

(d) Configuració objectiu: certificat emès per la CA interna de Nimbus (03-06), amb SAN correcte per a interno.nimbus.local; només TLS 1.3, en ser tots els clients propis; clau ECDSA P-256 o Ed25519; validació estricta a tots els clients contra l'arrel interna; i, com que és comunicació entre serveis, mTLS (apartat 8), amb renovació automatitzada i alerta de caducitat.

Exercici 2

(a) i (b) Mecanismes:

Superposicions. mTLS i llista blanca se superposen parcialment en la direcció Nimbus→passarel·la, però actuen en capes diferents (identitat criptogràfica davant d'origen de xarxa) i són complementaris en defensa en profunditat (01-03). TLS i HMAC no se superposen: TLS protegeix el canal, HMAC protegeix el missatge, i encara cal HMAC encara que el webhook arribi per HTTPS, perquè HTTPS acredita el canal, no qui va compondre el contingut.

(c) Si es filtra la clau privada del certificat de client: un atacant podria autenticar-se davant de la passarel·la com a Nimbus. Cal revocar el certificat immediatament, emetre'n un de nou amb una clau nova, desplegar-lo, notificar-ho al proveïdor, revisar els registres de la passarel·la a la recerca d'operacions no reconegudes i executar l'anàlisi de causa arrel (per què la clau era accessible). El cicle de vida complet, a 03-06.

(d) La llista blanca d'IP no és un control criptogràfic: no aporta confidencialitat, integritat ni autenticitat demostrable, i l'adreça d'origen és suplantable en alguns escenaris. El seu valor real és reduir la superfície d'atac (01-04) i filtrar soroll automatitzat. És un control útil i barat, però mai no pot substituir TLS ni l'HMAC.

Exercici 3

(a) L'atac, pas a pas. (1) El client es connecta a la wifi de la cafeteria, on l'atacant controla el punt d'accés o fa enverinament ARP. (2) Escriu nimbusreservas.example al navegador, sense https://. (3) El navegador emet una petició HTTP en clar. (4) L'atacant la intercepta i no la deixa arribar; en lloc d'això estableix ell una connexió HTTPS legítima amb Nimbus i serveix a l'usuari el mateix contingut per HTTP. (5) L'usuari veu el web correcte, sense cadenat —pocs se'l miren— i introdueix les seves credencials. (6) L'atacant les llegeix en clar i les reenvia a Nimbus, que veu una sessió perfectament normal.

(b) Per què la redirecció 301 no basta. La redirecció l'envia el servidor, i en aquest atac la petició inicial no arriba mai al servidor: la intercepta l'atacant, que simplement no redirigeix. La redirecció només actua quan el trànsit arriba a Nimbus; l'atac viu precisament al tram anterior.

(c) Què fa HSTS. La capçalera Strict-Transport-Security indica al navegador que, durant max-age segons, ha de fer servir HTTPS obligatòriament per a aquell domini, convertint internament qualsevol http:// en https:// abans d'enviar res per la xarxa. Després d'una sola visita legítima, l'stripping deixa de funcionar. preload va més enllà: el domini s'inscriu en una llista que els navegadors porten de fàbrica, de manera que la regla s'aplica fins i tot a la primera visita, cobrint l'únic forat que quedava.

(d) Els dos riscos operatius. (1) includeSubDomains obliga a HTTPS a tots els subdominis, presents i futurs; si algun —un web intern, un entorn de proves, un panell antic— només serveix HTTP, deixarà de ser accessible des dels navegadors que hagin vist la capçalera. (2) preload és molt difícil de revertir: la retirada de la llista triga mesos a propagar-se amb les versions dels navegadors, així que un error s'arrossega molt de temps. Mitigació: inventariar tots els subdominis i comprovar que serveixen HTTPS vàlid; desplegar primer amb un max-age curt (per exemple, 300 segons) i sense preload; verificar durant unes setmanes; i només aleshores pujar a dos anys i sol·licitar la inscripció.

Has fet el salt de les peces a l'assemblatge, i amb ell una idea que convé no oblidar: combinar primitives correctes no basta, perquè un protocol falla per no autenticar l'intercanvi, per una negociació manipulable, per manca de frescor, per filtrar informació en els errors o per estats no previstos —cap d'aquestes fallades no requereix trencar l'àlgebra—. D'aquí l'extensió natural de la regla del mòdul: els protocols tampoc no es dissenyen a mà; es trien, es configuren i es verifiquen.

I has saldat el deute pendent des del mòdul 2. Saps què protegeix TLS —confidencialitat, integritat, autenticitat del servidor i forward secrecy al tram— i què no: l'aplicació, les metadades, el servidor compromès i el client infectat. Coneixes l'evolució fins a TLS 1.3 i les seves cinc millores, sent la més important la que menys es cita: que és segur per defecte, perquè les opcions dolentes ja no existeixen. Has recorregut l'encaixada pas a pas veient exactament on entra ECDHE —i amb ell la forward secrecy—, on entra el certificat amb el seu CertificateVerify, que és el que tanca la porta al MITM, i on comença el xifratge simètric AEAD; saps llegir una suite i descartar d'un cop d'ull les que no porten ECDHE o porten CBC. Ho has verificat a la pràctica amb openssl s_client interpretant depth, cadena, versió, suite i Verify return code, i amb curl -I per a HSTS; i has configurat el frontal de Nimbus directiva a directiva: versions, suites, corbes, represa sense 0-RTT, grapat OCSP, HSTS i redirecció. Hi afegeixes mTLS per a pocs sistemes d'alt valor, la panoràmica d'SSH amb la seva confiança a la primera connexió i l'empremta que mai no s'accepta a cegues, IPsec i WireGuard, S/MIME i PGP, l'E2EE com a concepte i el segellat de temps. Tanques amb els atacs clàssics —downgrade, stripping amb HSTS com a resposta, MITM amb certificat fals i el paper real i els riscos del pinning, repetició, oracle de farciment i compressió— i amb l'error d'implementació canònic, el verify=False, que conserva íntegre el cost de TLS i n'anul·la per complet la garantia.

Però fixa't en quantes vegades has hagut d'ajornar la mateixa resposta. Com sap el client que aquell certificat és de Nimbus? Qui el va emetre i amb quina garantia? Què passa quan la clau es filtra o el certificat caduca? Com es munta la CA interna que necessiten l'mTLS i els serveis interns? Tota la seguretat d'aquest capítol descansa sobre la validació d'un certificat, i encara no hem obert aquella caixa.

A Gestió de Claus, Certificats i PKI (03-06) entrem en el que el mòdul 2 va anunciar com «el problema realment difícil», i la tesi és contundent: els algorismes gairebé mai no fallen; la gestió de claus sí. Veuràs el cicle de vida complet d'una clau, on ha de viure —de la variable d'entorn a l'HSM—, per què esborrar el commit del .env filtrat en l'incident de 02-06 no basta, com es rota sense tallar el servei, què conté exactament un certificat X.509, com funciona la cadena de confiança, què garanteixen les CA, com s'emet amb ACME, com es revoca i com la transparència de certificats permet a Nimbus detectar un certificat emès indegudament per al seu domini.