Où les entreprises stockent-elles généralement les certificats SSL pour une utilisation future?

26

Nous avons récemment acheté un certificat SSL générique pour notre domaine. Nous avons converti tous les certificats en un fichier de clés Java, mais nous nous demandons maintenant où nous devons les stocker pour une utilisation ultérieure.

Les gens utilisent-ils le contrôle de code source comme BitBucket pour ces types de fichiers ou génèrent-ils simplement chaque fois que cela est nécessaire, ou autre chose?

Nous nous demandons s'il existe une solution standard ou des "meilleures pratiques" concernant le stockage de ces certificats pour une utilisation future.

ssl-certificate certificate best-practices AméricainKryptonite
la source
Sauvegardez-les chiffrés dans votre solution de sauvegarde traditionnelle. Ne stockez pas les clés privées non chiffrées avec un fournisseur externe. J'inclus généralement le problème et les dates d'expiration dans mon certificat et le nom de fichier clé pour la différenciation.
Andrew Domaszek

Réponses:

22

Il existe plusieurs solutions:

Une avenue est un coffre de clés spécifique, soit une appliance matérielle , un module de sécurité matérielle ou un équivalent logiciel.

Une autre consiste à simplement révoquer l'ancienne clé et à générer une nouvelle paire de clés privée / publique lorsque la situation se présente. Cela déplace quelque peu le problème du maintien de la sécurité des clés à la sécurisation du nom d'utilisateur / mot de passe du compte auprès du fournisseur de certificats et de leurs procédures de réémission. L'avantage est que la plupart des organisations disposent déjà d'une solution de gestion de compte privilégiée, par exemple 1 2

Il existe plusieurs façons de stocker hors ligne, de l'impression d'une copie papier de la paire de clés privée et publique, y compris le mot de passe (mais ce sera une chienne à restaurer), à simplement les stocker sur des supports numériques conçus pour un stockage de longue durée. .

Les endroits vraiment mauvais sont GitHub, votre équipe WiKi ou un partage réseau (et vous avez l'idée).

Mise à jour 2015/4/29: Keywhiz semble également une approche intéressante.

HBruijn
la source
Je suis curieux, que voulez-vous dire par "équivalent logiciel" pour le HSM?
De nos jours, certains fournisseurs d'appareils matériels vendent également leurs appareils sous forme d'appliance virtuelle, une machine virtuelle. Il y a aussi des trucs comme Oracle key vault et The open source SoftHSM pour n'en nommer que quelques-uns.
HBruijn
Donc, fondamentalement, cela permet de transformer un ordinateur standard en HSM ...
1
"mais ce sera une chienne à restaurer" -> Celui-ci a fait ma journée! Blague à part, vous devez la crypter avant de l'enregistrer.
Ismael Miguel
Par définition, vous exposerez votre clé publique à tout le monde. Il n'y a aucune raison de crypter cela. Mais ce n'est pas non plus une raison d'être bâclé. La sécurité est principalement pour la clé privée, qui devrait généralement être cryptée / protégée par mot de passe. Vous devriez viser à en avoir le moins d'exemplaires possible.
HBruijn
21

Non, les certificats SSL n'entrent pas dans le contrôle de code source, du moins pas dans la partie clé privée.

Traitez-les comme vous le feriez avec un mot de passe. Les nôtres sont stockés exactement de la même manière que nos mots de passe - dans KeePass. Il vous permet de joindre des fichiers et est crypté.

Subvention
la source
3

Si vous mettez la clé privée dans le contrôle de code source, toute personne qui y aura accès pourra se faire passer pour votre serveur. Si votre serveur Web n'utilise pas PFS (Perfect Forward Secret), il est également possible de décrypter tout trafic SSL capturé avec des outils open source couramment disponibles comme Wireshark.

Vous pouvez protéger la clé par DES ou AES en la chiffrant avec une phrase secrète à l'aide d'OpenSSL. OpenSSL est disponible pour Linux, OSX et Windows.

OpenSSL peut également supprimer la phrase secrète lorsqu'une phrase secrète n'est pas pratique (par exemple sur un serveur Web qui démarre automatiquement mais ne prend pas en charge la saisie automatique des phrases secrètes).

Ajout d'une phrase secrète en utilisant le cryptage AES (plus sécurisé que DES): -

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

Suppression d'une phrase secrète (vous serez invité à saisir la phrase secrète): -

openssl rsa -in encrypted.private.key -out decrypted.private.key
Rusé
la source
1
Si vous faites les choses correctement, même l'exposition de la clé privée ne devrait pas conduire à compromettre le trafic passé, bien que cela rendrait certainement le MITM plus efficace pour compromettre le trafic futur.
un CVn
Salut @Michael, En théorie, mais malheureusement j'ai pu décrypter beaucoup de captures Apache et IIS, donc je ne peux que supposer que PFS est désactivé par défaut. Même un grand nombre de VPN IPSEC l'ont désactivé.
Tricky
PFS n'est pas tellement désactivé par défaut car il n'est pas pris en charge par de nombreuses suites de chiffrement. Essayez le test du serveur SSL Labs quelque temps; il indique quelles suites de chiffrement prennent en charge FS. Bien sûr, la désactivation de toutes les suites de chiffrement non FS risque de laisser de nombreux clients dans le froid car ils ne prennent pas en charge les suites de chiffrement FS. Donner un traitement préférentiel aux suites FS devrait cependant fonctionner (mais je déconseille fortement de commander manuellement des suites de chiffrement, sauf si vous savez ce que vous faites et leurs forces et faiblesses relatives).
un CVn
Merci pour la recommandation sur SSL Labs @Michael. Malheureusement, mes serveurs ne sont pas accessibles sur Internet, mais j'ai joué avec des chiffrements activés et, comme vous le suggérez, PFS ne semble être pris en charge que par certains chiffrements. PFS m'empêche en effet de décoder les traces de paquets. Je mettrai à jour ma réponse en conséquence.
Tricky
1

Une autre option, après avoir lu sur KeyWhiz, était le coffre-fort de HashiCorp. Ce n'est pas seulement un gestionnaire de mots de passe, mais un magasin de secrets, je crois un peu similaire à KeyWhiz. Il est écrit en GO, et le client fonctionne également comme serveur, et se connecte à un tas de backends et de méthodes d'authentification. Vault est également open-source, avec l'option Entreprise également.

Étant donné que les clés et certificats SSL ne sont que des fichiers texte, vous pouvez les coder en base64 et les enregistrer sous forme de chaîne dans Vault, ou même simplement le texte dans Vault. Il n'y a pas de WebUI ou GUI, sa ligne de commande ou son script, et dispose d'une très bonne API Web stable pour démarrer.

  1. https://www.vaultproject.io/
  2. https://github.com/hashicorp/vault
Pred
la source
0

Je recommanderais d'examiner un HSM hors ligne (comme un jeton de chiffrement matériel ou un CAC) pour stocker la clé privée et le certificat. Cela protège non seulement la clé privée contre les compromis accidentels, mais fournit également un déchargement cryptographique de base.

Si vous avez plus d'actifs cryptographiques à gérer, je vous recommande de rechercher un logiciel de gestion des clés et certificats d'entreprise, qui peut automatiser les renouvellements, suivre le cycle de vie, automatiser le provisionnement des points de terminaison, etc. La plupart d'entre eux stockent l'actif chiffré au repos en tant que CLOB dans une base de données.

DTK
la source
Pourquoi les downvotes? Ne pas se plaindre; curieux de savoir ce qui ne va pas avec cette réponse.
Matt
Je ne sais pas pourquoi il a été rejeté. Les HSM sont spécialement conçus pour le stockage sécurisé des clés et le chiffrement à haute vitesse. Je ne peux que deviner que c'est lié aux dépenses ou à la gestion plus complexe. Toutes les grandes banques utilisent les HSM pour les opérations clés dans des domaines tels que les transactions Chip & Pin.
Tricky