SSL証明書のインポート
このセクションでは、新しいSUSE Multi-Linux ManagerのインストールにSSL証明書を設定する方法、および既存の証明書を置き換える方法について説明します。
開始する前に、以下があることを確認します。
-
認証局(CA) SSLパブリック証明書。 CAチェーンを使用している場合は、すべての中間CAも使用できる必要があります。
-
SSLサーバ秘密鍵
-
SSLサーバ証明書
-
SSLデータベース機密鍵
-
SSLデータベース証明書
すべてのファイルがPEM形式である必要があります。
SSLサーバ証明書のホスト名は、配備先マシンの完全修飾ホスト名と一致している必要があります。 ホスト名は、証明書のX509v3 Subject Alternative Nameセクションで設定できます。 環境で必要な場合は、複数のホスト名を一覧にすることもできます。 サポートされているキーの種類は、RSAとEC (Elliptic Curve)です。
|
データベースSSL証明書では、 |
Third-party authorities commonly use intermediate CAs to sign requested server certificates. In this case, all CAs in the chain are required to be available. The mgrdadm commands are taking care of ordering the certificates. Ideally, the root CA should be in its own file. The server certificate file should contain the server certificate first, followed by all intermediate CA certificates in order.
1. 新しいインストール用証明書のインポート
By default, SUSE Multi-Linux Manager uses a self-signed certificate. Certificates can be imported with third-party certificates at the installation time.
SUSE Multi-Linux Managerサーバのインストールの手順に従ってSUSE Multi-Linux Managerサーバを配備します。必ず、正しいファイルをパラメータとして
mgradm install podmanに渡してください。パラメータは次のとおりです。サードパーティSSL証明書フラグ: --ssl-ca-intermediate文字列 中間CA証明書のパス --ssl-ca-root文字列 ルートCA証明書のパス --ssl-server-cert文字列 サーバ証明書のパス --ssl-server-key文字列 サーバキーのパス --ssl-db-ca-intermediate文字列 データベースの中間CA証明書のパス(サーバの証明書と異なる場合) --ssl-db-ca-root文字列 データベースのルートCA証明書のパス(サーバの証明書と異なる場合) --ssl-db-cert string データベース証明書のパス --ssl-db-key string データベースキーのパス
Intermediate CAs can either be available in the file which is specified with --ssl-ca-root, or specified as extra options with --ssl-ca-intermediate. The --ssl-ca-intermediate option can be specified multiple times.
2. Import certificates for new proxy installations
The proxy certificates are embedded in the generated configuration. In order to use a third-party certificate, it needs to be provided during the configuration.
SUSE Multi-Linux Managerプロキシのインストールの手順に従って、SUSE Multi-Linux Managerプロキシをインストールします。
プロンプトに従ってセットアップを完了します。
Use the same certificate authority (CA) to sign all certificates for servers and proxies. Certificates signed with different CAs do not match.
3. Replace certificates
You can replace active certificates on your SUSE Multi-Linux Manager installation with a new certificate. There are two cases to consider: replacing only the server or database certificate, and replacing the root CA.
Replacing the root certificate requires more time and planning to avoid disruption as all the registered proxies and systems will need to have the new CA in their database before switching to it at the server level.
When using third-party certificates signed by an intermediate CA, the intermediate CA certificates need to be appended to the server or database certificate file.
The order is important: first comes the server certificate, then the CAs from the one which signed the certificate to the one signed by the root CA. The root CA certificate should not be appended to the server certificate file.
The following considers that you have
root-ca.pem,intermediate-ca1.pem,intermediate-ca2.pem,server.pemandserver.keyfiles. It may be different depending on the number of intermediate CAs in the server certificate signature chain.Combine the intermediate CAs and server certificates. The order matters, the server must be first and the intermediate CAs in order. Do not add the root CA last into the chain as it will be passed separately to
uyuni-caanduyuni-db-casecrets. If there is no intermediate CA, then you can use theserver.peminstead of the combined file in the next steps.cat server.pem intermediate-ca1.pem intermediate-ca2.pem >combined-server.pemOn the SUSE Multi-Linux Manager container host, at the command prompt, recreate podman certificate secrets passing the files paths:
podman secret create --replace uyuni-ca $path_to_ca_certificate podman secret create --replace uyuni-cert $path_to_combined_server_certificate podman secret create --replace uyuni-key $path_to_server_key podman secret create --replace uyuni-db-ca $path_to_database_ca_certificate podman secret create --replace uyuni-db-cert $path_to_combined_database_certificate podman secret create --replace uyuni-db-key $path_to_database_key
コンテナホストで、サーバを再起動して変更を取得します。
mgradm restart
プロキシを使用している場合は、各プロキシのホスト名とcnameを使用して、各プロキシ用のサーバ証明書RPMを生成する必要があります。 新しい設定tarballを生成して配備します。
詳細については、installation-and-upgrade:container-deployment/mlm/proxy-deployment-mlm.adoc#_generate_proxy_configurationを参照してください。
If the Root CA was changed, it needs to get deployed to all the clients connected to SUSE Multi-Linux Manager. This is ideally done in advance to minimize the disruption.
|
If the CA certificate was updated, a RPM file with Kiwi certificate needs to be repackaged. On the SUSE Multi-Linux Manager Server container host, execute following command:
After that, apply highstate on the Image Build hosts to deploy the new certificates for Kiwi to use. |
SUSE Multi-Linux Manager Web UIで、に移動します。
すべてのクライアントをチェックして、システムセットマネージャに追加します。
に移動します。
[
状態]フィールドで、適用をクリックして、システムの状態を適用します。[
highstate]ページで、highstateの適用をクリックして、クライアントに変更を伝播します。