Un certificato digitale, in particolare il formato X.509 più comune utilizzato per TLS, ha un numero di parti. Tre dei più importanti sono il nome soggetto, la chiave pubblica dell'oggetto e la firma dell'emittente. I primi due ti dicono a chi è rivolto il certificato (come "* .stackexchange.com"), e qual è la chiave pubblica che corrisponde alla chiave privata di quell'entità. Lo spoofing di queste parti ti consente di utilizzare un certificato che ti è stato rilasciato per intercettare le richieste su un altro server (cambiando il nome del soggetto) o utilizzare la tua coppia di chiavi pubblica / privata per decodificare lo scambio di chiavi e quindi decrittografare l'intera connessione TLS ( sostituendo la chiave pubblica dell'oggetto con la propria chiave pubblica). Pertanto, il certificato deve essere protetto dalla manomissione e il destinatario del certificato deve essere in grado di dire se il certificato è stato falsificato o meno (si potrebbe, dopo tutto, solo creare i campi dell'oggetto). Ecco dove arriva la firma.
Le firme digitali vengono create utilizzando una chiave privata, non una chiave pubblica, quindi solo il titolare di tale chiave privata può creare la firma. Chiunque abbia la chiave pubblica può comunque verificare la firma. Generalmente si crea una firma di una stringa di byte breve, denominata hash digest crittografico (l'output di una funzione come SHA-256), poiché la crittografia a chiave pubblica / privata è lenta (sebbene in teoria si possa firmare l'intero certificato) . La verifica della stringa della firma la trasforma nuovamente nel digest originale. Se la firma verificata non corrisponde al digest del certificato (che il client può calcolare da sé), il certificato non è attendibile (perché è stato manomesso o ha una firma falsa).
Poiché l'unica entità con la chiave privata di una CA è (in teoria) la CA stessa, solo la CA può creare firme che verificheranno utilizzando la chiave pubblica della CA. Il cliente non ha bisogno di chiedere alla CA se ha firmato il certificato; se la CA non ha firmato il certificato, allora il certificato non avrebbe la firma della CA su di essa (a meno che qualcun altro non si fosse impossessato della chiave privata della CA, che è il tipo di errore che tende a mettere fuori mercato una CA) . Un utente malintenzionato non può semplicemente prendere la firma da un certificato X valido e metterlo su un certificato fraudolento Y, perché quando tale firma viene verificata corrisponderà al digest (output della funzione hash) del certificato X, ma non al digest del certificato fraudolento Y (a meno che l'attaccante non abbia trovato una collisione nella funzione hash, motivo per cui nessuno si fida dei certificati firmati con funzioni hash vecchie e rotte come MD5).
I client, come il browser, sanno quale sia la chiave pubblica della CA perché i certificati CA affidabili (che includono le chiavi pubbliche) sono inclusi con il client o anche con il sistema operativo. Pertanto, non posso semplicemente firmare qualcosa con la mia chiave privata e far finta che Verisign l'abbia firmato; La chiave pubblica di Verisgn è già nota al tuo cliente e non verrebbe verificata la firma, quindi non ti fidi del certificato. Questa fiducia è spesso usata in modo transitorio; una CA radice (come Verisign) potrebbe dire "Mi fido di questa cosiddetta CA intermedia, quindi firmerò il loro certificato (inclusa la parte che dice che il loro certificato può firmare altri certificati) e dovresti fidarti di loro come te fidati di me." La CA intermedia può quindi firmare un certificato per un sito Web o qualcosa, che si trova in fondo a una "catena di fiducia" che collega il certificato del server Web al certificato della CA principale tramite la CA intermedia.