SSL 인증서 임포트

이 섹션에서는 새 SUSE Multi-Linux Manager의 설치를 위해 SSL 인증서를 구성하는 방법과 기존 인증서를 교체하는 방법을 설명합니다.

시작하기 전, 다음을 확인해야 합니다.

  • 인증 기관(CA) SSL 공개 인증서. CA 체인을 사용하는 경우 모든 중간 CA도 사용할 수 있어야 합니다.

  • SSL 서버 개인 키

  • SSL 서버 인증서

  • An SSL database private key

  • An SSL database certificate

모든 파일은 PEM 형식이어야 합니다.

SSL 서버 인증서의 호스트 이름은 인증서 배포 대상이 되는 시스템의 정규화된 호스트 이름과 일치해야 합니다. 인증서의 X509v3 Subject Alternative Name 섹션에서 호스트 이름을 설정할 수 있습니다. 환경에 필요한 경우 여러 호스트 이름을 나열할 수도 있습니다. 지원되는 키 유형은 RSA 및 EC(Elliptic Curve)입니다.

Database SSL certificates require reportdb and db as Subject Alternative Name.

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.

Procedure: Importing certificates on a new SUSE Multi-Linux Manager server

  1. Deploy the SUSE Multi-Linux Manager Server according to the instructions in Install SUSE Multi-Linux Manager Server. Make sure to pass the correct files as parameters to mgradm install podman. The parameters are:

    3rd Party SSL Certificate Flags:
      --ssl-ca-intermediate strings    Intermediate CA certificate path
      --ssl-ca-root string             Root CA certificate path
      --ssl-server-cert string         Server certificate path
      --ssl-server-key string          Server key path
      --ssl-db-ca-intermediate strings Intermediate CA certificate path for the database if different from the server one
      --ssl-db-ca-root string          Root CA certificate path for the database if different from the server one
      --ssl-db-cert string             Database certificate path
      --ssl-db-key string              Database key path

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.

Procedure: Importing certificates on a new SUSE Multi-Linux Manager Proxy

  1. Install the SUSE Multi-Linux Manager Proxy according to the instructions in Install SUSE Multi-Linux Manager Proxy.

  2. 프롬프트를 따라 설정을 완료합니다.

    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.

Procedure: Replacing all existing certificates

  1. The following considers that you have root-ca.pem, intermediate-ca1.pem, intermediate-ca2.pem, server.pem and server.key files. It may be different depending on the number of intermediate CAs in the server certificate signature chain.

  2. 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-ca and uyuni-db-ca secrets. If there is no intermediate CA, then you can use the server.pem instead of the combined file in the next steps.

    cat server.pem intermediate-ca1.pem intermediate-ca2.pem >combined-server.pem

  3. On 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
Procedure: Restarting the server

  1. 컨테이너 호스트에서 서비스를 재시작하여 변경사항을 적용합니다.

    mgradm restart

프록시를 사용하는 경우, 각 프록시의 호스트 이름과 cname을 사용하여 각 프록시에 대한 서버 인증서 RPM을 생성해야 합니다. 새로운 구성 tarball을 생성하고 배포합니다.

For more information, see 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:

mgrctl exec mgr-package-rpm-certificate-osimage

After that, apply highstate on the Image Build hosts to deploy the new certificates for Kiwi to use.
Procedure: Deploying the root CA on clients

  1. SUSE Multi-Linux Manager Web UI에서 Systems  개요로 이동합니다.

  2. 시스템 설정 관리자에 추가하려면 모든 클라이언트를 선택합니다.

  3. 시스템  시스템 세트 관리자  개요으로 이동합니다.

  4. 상태 필드에서 적용을 클릭하여 시스템 상태를 적용합니다.

  5. Highstate 페이지에서 Highstate 적용을 클릭하여 변경사항을 클라이언트에 전파합니다.