CA con firma incrociata: la chiave combacia, il binding AKI no
Una foglia può fissare il proprio emittente tramite l'identificatore di chiave insieme a emittente e numero di serie. Verifica quel binding prima di considerare intercambiabile una catena con firma incrociata.
Due certificati CA possono avere la stessa chiave pubblica e lo stesso soggetto e non essere comunque intercambiabili. Uno è autofirmato, l'altro è firmato in modo incrociato dalla vecchia radice, e i loro nomi di emittente, numeri di serie e firme differiscono. Una foglia può legarsi specificamente a uno dei due tramite il suo Authority Key Identifier. Quel binding resta invisibile finché un client sceglie la catena sbagliata e l'handshake fallisce senza un motivo evidente.
Esegui questi cinque controlli in ordine: ognuno esclude un guasto diverso.
Controllo 1: disegna entrambe le catene prima di toccare il modello
Annota i percorsi. La popolazione vecchia si fida della Vecchia radice A, che ha emesso la CA B, che ha emesso la foglia del server. La popolazione nuova si fida direttamente della CA B autofirmata. Entrambi i certificati B portano la stessa chiave e lo stesso soggetto, ed è proprio per questo che chi legge una riga di soggetto vede una CA dove il client ne vede due.
La copia con firma incrociata deve essere anch'essa un vero certificato CA, con basic constraints e key usage che consentano la firma.
Controllo 2: confronta i campi AKI, non solo la chiave
Il nome dell'emittente della foglia deve corrispondere al soggetto di B, e questa parte di solito regge. L'Authority Key Identifier è il punto in cui le due copie divergono, perché può portare un identificatore di chiave, un emittente del certificato e un numero di serie. L'identificatore di chiave corrisponde a entrambe le copie, dato che la chiave è identica. I campi emittente e serie corrispondono esattamente a una, e per questo una catena costruita contro la copia autofirmata può fallire contro quella con firma incrociata.
Ispeziona la foglia invece di indovinare: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.
Poi confronta entrambi i candidati con openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", e lo stesso comando contro la copia autofirmata.
Se la foglia porta emittente e numero di serie, solo il certificato che quei valori descrivono completa la catena, qualunque copia il client abbia caricato.
Controllo 3: cambia la politica di emissione, mai i byte firmati
Le estensioni vivono dentro la firma. Aggiungerne, rimuoverne o modificarne una su una foglia esistente non è una riparazione, è un certificato diverso e richiede una riemissione. La modifica appartiene alla politica di emissione: authorityKeyIdentifier = keyid,issuer:always fa portare alle nuove foglie il binding specifico del certificato, mentre keyid da solo conserva la forma più permissiva adatta a una transizione deliberata di firma incrociata. Decidi quale vuole la tua PKI prima che venga firmato il lotto successivo.
Modificare un modello condiviso cambia anche ogni certificato futuro, non solo il server davanti a te.
Controllo 4: verifica ogni popolazione di fiducia separatamente
Prova il vecchio percorso e il nuovo come esecuzioni separate. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem esercita la rotta con firma incrociata, e lo stesso comando con la nuova radice e senza file untrusted esercita la rotta autofirmata. Mescolare entrambe le radici in un solo bundle nasconde quale catena è stata scelta. Ripeti poi con client reali, perché un backend VPN può preferire una catena o fissare un certificato in modi che openssl non fa.
Consegna il certificato intermedio tramite la configurazione del servizio che il client legge davvero, non tramite una pagina wiki.
Controllo 5: tieni il vecchio percorso su un orologio di dismissione
La firma incrociata mantiene vivo per progetto un vecchio percorso di fiducia, che è insieme lo scopo e il rischio. Non rimedia a una vecchia radice compromessa e non rimuove quella radice da nessun client. Annota quando il vecchio percorso smette di concedere fiducia, e conferma che quel giorno arrivi davvero.
Se ogni client può accettare la nuova radice prima che le foglie si muovano, un semplice rollout a doppia fiducia è più semplice della firma incrociata, e lascia una cosa in meno da dismettere.