Le chiavi pubbliche sono destinate a essere pubbliche. L'intera idea delle infrastrutture a chiave pubblica è che la conoscenza della chiave pubblica di root CA è sufficiente: una volta che conosci (con una certa certezza ) quella chiave pubblica, quindi è possibile ottenere una certa garanzia sulla proprietà delle chiavi pubbliche da parte degli utenti mediante la convalida dei certificati.
Non c'è alcun problema per te nel mettere il certificato CA stesso su un sito Web pubblico. Questo è considerato buono. Infatti, i certificati emessi da una CA dovrebbero contenere un URL che punta al certificato della CA (questo è il accesso alle informazioni dell'autorità estensione).
Il puzzle è dalla parte dei clienti. PKI non crea trust ex nihilo ; lo trasporta. I clienti possono ottenere il certificato CA (presumibilmente autofirmato) ma in qualche modo devono fidarsi di aver ottenuto quello giusto. La solita procedura è che la identificazione personale (in realtà, un hash) del certificato è ottenuta tramite un metodo non specificato ma "sicuro" (ad esempio, i client telefonano al tuo sysadmin e specifica quaranta caratteri esadecimali) e i client verificano che il thumprint che hanno ottenuto corrisponda a quello che calcolano con il certificato CA ottenuto.
Un altro problema, che in realtà è più difficile, è che la maggior parte dei software di posta elettronica non offre alcun modo per limitare la fiducia nella CA radice, ad esempio, in un sottodominio specifico. Uno dei client vorrebbe configurare la sua macchina in modo che il certificato CA sia attendibile, ma solo per verificare i certificati e-mail collegati alle e-mail nel dominio @example.com . In altre parole, la mancanza di opzioni di segmentazione sul lato client significherà che importando il certificato CA, in realtà si fidano della CA per molte cose. Potrebbero rifiutarsi di farlo.