In teoria, se un sistema era abbastanza sicuro e hai mai firmato la CSR su un server separato, mantenendo tale chiave dannatamente , non ci sarebbero problemi con questo.

Tuttavia,

• Che cosa succede se qualcuno fa ha in qualche modo compromesso la chiave privata?
• Qual è il tuo piano in caso di violazione?
• Avrai quella chiave privata per il tuo certificato TLS sullo stesso server del server di firma ?

Chiediti: c'è qualche vantaggio nell'usare la stessa chiave per più di 1000 domini? Puoi spiegare l'unico punto di errore ai tuoi clienti?

Inoltre, RSA (almeno) non ha all'attacco attualmente noto l'utilizzo per la firma ripetuta che darebbe via la chiave. Quello è riservato a DSA con un PRNG poco raccomandabile.

Ancora, è una cattiva idea.

Aggiornamento

Il sistema che vuoi in questo caso sarebbe il seguente:

1. Ogni cliente viene incarcerato (tramite chroot() ) nella propria directory sul server
2. Per ogni CSR generato, una chiave privata viene generata nella prigione dell'utente, ma al di fuori del webroot.
   • es. /jail/customername/private/server.key
   • /jail/customername/domains/<domain>/subdomains/<subdomain>/public
   • /jail/customername/domains/<domain>/public
   • /jail/a/domains/a.com/public/ , ecc.
3. Il server web deve rispettare le jail e i linguaggi di scripting devono essere eseguiti come utenti che non possono accedere alla cartella privata nella prigione di ogni utente.

Non ci sarebbero problemi con questo sistema; Suppongo che tu stia utilizzando un sistema host condiviso e che desideri un modo semplice per generare un CSR per ciascun cliente per abilitare TLS.

In questo modo, hai una separazione corretta e forzata dei privilegi per ciascun cliente e nel caso in cui un cliente venga compromesso (salvo eventuali exploit di escalation di privilegi locali), il resto dell'infrastruttura è valido e puoi semplicemente revocare il certificato TLS da l'utente che è stato sfruttato.

Non c'è pericolo nella creazione di molti CSR per la stessa chiave privata, oltre al riutilizzo della chiave privata stessa.

Un CSR contiene:

• informazioni sulla richiesta di certificato (soggetto ecc.)
• la chiave pubblica
• una firma di quanto sopra, utilizzando la chiave privata

Per quanto ne so, non c'è mai stato un caso in cui la firma ripetuta con una chiave privata ha degradato la sicurezza della chiave privata. Se ci fosse, saremmo tutti nei guai.

Tuttavia . Riutilizzare la stessa chiave privata per molti domini è una pessima idea. Dovresti generare una nuova chiave privata per ogni CSR che generi. Non appena inizi a farlo, potrebbero esserci dei problemi! Un utente malintenzionato potrebbe generare molte chiavi private e ciò a sua volta ridurrebbe l'entropia disponibile sul sistema, causando (ipoteticamente) la possibilità che le chiavi private fossero più prevedibili.

Originariamente ho scritto un commento con due possibili problemi in precedenza, e poi ho capito che potrebbe esserci uno ancora più grande che merita una risposta.

Diciamo che esiste una (finora) ipotetica vulnerabilità zero-day nel server Web, nel sistema operativo o altrove che consente a un'applicazione PHP di accedere alla chiave privata. Normalmente, questo sarebbe sfruttabile solo inserendo un file PHP dannoso. Sarebbe una seria vulnerabilità, ma può essere sfruttata solo da remoto attraverso altre vulnerabilità che consentono il caricamento non autorizzato di uno script PHP.

Se condividi la chiave privata, tale vulnerabilità diventerebbe catastrofica. Tutto ciò che un utente malintenzionato dovrebbe fare è registrare un account con te, caricare l'exploit PHP e avere istantaneamente la chiave privata per migliaia di altri siti Web.

Analogamente, nel tuo scenario, qualcosa come Heartbleed non solo comprometterebbe un sito, ma rivelerebbe la chiave privata per tutti i tuoi clienti in una volta, rendendo questo problema già serio assolutamente catastrofico.