SSL 인증서 임포트

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

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

  • 인증 기관(CA) SSL 공개 인증서. CA 체인을 사용하는 경우 모든 중간 CA도 반드시 사용 가능해야 합니다.

  • SSL 서버 개인 키

  • SSL 서버 인증서

  • SSL 데이터베이스 개인 키

  • SSL 데이터베이스 인증서

All files must be in PEM format. All CA certificates in the chain must mark X509v3 Basic Constraints as critical and include CA:TRUE. For more information, see Verify CA Basic Constraints.

The hostname of the SSL server certificate must match the fully qualified hostname of the machine you deploy them on. You can set the hostnames in the X509v3 Subject Alternative Name section of the certificate. You can also list multiple hostnames if your environment requires it. Supported Key types are RSA and EC (Elliptic Curve).

In previous versions the database SSL certificates required reportdb and db as Subject Alternative Name. This is no longer needed.

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 mgradm 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. Verify CA Basic Constraints

Strict certificate validators reject CA certificates when the X509v3 Basic Constraints extension is not marked as critical. This includes Python 3.13 and later, which is used by SUSE Linux Enterprise Server 16 and openSUSE Leap 16.

Before importing certificates or upgrading an existing installation, verify every root and intermediate CA certificate used by SUSE Multi-Linux Manager. For each CA certificate, run:

openssl x509 -in root-ca.pem -noout -text | grep -A1 "Basic Constraints"

The output must include critical and CA:TRUE:

X509v3 Basic Constraints: critical
  CA:TRUE

If a CA certificate does not include both values, replace or regenerate the affected CA certificate before using it with SUSE Multi-Linux Manager. Replacing only the server certificate does not fix a CA certificate that misses the critical flag. For self-signed certificates generated by SUSE Multi-Linux Manager, see administration:ssl-certs-selfsigned.adoc#ssl-certs-selfsigned-create-replace. To replace a CA that is still trusted by the clients without interrupting their connection, see Migrate SSL Certificate Authorities.

2. 새 설치를 위해 인증서 임포트

기본적으로 SUSE Multi-Linux Manager은(는) 자체 서명된 인증서를 사용합니다. 인증서는 설치 시점에 타사 인증서로 임포트할 수 있습니다.

절차: 새 SUSE Multi-Linux Manager 서버에 인증서 임포트

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

    타사 SSL 인증서 플래그:
      --ssl-ca-intermediate 문자열   임시 CA 인증서 경로
      --ssl-ca-root 문자열            루트 CA 인증서 경로
      --ssl-server-cert 문자열        서버 인증서 경로
      --ssl-server-key 문자열         서버 키 경로
      --ssl-db-ca-intermediate 문자열         서버와 다른 경우 데이터베이스의 중간 CA 인증서 경로
      --ssl-db-ca-root string          서버와 다른 경우 데이터베이스의 루트 CA 인증서 경로
      --ssl-db-cert string             데이터베이스 인증서 경로
      --ssl-db-key string              데이터베이스 키 경로

중간 CA는 --ssl-ca-root로 지정한 파일에서 사용하거나 --ssl-ca-intermediate을 사용하여 추가 옵션으로 지정할 수 있습니다. --ssl-ca-intermediate 옵션은 여러 번 지정할 수 있습니다.

3. 새 프록시 설치를 위한 인증서 임포트

프록시 인증서는 생성된 구성에 포함되어 있습니다. 타사 인증서를 사용하려면 구성 절차 중에 해당 인증서를 제공해야 합니다.

절차: 새 SUSE Multi-Linux Manager 프록시에 인증서 임포트

  1. SUSE Multi-Linux Manager 프록시 설치의 지침에 따라 SUSE Multi-Linux Manager 프록시를 설치합니다.

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

    동일한 인증 기관(CA)을 사용하여 서버 및 프록시에 대한 모든 서버 인증서에 서명합니다. 다른 CA로 서명된 인증서는 일치하지 않습니다.

4. 인증서 바꾸기

SUSE Multi-Linux Manager 설치의 활성 인증서를 새 인증서로 교체할 수 있습니다. 고려해야 할 두 가지 경우는 서버 또는 데이터베이스 인증서만 교체하는 경우와 루트 CA를 교체하는 경우입니다.

루트 인증서를 교체하려면 등록된 모든 프록시와 시스템이 서버 수준에서 새 CA로 전환하기 전에 데이터베이스에 새 CA를 적용해야 하므로 중단을 방지하기 위해 더 많은 시간과 계획이 필요합니다.

중간 CA가 서명한 타사 인증서를 사용할 경우, 중간 CA 인증서를 서버 또는 데이터베이스 인증서 파일에 추가해야 합니다.

순서가 중요합니다. 먼저 서버 인증서가 오고, 그런 다음 해당 인증서를 서명한 CA부터 루트 CA가 서명한 CA의 순서입니다. 루트 CA 인증서를 서버 인증서 파일에 추가해서는 안 됩니다.

절차: 모든 기존 인증서 교체

  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. SUSE Multi-Linux Manager 컨테이너 호스트에서 명령 프롬프트를 열고, 파일 경로를 전달하여 podman 인증서 시크릿을 다시 생성하십시오.

    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
절차: 서버 재시작

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

    mgradm restart

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

자세한 내용은 installation-and-upgrade:container-deployment/mlm/proxy-deployment-mlm.adoc#_generate_proxy_configuration을 참조하십시오.

루트 CA가 변경된 경우 SUSE Multi-Linux Manager에 연결된 모든 클라이언트에 배포해야 합니다. 이 작업은 미리 수행하는 것이 이상적이며, 이를 통해 혼란을 최소화할 수 있습니다.

절차: 클라이언트에 루트 CA 배포

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

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

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

  4. In the States field, click Apply to apply the system states.

  5. In the Highstate page, click Apply Highstate to propagate the changes to the clients.