@ La risposta di SebastianOerding è buona, ma proverò una spiegazione diversa sviluppando il concetto di un certificato incrociato.
Certificato incrociato
Supponiamo che tu abbia due CA separate e desideri che i client di CA1 (ovvero quelli con CA1 nei loro archivi fiduciari) si fidino dei certificati emessi da CA2. Vuoi farlo senza aggiungere CA2 al loro negozio di fiducia.
La soluzione è un certificato incrociato , da Microsoft documentazione:
Cross certification enables entities in one public key infrastructure (PKI) to trust entities in another PKI. ... A mutual trust relationship between two CAs requires that each CA issue a certificate to the other to establish the relationship in both directions. The path of trust is not hierarchal (neither of the governing CAs is subordinate to the other).
Quindiogniradicerilasciauncertificatocontenentelachiavepubblicadell'altro(autofirmato)CAprincipale.Ciòconsenteaimotoridiconvalidadeipercorsidi"fingere" che il certificato di autofirmazione radice di CA2 sia stato emesso dal certificato trasversale, che è stato emesso da CA1.
Certificato di collegamento
Ora, pensate a un certificato di collegamento come caso speciale di un certificato incrociato in cui CA1 e CA2 sono due certificati radice diversi per la stessa CA (vale a dire la stessa CA DN), ma con diverse chiavi pubbliche (e probabilmente anche diversa scadenza date, numero di serie, posizione CRL, ecc.)
La scadenza del codice radice è un problema perché, per quanto riguarda i client, è una CA nuova di zecca. I certificati di collegamento colmano tale lacuna dicendo ai clienti che questo nuovo certificato radice sostituisce quello scaduto nel loro archivio fidato.