企業は通常、将来使用するためにSSL証明書をどこに保存しますか？

最近、ドメイン用のワイルドカードSSL証明書を購入しました。すべての証明書をJavaキーストアに変換しましたが、今は後で使用するためにどこに保存するかを自問しています。

これらのタイプのファイルにBitBucketのようなソース管理を使用するのか、それが必要なときに毎回生成するのか、それとも何か他のものですか？

これらの証明書を将来の使用に備えて保存するための標準的なソリューションまたは「ベストプラクティス」があるのか​​どうか疑問に思っています。

複数の解決策があります。

1つの方法は、ハードウェアベースのアプライアンス、ハードウェアセキュリティモジュール、またはソフトウェアベースの同等の特定のキーボルトです。

もう1つの方法は、古いキーを単純に失効させ、状況が発生したときに新しい秘密/公開キーペアを生成することです。これにより、問題はキーセキュリティの維持から、証明書プロバイダーとその再発行手順を使用してアカウントのユーザー名/パスワードを保護することに変わります。そこにある利点は、ほとんどの組織が既に特権アカウント管理ソリューションを持っていることです。例えば1 2

オフラインストレージには、パスワードを含む秘密キーと公開キーのペアのハードコピーを印刷する方法（復元する雌犬になります）から、長期保存用のデジタルメディアに単純に保存する方法まで、複数の方法があります。

本当に悪い場所は、GitHub、チームのWiKi、またはネットワーク共有です（そして、あなたはアイデアを得ます）。

更新2015/4/29： Keywhizも興味深いアプローチのようです。

いいえ、SSL証明書はソース管理には使用できません。少なくとも秘密キー部分には使用できません。

パスワードと同じように扱います。私たちのものは、実際にパスワードが保存されているのとまったく同じように-KeePassに保存されます。ファイルを添付でき、暗号化されます。

秘密キーをソース管理に入れると、それにアクセスできる人はだれでもサーバーになりすますことができます。WebサーバーがPFS（完全転送秘密）を使用していない場合は、Wiresharkなどの一般的に利用可能なオープンソースツールを使用して、キャプチャしたSSLトラフィックを解読することもできます。

OpenSSLを使用してDESまたはAESをパスフレーズで暗号化することにより、キーを保護できます。OpenSSLは、Linux、OSX、およびWindowsで利用可能です。

OpenSSLは、パスフレーズが不便な場合にもパスフレーズを削除できます（たとえば、自動的に起動するがパスフレーズの自動入力をサポートしないWebサーバー上）。

AES暗号化を使用したパスフレーズの追加（DESよりも安全）：-

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

パスフレーズを削除します（パスフレーズの入力を求められます）：

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

KeyWhizについて読んだ後のもう1つのオプションは、HashiCorpのVaultです。パスワードマネージャーだけでなく、Secretsストアでもあるので、KeyWhizに似ていると思います。GOで記述されており、クライアントはサーバーとしても機能し、多数のバックエンドと認証方法に接続します。Vaultもオープンソースであり、エンタープライズオプションもあります。

SSLキーと証明書は単なるテキストファイルであるため、Base64でエンコードし、Vaultの文字列として、またはVaultのテキストとしても保存できます。WebUI、またはGUI、そのすべてのコマンドライン、またはスクリプト駆動型はなく、起動するための非常に優れた安定したWeb APIがあります。

1. https://www.vaultproject.io/
2. https://github.com/hashicorp/vault

オフラインHSM（ハードウェア暗号化トークンやCACなど）を調べて、秘密キーと証明書を保存することをお勧めします。これは、秘密キーを偶発的な侵害から保護するだけでなく、基本的な暗号化オフロードも提供します。

より多くの暗号化資産を管理する必要がある場合は、更新の自動化、ライフサイクルの追跡、エンドポイントへのプロビジョニングの自動化などが可能なEnterprise Key＆Certificate Managementソフトウェアを検討することをお勧めします。データベース内のCLOB。