PKI - Public Key Infrastructure e Chain of Trust

Cos'e'

#

Sistema di policy, ruoli e tecnologie che gestisce l'intero ciclo di vita delle chiavi pubbliche — generazione, distribuzione, verifica, revoca e rinnovo. Senza PKI, l'asymmetric encryption e' vulnerabile al MITM perche' non c'e' modo di verificare a chi appartiene una public key.

TL;DR

#

Il problema: senza PKI non puoi verificare a chi appartiene una public key — vulnerabile a MITM. Con la CA, il binding chiave-identita' e' firmato da un'autorita' fidata. Il tuo OS ha gia' ~150 CA pre-approvate nel trust store.

Flusso in 4 passi:

1. Root CA (offline) firma la public key dell'Intermediate CA
2. Intermediate CA emette e firma i leaf certificate (siti, VPN, email...)
3. Browser riceve il cert e risale la catena fino alla Root CA
4. Root CA nel trust store → connessione fidata

Chain of Trust

#

La chain of trust e' la gerarchia a tre livelli che distribuisce la fiducia dalla CA root verso il basso. Ogni livello firma il livello successivo — chi firma sta garantendo chi viene firmato.

flowchart TD
    ROOT["Root CA
self-signed, trust anchor, OFFLINE"]
    ICA1["Intermediate CA 1"]
    ICA2["Intermediate CA 2"]
    E1["End-entity
HTTPS / VPN / S/MIME / code signing"]
    E2["End-entity
HTTPS / VPN / S/MIME / code signing"]

    ROOT -->|"firma public key"| ICA1
    ROOT -->|"firma public key"| ICA2
    ICA1 -->|"leaf certificate"| E1
    ICA2 -->|"leaf certificate"| E2

    style ROOT fill:#1a1a2e,fill-opacity:0.8,color:#58a6ff,stroke:#58a6ff
    style ICA1 fill:#1a2a1a,fill-opacity:0.8,color:#7ec87e,stroke:#7ec87e
    style ICA2 fill:#1a2a1a,fill-opacity:0.8,color:#7ec87e,stroke:#7ec87e

Lettura diagramma: La Root CA (blu, offline) firma le public key delle Intermediate CA (verde, online). Le Intermediate emettono i leaf certificate alle end-entity. La fiducia scorre sempre dall'alto verso il basso.

Perche' la Root CA e' offline: se compromessa, tutti i certificati che ha emesso diventano inaffidabili — l'intera PKI collassa (vedi DigiNotar). L'Intermediate CA fa il lavoro quotidiano; se viene compromessa, la Root intatta puo' revocarla e emetterne una nuova.

Dev parallel: come la catena di dipendenze npm. Se un pacchetto intermedio e' compromesso, tutto cio' che dipende da lui e' a rischio. La Root CA e' il nodo radice — se cade, cade tutto l'albero.

Come si verifica un certificato

#

La verifica e' completamente locale: nessuna chiamata di rete verso la CA durante la navigazione. La CA ha firmato il certificato in anticipo e non partecipa alla connessione.

sequenceDiagram
    participant B as Browser
    participant S as Server (google.com)
    participant TS as Trust Store (OS)

    B->>S: 1 - Connessione HTTPS
    S->>B: 2 - Invia certificato (pub key + identita' + firma DigiCert)
    Note over B: 3 - "Firmato da DigiCert"
    B->>TS: 4 - DigiCert e' nel trust store?
    TS->>B: 5 - Si' - CA fidata
    Note over B: 6 - Verifica firma localmente
    Note over B: usa pub key DigiCert dal trust store
    Note over B: ricalcola hash del certificato
    Note over B: confronta con firma DigiCert
    Note over B: coincidono = certificato autentico
    B->>S: 7 - Key exchange con pub key google.com
    Note over B,S: 8 - Sessione cifrata AES

Il trust store e' un archivio di CA fidate pre-installato dal produttore dell'OS:

• macOS: Keychain Access (~170 CA)
• Windows: certmgr.msc — Trusted Root Certification Authorities
• Linux: /etc/ssl/certs/ o pacchetto ca-certificates
• Firefox: trust store proprio (Mozilla NSS), indipendente dall'OS — Firefox non usa il trust store di Windows o macOS

Ciclo di vita del certificato

#

Un certificato nasce con una richiesta CSR (Certificate Signing Request) e muore con la revoca o la scadenza. La private key non esce mai dal server del richiedente.

Processo CSR in 7 passi:

1. Genera chiave privata (la pub key e' derivata da essa)
2. Genera CSR PKCS10 — pub key + info soggetto: CN, O, L, S, C
3. Invia CSR alla CA — la priv key NON viene mai inviata
4. CA valida (DV / OV / EV)
5. CA emette il cert firmato con la priv key dell'Intermediate CA
6. Installa il cert sul web server o nel keystore dell'app
7. Server usa il cert nelle sessioni HTTPS, VPN, mTLS

Livelli di validazione:

RA vs CA: la Registration Authority raccoglie le informazioni di registrazione e verifica l'identita' del richiedente, ma NON emette certificati. L'emissione spetta sempre e solo alla CA.

Revoca - CRL vs OCSP

#

Un certificato puo' diventare non valido prima della scadenza: chiave privata compromessa, dipendente licenziato, CA compromessa. La revoca e' il meccanismo per invalidarlo immediatamente.

OCSP Stapling: il server scarica e firma la risposta OCSP in anticipo e la allega al certificato durante il TLS handshake. Il browser non contatta la CA — veloce e privato.

PKI oltre HTTPS

#

Il meccanismo e' sempre lo stesso: una CA firma il binding "questa chiave appartiene a questa entita'". HTTPS e' solo il caso piu' visibile.

Quando la PKI non serve: SSH classico usa TOFU (Trust On First Use) — accetti la chiave al primo collegamento, poi known_hosts fa la guardia. PGP/GPG usa web of trust — gli utenti si firmano le chiavi di persona.

War Story - DigiNotar 2011

#

Nel 2011 la CA olandese DigiNotar fu violata. Gli attaccanti emisero certificati falsi per google.com, CIA, Mossad e altri. Qualsiasi browser che si fidava di DigiNotar accettava quei certificati come legittimi — connessioni HTTPS verso server impostori senza nessun warning.

Quando la compromissione fu scoperta:

1. Tutti i browser vendor rimossero DigiNotar dai trust store in giorni
2. Tutti i certificati emessi da DigiNotar diventarono automaticamente non validi
3. DigiNotar falli' settimane dopo

La stessa logica vale in DevSecOps: se la CA privata interna di un cluster Kubernetes e' compromessa, tutti i certificati mTLS dei microservizi diventano inaffidabili simultaneamente. Per questo la Root CA aziendale va tenuta offline.

Dev parallel DevSecOps: in cloud, una CA privata interna e' esattamente quello che gestisci con AWS Private CA o Azure Private CA. Quando deploy microservizi su Kubernetes con mutual TLS (mTLS), ogni service account ha un certificato emesso dalla CA interna — i pod si autenticano l'uno con l'altro come fa un browser con un sito HTTPS. Cert-manager su K8s automatizza emissione e rinnovo.

Scenario Reale Blue Team

#

Situazioni operative dove la PKI e' rilevante per un analyst.

# Verificare chain e scadenza di un servizio interno
openssl s_client -connect servizio-interno:443 -showcerts 2>/dev/null \
  | grep -E "subject|issuer|notAfter"

# Scansionare piu' domini per scadenze imminenti
for domain in api.internal sso.internal vault.internal; do
  echo -n "$domain: "
  echo | openssl s_client -connect $domain:443 2>/dev/null \
    | openssl x509 -noout -enddate
done

Un certificato valido non significa che il sito e' sicuro — significa che la connessione e' cifrata e che una CA ha verificato l'identita'. Un attaccante puo' avere un certificato DV valido per un dominio di phishing: la CA verifica il controllo del dominio, non le intenzioni.

Collegato a

#

• crypto — categoria
• ssl-tls — come TLS usa la PKI nel handshake
• cryptography — cifratura asimmetrica alla base dei certificati
• dnssec — chain of trust applicata ai record DNS