È possibile automatizzare l'uso di chiavi private crittografate con passphrase?

Un riavvio del server è un evento serio e non dovrebbe mai accadere da solo . Idealmente dovrebbe esserci un admin connesso a trigger il riavvio - o almeno a riavviare il server dopo che ha diagnosticato il motivo per cui è andato giù in primo luogo, se si trattava di un down non programmato.

Quindi l'amministratore può fornire manualmente la passphrase.

Come alternativa più debole , il SSLPassPhraseDialog potrebbe essere utilizzato per fornire la passphrase.

Per rafforzare lo scenario, lo script deve essere protetto (altrimenti non è migliore di una passphrase in chiaro, o senza passphrase), quindi dovrebbe chiedere per la passphrase a un secondo server questo ha alcuni mezzi per accertare se la richiesta è legittima o meno.

Ad esempio, se c'è una diagnosi sul server, allora e solo allora un accesso SSH per l'utente servermaint da quell'un IP è concesso e il corretto password echo:

ssh -i identity_file servermaint@passphraseserver "getpassphrase"

E identity_file identifica solo quel server con un indirizzo IP noto.

Un utente malintenzionato che ha avuto accesso al server Web non ha trovato passphrase e non sarebbe stato in grado di accedere a passphraseserver (in realtà lui avrebbe , ma un tale tentativo innescherebbe un avvisalo e disconnettilo immediatamente invece di fornire la passphrase - e segnerà anche il server come compromesso).

Un utente malintenzionato dovrebbe quindi non solo penetrare nel server, ma anche causare un arresto del server Web, e mantenere il controllo del server Web mentre vengono eseguite diagnostica e analisi forense, un evento improbabile nel migliore dei casi: con quel tipo di controllo, potrebbe essere in grado di sfruttare il processo Apache e ottenere una copia della passphrase quando il vero amministratore di sistema lo digita.

Naturalmente, in uno scenario più semplice e più comune ("Voglio solo che il mio server ritorni indietro se va giù, il più velocemente possibile - non importa perché è andato giù, succederà sempre ogni ora e quindi "), sarebbe più semplice escludere del tutto la passphrase.

Stai valutando che 2 non è più sicuro che 1 sia corretto. È un altro passo in cui un attaccante può districare ma non è così difficile.

L'opzione 3 è meglio di 1 e 2, ma un aggressore intelligente con privilegi di livello root può probabilmente far uscire il tuo certificato dalla memoria.

Bottom line: il tuo server deve avere il tuo certificato in forma non criptata per servire il traffico HTTPS e qualcuno con accesso a livello di root sarà in grado di raggiungerlo. È solo una questione di tempo e impegno.

L'opzione migliore è quella di proteggere il certificato sull'host con le autorizzazioni sui file, eseguire il server con privilegi sub-root (lasciandolo passare da root a nessuno o http dopo che è associato alla porta 80 e 443 e caricato il certificato) e monitorare l'host per comportamento insolito.

Se dovesse accadere il peggio e la tua certificazione è compromessa, ecco a cosa servono gli elenchi di revoca dei certificati.

[Modifica] Un'altra cosa in più ... le protezioni che metti intorno al tuo certificato dipendono dal livello di rischio che sei disposto ad accettare.