Certificati del server, autorità di certificazione e server

Il tuo certificato avrà determinate proprietà, credo che siano chiamate "utilizzo certificato" o simili. Se, sotto, trovi Certificate Signing , allora sì, puoi utilizzare il tuo certificato per firmare altri certificati.

Nota: il vincolo Signing da solo non significa che puoi firmare altri certificati, deve essere il Certificate Signing completo.

Il tuo certificato jolly è valido per tutti i domini che corrispondono a *.domain.com , quindi sì puoi usare il tuo certificato per https su qualsiasi sottodominio, e sarà accettato dai browser client - presupponendo naturalmente che il tuo certificato sia firmato da un trusted CA.

Nota aggiuntiva:

Un modo semplice per capire è quanto hai pagato per questo certificato. Un certificato di Certificate Signing firmato da una CA affidabile e onnipresente vale una grande quantità di denaro.

Un certificato vale quanto chiunque convalida pensa che sia. Un certificato è valido per SSL fino a quando i client SSL (ad esempio browser Web o client VPN) lo accettano come validi. Qualunque cosa tu faccia, i clienti esistenti condurranno il ballo.

Un certificato "jolly" è descritto in RFC 2818 , sezione 3.1:

Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., .a.com matches foo.a.com but not bar.foo.a.com. f.com matches foo.com but not bar.com.

Questo è l'unico posto in cui il carattere " * " ha un significato speciale. Ciò significa che il certificato jolly è "un certificato jolly" solo nel contesto di un server HTTPS: in quel contesto, il client richiederà che il nome del server previsto (quello nell'URL) corrisponda al nome nel certificato; la "wildcard" è una sorta di abbinamento. Quindi il tuo certificato sarà accettato dai clienti come certificato per i server foo.domain.com, bar.domain.com, qux.domain.com ... e così via.

Si noti che alcuni altri protocolli hanno più o meno adottato le stesse regole di corrispondenza dei nomi; per esempio. un certificato per un server IMAPS dovrà anche contenere il nome del server (ovvero, il nome che i client si aspettano). Inoltre, tieni presente che il supporto completo per i caratteri jolly è una specie di rarità (i clienti che accettano di considerare *fo*.domain.com come foo.domain.com corrispondente non sono legione).

Questo è completamente ortogonale alla questione dell'emissione di certificati secondari. Un certificato accettato come emittente per un altro certificato è denominato certificato CA e il segno distintivo di un certificato CA è che contiene un'estensione Vincoli di base con il flag cA impostato su TRUE ( vedi RFC 5280 , sezione 4.2.1.9). Nessun cliente accetterà un certificato emesso dal certificato "jolly" a meno che non abbia questo flag; e la presenza o l'assenza di un carattere " * " nel nome è totalmente irrilevante qui.

Come nota a margine, trovo un po 'dubbioso l'idea di "proteggere tutto" copiando lo stesso certificato e la chiave privata in molte macchine. Più copia una chiave privata, meno diventa segreta. La crittografia asimmetrica era intesa come un modo per evitare copiare le chiavi segrete. Il normale paradigma del certificato è che ogni entità in una rete dovrebbe avere la propria chiave privata, invece di condividere la stessa chiave privata tra gli host.

Sarei molto sorpreso se tu abbia mai ottenuto un certificato valido che ha fatto entrambi. I certificati di firma dei certificati tendono a farlo solo, non supportano l'identificazione del server (ad es. SSL), data la reale necessità di protezione.

Se quel certificato e la chiave privata sono stati installati su un server Web, tutto ciò che un utente malintenzionato dovrebbe fare è violare quel server Web e ora dispongono di una chiave di firma CA attendibile. Con tale chiave di firma potevano quindi generare un certificato valido per qualsiasi dominio su Internet. Quindi perché devono essere protetti.