Suggerirei di utilizzare una radice completamente separata per i certificati interni ed esterni, per evitare qualsiasi perdita di informazioni sugli host interni o sugli utenti, tramite Root01, ma anche per impedire qualsiasi trust implicito da parte di software non funzionante. Utilizzando 2 root separati per l'uso esterno e interno, non è possibile che nessun trust provenga da certificati esterni a interni, indipendentemente da come è danneggiato il software.
Normalmente, se abbiamo percorsi di certificazione che assomigliano a questo:
Root01 --> SubCA01 -> Cert01
Root01 --> SubCA02 -> Cert02
E SubCA02 è importato come affidabile. In un'implementazione PKI valida, Cert01 non dovrebbe essere considerato attendibile. Ma come sapete con codifica pigra, software rotto e analisi hacky dei certificati, è possibile che la fiducia trapeli da subCA02 a Root01 e quindi trapelare causando a Cert01 la fiducia di qualcuno che non dovrebbe fidarsi di quel certificato, se il L'implementazione di PKI è molto spezzata e, ad esempio, presuppone che ogni cert più alto sia considerato attendibile automaticamente. Sì, è molto estrapolato, ma è meglio tenere conto di eventuali software danneggiati usando invece radici completamente separate.
Vorrei anche aggiungere un vincolo di base PathLength = 0, che impedisce al certificato CA di essere utilizzato per firmare altri certificati CA, oltre al vincolo del nome.
Come forse saprai, c'è un sacco di software rotto là fuori, e un attacco di escalation di privilegi (come lo chiami quando qualcuno riesce a firmare un certificato in violazione con i vincoli) può accadere, per esempio se il suddetto certificato PolicyExt01 è usato per firmare una CA subordinata, che a sua volta sta firmando un certificato S / MIME.
Alcuni software rotti controllano solo i vincoli di denominazione di esempio "1 livello Deep" e l'aggiunta di un vincolo Pathlength causerebbe il fallimento di catene più lunghe invece di essere accettate come attendibili.
Quindi vorrei fare così:
Root01 (Name constraints = [email protected], PathlenConstraint=0, EKU=Message signing)
Root02 (Internal applications, not trusted by 3rd parties...)
E quindi condividere il certificato Root01 con quelle terze parti che dovrebbero fidarsi di esso, mentre installa Root01 e Root02 in tutti i computer interni all'azienda.
Sia Root01 che Root02 sono quindi certificati CA radice autofirmati.
Quando si utilizza Namingconstraint, inserirei solo un vincolo di denominazione [email protected] e quindi inserire tutti gli altri vincoli di denominazione (IP, DNS, UPN, URI) come caratteri jolly esclusi, per impedire l'utilizzo di un certificato come per esempio un certificato SSL di un sito Web, se un browser o un'implementazione SSL non fosse in grado di analizzare i flag di utilizzo della chiave.
Una buona idea è anche testare la tua configurazione, preferibile esportando il certificato della CA radice e la chiave privata in un computer sicuro, e poi provare a firmare certificati "non validi" con questo. Quindi prova i certificati "non validi" con il software client comune per assicurarti che i vincoli si stiano verificando e contrassegnando il certificato come non attendibile.
Personalmente non conosco alcuna configurazione esplicita che possa causare un tale attacco di "escalation di privilegi", ma come sai, ci sono molte implementazioni SSL e software PKI danneggiati, quindi è meglio prevenire che curare e limitare i certificati come il più possibile, e usa anche radici separate per evitare qualsiasi perdita di fiducia tra i certificati da parte del software MOLTO danneggiato.