同じSSLをインストールする/TLS 複数のサーバーに証明書を配布するには、主に2つの方法があります。サーバー間で証明書を共有することは、SSL.com証明書の無料機能です。 再入力 証明書は、追加料金なしで必要な回数だけ（再発行）できます。以下では、サーバー間で証明書を共有または展開するための 2 つのアプローチと、自動化と管理に関する推奨事項について説明します。
方法 1: PFX ファイル経由で証明書を共有する
最初の方法には、 .pfx ファイルの作成 （PKCS#12アーカイブ）に証明書、中間証明書、秘密鍵を格納し、 .pfxをインポートする 他のサーバーにアップロードします。(Microsoft Azure などの多くのクラウド プロバイダーでは、サービスを利用するには .pfx 形式の証明書をアップロードする必要があります。)
ステップ：
-
.pfx ファイルをエクスポートする 証明書がインストールされているサーバーから取得できます。 またはWindows 証明書のエクスポート ウィザード（参照 ）。これらのガイドでは、秘密鍵、サーバー証明書、および必要な中間証明書を 1 つの PFX ファイルに結合します。
-
.pfxファイルをインポートする 証明書を必要とする各追加サーバーで実行します。Linux/Unixシステムの場合は、OpenSSLを使用してPFXから証明書とキーを抽出できます（SSL.comのガイドを参照してください）。 Windowsサーバーでは、証明書MMCスナップインまたはIISマネージャーを使用してPFXをインポートできます。 .
-
サーバーを構成する インポートした証明書を使用するには、証明書をサイトまたはサービスにバインドする必要があります。たとえば、IIS では、証明書を Web サイトの HTTPS ポートと IP にバインドする必要があります (SSL.com では、 （参考用）。他のサーバーでは、新しい証明書と秘密キー ファイルを指すように構成を更新します。構成が完了すると、サーバーは安全な接続に共有証明書を使用します。
方法 2: サーバーごとに固有の証明書
代替方法は、大規模な導入ではより安全ですが、追加の証明書管理が必要になります。各サーバーに 独自の秘密鍵と証明書 （まったく同じキーを共有するのではなく）新しいキーを使用して各サーバーにSSL.com証明書を再発行することができます。 CSR およびキーペア:
ステップ：
-
生成する CSR 各サーバーの秘密鍵
証明書が必要です。プラットフォーム固有のガイダンスに従って、新しい証明書署名要求を作成します。
-
Linux/Unix ApacheまたはNginxサーバーの場合は、 CSR OpenSSL を使用（ (Apache/Nginx 環境の場合)。
-
Windows/IISの場合は、サーバーのGUIまたはPowerShellを使用して、 CSR （SSL.comのハウツーを参照してください） ).
-
WHM/cPanelの場合は、cPanelのSSL/TLS インターフェースを生成する CSR （参照してください ). 各サーバーは独自の秘密鍵を持ち、 CSR.
-
-
証明書の注文を再処理する SSL.comで新しい CSRSSL.comアカウントポータルで証明書の注文を探し、 キーの再生成/再処理 新しいものを提出するオプション CSR（SSL.comでは、 これにより、サーバーの証明書と一致する新しい証明書がCAから生成されます。 CSRこれを実行するたびに、新しい証明書が送信されます (他のサーバーの以前の証明書も有効なままです)。
-
新しい証明書をそれぞれのサーバーにインストールします。 再発行後、通常の単一サーバー証明書と同様に、そのサーバーに証明書ファイルをダウンロードしてインストールします。たとえば、次の手順に従ってインストールします。 , , または 、プラットフォームによって異なります。インストールして設定すると、そのサーバーは ユニーク 証明書（独自の秘密鍵付き）を発行します。必要に応じて、追加のサーバーごとにこのプロセスを繰り返します。（発行された証明書はすべて元の注文に関連付けられており、同じ発行条件が適用されます。）
SSLの自動化/TLS 証明書管理
サーバーの数が増加すると、証明書を手動でエクスポート、コピー、再発行するのは面倒になります。効率とセキュリティを向上させるには、SSL.com とコミュニティが提供する次の自動化ツールとソリューションを検討してください。
-
ACME プロトコル自動化 – SSL.comは、 自動証明書管理環境（ACME） ハンズフリー証明書の発行と更新（). ACMEクライアントなど Certbot (EFFの人気のLet's Encrypt用ACMEツール)と Kubernetescert-manager SSL.comのACMEエンドポイントを指定して、サーバーに証明書を自動的に要求してインストールすることができます。これにより、複数のシステム間で証明書をシームレスに同期および更新できます。詳細については、SSL.comの Certbotがどのように証明書管理を効率化できるかを説明します。Certbotのドキュメントは、 さまざまなプラットフォーム向けのKubernetes cert-managerプロジェクトについては、 – どちらも SSL.com の ACME サービスと互換性があります。ACME を使用すると、証明書のライフサイクル タスク (発行、更新、失効) がクライアント ソフトウェアによって標準化された方法で処理されるため、ほとんどの手動手順が不要になります。
-
SSL.com SSL Manager – Windows環境の場合、SSL.comは SSL Manager SSL/TLSの注文、インストール、管理を可能にする無料のGUIツールです。TLS 証明書（コード署名証明書やドキュメント署名証明書も含む）をデスクトップから直接作成できます。 CSR証明書の展開、Windows 証明書ストアへの証明書のインストール、証明書形式の変換をすべて 1 か所で実行できます。これは、複数の Windows サーバーまたはサービスに証明書を展開する必要がある場合に特に便利です。手動コマンドを実行する代わりに、数回のクリックでキーと証明書を管理できます。 SSL Manager 証明書の保存にはハードウェアトークンデバイス（YubiKeyなど）も統合されています。 SSL Manager 複数の Windows サーバーを扱う際に時間を節約し、エラーの可能性を減らすことができます。
-
ホステッド PKI 解決策 – 企業での導入や大規模なニーズには、SSL.comの ホステッド PKI プラットフォーム。SSL.comの SSL.comのクラウドベースの証明書インフラストラクチャを活用して、組織はWebインターフェースまたはAPIを介して証明書を発行および管理できます。このソリューションは、複数のサーバー、アプリケーション、さらにはIoTデバイスの証明書を一元管理できます（)ホストされたプライベート CA/RA (登録機関) サービスを使用すると、独自の証明機関を実行する必要はありません。SSL.com が面倒な作業 (安全なキー管理、インフラストラクチャ、監査) を処理し、使いやすいツールまたは RESTful API を通じて証明書発行ポリシーと自動化を制御します。これは、複雑な環境での証明書の展開を自動化するのに理想的であり、CI/CD パイプラインまたは DevOps ワークフローに統合してシームレスなスケーラビリティを実現できます。
-
スクリプトとDevOpsツール – 上記に加えて、証明書タスクを構成管理または展開スクリプトに組み込むことができます。たとえば、LinuxではOpenSSLコマンドを含むシェルスクリプトを使用して証明書を配布および再ロードし、Windowsでは PowerShellの スクリプト（Microsoftの 証明書をインポートしてサービスにバインドするには、次の手順に従ってください。これらのアプローチを ACME プロトコルまたは SSL.com API と組み合わせると、DevOps プロセスのエンドツーエンドの自動化が可能になります。証明書操作をスクリプト化することで、手作業の労力を減らし、期限切れの証明書や構成エラーによるダウンタイムのリスクを最小限に抑えることができます。
サポートと連絡
SSLの管理/TLS 複数のサーバーにまたがる証明書は疑問を生じさせる可能性があります。サポートが必要な場合は、 SSL.comのサポートチームがお手伝いしますよくある質問への回答は、 では、詳細なハウツー記事やFAQを提供しています。個別のサポートについては、
