La distinzione dipende da alcuni dettagli sul certificato autofirmato e su come reagiranno il browser e il sistema operativo.
Un certificato normale include un'estensione Basic Constraints che contiene una bandiera che indica se il certificato è per una CA o no; quando il flag è TRUE , il certificato è considerato accettabile come emittente per altri certificati. Se manca completamente l'estensione, il certificato deve essere considerato come non CA.
I certificati CA root sono "speciali"; non sono certificati veri. Sono trust anchors ; un TA è, nominalmente, una chiave pubblica accoppiata con un nome. È tradizionale codificare i trust ancore come certificati e, poiché un certificato include un campo per una firma, alcuni byte devono essere memorizzati lì; ancora una volta, la Tradizione dice che faremo il certificato autofirmato . Nessuno controlla davvero quella firma, però; i junk byte di circa la giusta dimensione servirebbero altrettanto bene.
Il punto delicato è quindi che l'interpretazione delle eventuali estensioni di certificato trovate in tale "certificato CA radice" non è standard. In particolare, alcuni CA storici risalgono a prima dell'invenzione dell'estensione Basic Constraints ; come veri certificati, sarebbero interpretati come "non CA", ma dal momento che sono ancore fidate camuffate da certificati, le normali regole di interpretazione non si applicano.
Quindi su alcuni browser o sistema operativo, un certificato non CA (privo di un'estensione Basic Constraints , o addirittura di uno con il flag cA impostato su FALSE ), una volta installato nell'archivio "root CA", può benissimo iniziare ad essere accettato come CA. Pertanto, la riservatezza della chiave privata per qualsiasi certificato installato nel trust store dell'utente è piuttosto critica.
Qual è la differenza nel tuo caso? Dopo tutto, nella tua situazione, ci sono due scelte:
- Si crea un certificato autofirmato per il proprio server e l'utente installa tale certificato come "attendibile".
- Si crea un certificato CA autofirmato, che l'utente installa come "affidabile". emetti un certificato normale per il tuo server con questa CA.
In entrambi i casi, l'utente cede la sua sicurezza ad un certificato da te, che l'utente installa come "fidato". Quindi cosa cambierebbe?
La differenza è che se si utilizza una CA personalizzata, è possibile memorizzare la chiave privata corrispondente con una buona protezione. Ad esempio, tu fai la CA business su un laptop che è tenuto offline in ogni momento. Non c'è possibilità di un exploit remoto quando non c'è nessuna rete. La CA principale deve essere sempre offline e utilizzata solo come parte delle procedure manuali e delle chiavi USB per il trasferimento dei dati. D'altra parte, il tuo server è, beh, un server, quindi è online e intrinsecamente esposto. Un utente malintenzionato che accede al tuo server può ottenere una copia della chiave privata del server. Se la chiave pubblica corrispondente è stata installata come "trusted root" nelle macchine degli utenti, anche l'hacker ottiene molto vantaggio su queste macchine.
In breve, la creazione di una CA personalizzata distinta dal certificato del server (utilizzato tutto il giorno) consente una migliore protezione della chiave privata e quindi un minore rischio di aumento di potenza da parte di un aggressore catastrofico.
Ci sono browser che non sono così vulnerabili . Quello che vuoi veramente, con un certificato server autofirmato, è che gli utenti si fidano del certificato solo per le connessioni SSL (non come CA), e solo per quello specifico server. Firefox sa come farlo; si chiama "eccezione di sicurezza" nella terminologia di Firefox (vedi Preferenze - > Avanzate - > Certificati - > Visualizza certificati, quindi la scheda "Server").