Dove le aziende in genere archiviano i certificati SSL per uso futuro?

26

Di recente abbiamo acquistato un certificato SSL jolly per il nostro dominio. Abbiamo convertito tutti i certificati in un keystore Java, ma ora ci stiamo chiedendo dove dovremmo archiviarli per un uso successivo.

Le persone usano il controllo del codice sorgente come BitBucket per questi tipi di file o semplicemente generano ogni volta che è necessario o qualcos'altro?

Ci chiediamo se esiste una soluzione standard o eventuali "migliori pratiche" per la memorizzazione di questi certificati per un uso futuro.

ssl-certificate certificate best-practices

— AmericanKryptonite
fonte

Esegui il backup crittografato sulla tua soluzione di backup tradizionale. Non archiviare le chiavi private non crittografate con nessun provider esterno. Di solito includo il problema e scado le date nel mio cert e chiave nome file per la differenziazione.

— Andrew Domaszek,

22

Esistono più soluzioni:

Una strada è un deposito chiave specifico o un'appliance basata su hardware, un modulo di sicurezza hardware o un equivalente basato su software.

Un altro è semplicemente revocare la vecchia chiave e generare una nuova coppia di chiavi privata / pubblica quando si presenta la situazione. Ciò in qualche modo sposta il problema dal mantenimento della sicurezza delle chiavi alla protezione del nome utente / password dell'account con il fornitore del certificato e delle loro procedure per la riemissione. Il vantaggio è che la maggior parte delle organizzazioni ha già una soluzione di gestione degli account privilegiata, ad es. 1 2

Esistono diversi modi di archiviazione off-line, dalla stampa di una copia cartacea della coppia di chiavi privata e pubblica inclusa la password (ma che sarà un cane femmina da ripristinare) alla semplice memorizzazione su supporti digitali classificati per l'archiviazione a lungo termine .

I posti davvero cattivi sono GitHub, il tuo team WiKi o una condivisione di rete (e ottieni l'idea).

Aggiornamento del 29/04/2015: Keywhiz sembra anche un approccio interessante.

— HBruijn
fonte

Sono curioso, cosa intendi con "equivalente basato su software" per HSM?

Al giorno d'oggi alcuni dei fornitori di dispositivi hardware vendono i loro dispositivi anche sotto forma di dispositivo virtuale, una macchina virtuale. Ci sono anche cose come Oracle Key Vault e The open source SoftHSM per citarne alcuni.

— HBruijn,

Quindi, in pratica, ciò consente di trasformare un computer standard in un HSM ...

1

"ma sarà una cagna da restaurare" -> Questo ha reso la mia giornata! Scherzi a parte, è necessario crittografarlo prima di salvare.

— Ismael Miguel,

Per definizione, esponerai la tua chiave pubblica a tutti. Non c'è motivo di crittografarlo. Ma questa non è una ragione per essere sciatta. La sicurezza è principalmente per la chiave privata, che in genere dovrebbe essere effettivamente crittografata / protetta da password. Dovresti mirare ad avere il minor numero di copie possibile.

— HBruijn,

21

No, i certificati SSL non vanno nel controllo del codice sorgente, almeno non nella parte della chiave privata.

Trattali come faresti con una password. Le nostre password vengono archiviate esattamente come fanno le nostre password - in KeePass. Ti consente di allegare file ed è crittografato.

— Concedere
fonte

3

Se metti la chiave privata nel controllo del codice sorgente, chiunque abbia accesso ad essa sarà in grado di impersonare il tuo server. Se il tuo server web non sta usando PFS (perfetto segreto in avanti), è anche possibile decrittografare qualsiasi traffico SSL acquisito con strumenti open source comunemente disponibili come Wireshark.

È possibile proteggere la chiave con DES o AES crittografandola con una passphrase utilizzando OpenSSL. OpenSSL è disponibile per Linux, OSX e Windows.

OpenSSL può anche rimuovere la passphrase quando una passphrase è scomoda (ad es. Su un server web che si avvia automaticamente ma non supporta l'inserimento automatico delle passphrase).

Aggiunta di una passphrase utilizzando la crittografia AES (più sicura di DES): -

openssl rsa -aes256 -in private.key -out encrypted.private.key

Rimozione di una passphrase (verrà richiesta la passphrase): -

openssl rsa -in encrypted.private.key -out decrypted.private.key

— Difficile
fonte

1

Se si sta facendo le cose per bene allora anche l'esposizione della chiave privata non dovrebbe portare alla compromissione del traffico passato, anche se sicuramente sarebbe fare MITM'ing per il traffico futuro compromesso molto più facile.

— un CVn

Ciao @Michael, in teoria, ma purtroppo sono stato in grado di decifrare molte acquisizioni di Apache e IIS, quindi posso solo supporre che PFS sia disattivato per impostazione predefinita. Anche molte VPN IPSEC lo hanno spento.

— Tricky,

PFS non è tanto off di default in quanto non è supportato da molte suite di crittografia. Prova il test del server SSL Labs qualche volta; indica quali suite di crittografia supportano FS. Naturalmente, la disabilitazione di tutte le suite di crittografia non FS probabilmente lascerà fuori molti clienti al freddo perché non supportano le suite di crittografia FS. Tuttavia, il trattamento preferenziale delle suite FS dovrebbe funzionare (ma sconsiglio vivamente di ordinare manualmente le suite di cifratura a meno che tu non sappia cosa stai facendo e i loro relativi punti di forza e di debolezza).

— un CVn il

Grazie per la raccomandazione su SSL Labs @Michael. Sfortunatamente i miei server non sono rivolti a Internet, ma mi sono divertito con le cifre abilitate e come suggerisci PFS sembra essere supportato solo da alcune cifre. PFS infatti mi impedisce di decodificare le tracce dei pacchetti. Aggiornerò la mia risposta di conseguenza.

— Tricky,

1

Un'altra opzione, dopo aver letto su KeyWhiz, era HashiCorp's Vault. Non è solo un gestore di password, ma un negozio di segreti, credo in qualche modo simile a KeyWhiz. È scritto in GO e il client funziona anche come server e si aggancia a una serie di backend e metodi di autenticazione. Vault è anche open-source, con anche l'opzione Enterprise.

Poiché chiavi e certificati SSL sono solo file di testo, è possibile codificarli in base64 e salvarli come stringa in Vault o anche solo il testo in Vault. Non esiste una WebUI o una GUI, tutta la sua riga di comando o script guidato e ha un'API Web molto buona e stabile per l'avvio.

— pred
fonte

0

Consiglierei di esaminare un HSM offline (come un token di crittografia hardware o un CAC) per archiviare la chiave privata e il certificato. Ciò non solo protegge la chiave privata da compromessi accidentali, ma fornisce anche alcuni offload crittografici di base.

Se hai più risorse crittografiche da gestire, consiglierei di esaminare un software Enterprise Key & Certificate Management, che può automatizzare i rinnovi, tenere traccia del ciclo di vita, automatizzare il provisioning agli endpoint, ecc. La maggior parte di questi archivia le risorse crittografate a riposo come CLOB in un database.

— DTK
fonte

Perché i downvotes? Non lamentarsi; curioso di sapere cosa c'è che non va in questa risposta.

— Matt

Non sono sicuro del perché abbia votato. Gli HSM sono progettati specificamente per l'archiviazione sicura delle chiavi e la crittografia ad alta velocità. Posso solo supporre che sia correlato alla spesa o alla gestione più complessa. Tutte le principali banche utilizzano HSM per operazioni chiave in operazioni come Chip & Pin.

— Ingannevole