Certificati SSL Wildcard e SAAS

Non c'è niente di sbagliato in "certificati jolly". Un certificato con caratteri jolly equivale a un certificato che contiene molto di possibili nomi di server. Se questo si adatta bene al tuo problema (ad esempio hai un server con molti frontend che pubblicizzano nomi distinti, ma tutti questi nomi sono nello stesso dominio e tu controlli quel dominio), allora i certificati jolly sono sicuramente una possibilità. I principali problemi con i certificati jolly sono:

• Un certificato con caratteri jolly è utilizzabile con diversi nomi del server, e di solito devi usare diversi nomi perché hai diversi macchine . Poiché il certificato jolly corrisponde alla chiave privata one , quella chiave privata dovrà essere installata su tutte queste macchine. Le chiavi private duplicate e che viaggiano sono in qualche modo meno private, perché sono più esposte.

• Le CA commerciali utilizzano un modello aziendale che si basa sulla vendita di molti certificati. Un certificato con caratteri jolly consente al cliente di acquistare un certificato un anziché molti . Pertanto, le CA commerciali tendono a rendere i certificati con caratteri jolly molto più costosi, per compensare la corrispondente perdita di affari.

Nella tua situazione, a quanto ho capito, hai un server di hosting, che gestisce un server SSL per diversi siti; i siti hanno nomi che seguono lo schema name.example.com dove name è un nome specifico del cliente e example.com è un dominio sotto il tuo controllo. Poiché, in HTTPS , la finestra di dialogo SSL si verifica per prima (prima che si verifichi qualsiasi HTTP), il server non (di solito) conosce il nome del server previsto (il nome dall'URL utilizzato dal client), il server deve in qualche modo inviare un certificato che "funziona bene" con tutti i possibili nomi dal client. Questo porta a tre possibili soluzioni:

1. Utilizza un certificato con caratteri jolly con *.example.com . Funzionerà bene.
2. Utilizza un certificato con molti nomi nell'estensione Subject Alt Name . Puoi mettere centinaia di nomi lì dentro. Anche questo funziona, ma devi ottenere un nuovo certificato ogni volta che vuoi aggiungere un nuovo nome (un certificato è firmato dalla CA, non puoi cambiare nulla in esso senza invalidare la firma).
3. Fai in modo che il server "indovini" il nome del server previsto, in modo che possa inviare il certificato "giusto" (il server avrebbe quindi molti certificati, uno per ogni nome di sito). Questo utilizza l'estensione Nome server : uno slot nei primi messaggi SSL handshake in modo che il client possa comunicare al server, prima il server invia effettivamente il suo certificato, il nome del sito che il cliente si aspetta. SNI funziona bene, ad eccezione del fatto che alcuni vecchi browser o sistemi operativi non lo inviano, quindi l'uso di questa estensione significa che non si supporteranno tali client. Il client principale non supportato è Internet Explorer su Windows XP (IE su sistemi Windows più recenti va bene). Se pensi di poterti permettere di rifiutare i client che usano ancora Windows XP e IE, allora SNI è una soluzione praticabile per te.

Il certificato con caratteri jolly sembra ancora il metodo più semplice e robusto.

L'uso del certificato con caratteri jolly non è un problema se ne capisci le implicazioni.

Tuttavia, se non vuoi (o non puoi) utilizzare un certificato jolly, nel tuo caso hai poca scelta ma emetti un nuovo certificato separato per ogni sottodominio.

In teoria, potresti anche utilizzare il certificato SAN ma a meno che tu non sappia in anticipo l'elenco completo dei domini che sei andando a proteggere, sarà una soluzione che cresce ancora più male di avere un nuovo certificato per ogni sottodominio.

Ora, se non sei disposto a utilizzare un certificato con caratteri jolly, perché non sei esattamente disposto a rilasciare un nuovo certificato per ogni nuovo cliente?

Modifica : sei preoccupato di perdere l'intero sistema nel caso in cui la tua chiave sia compromessa. tuttavia, vi è un piccolo motivo pratico per cui la suddivisione della crittografia utilizzando più chiavi migliorerà la sicurezza: l'unica parte alla quale sarà richiesto di accedere alla chiave privata sono gli endpoint SSL del server, quindi, assumendo che si abbia un controllo limitato su ciò che accade sul end server (e temete che l'azione del cliente possa compromettere il proprio server, forse perché gli fate eseguire il proprio codice, allora la soluzione è distribuire un proxy inverso davanti ai vostri server che gestirà la crittografia pubblica e manterrà la tua chiave sicura (puoi anche configurare una connessione SSL interna tra il proxy e i server se vuoi crittografare le comunicazioni all'interno della tua rete).

Un sistema di questo tipo sarà più semplice da gestire e sicuro di quello che ogni server usa il proprio certificato (inoltre, sarà più economico e può essere implementato con soluzioni off-the-shelf).