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 인증서에는 |
타사 기관은 일반적으로 중간 CA를 사용하여 요청된 서버 인증서에 서명합니다. 이 경우 체인의 모든 CA를 사용할 수 있어야 합니다. mgrdadm 명령이 인증서 정렬을 처리합니다. 루트 CA는 별도의 파일에 위치하는 것이 좋습니다. 서버 인증서 파일은 서버 인증서를 맨 앞에 두고, 그 뒤에 모든 중간 CA 인증서를 순서대로 포함해야 합니다.
1. 새 설치를 위해 인증서 임포트
기본적으로 SUSE Multi-Linux Manager은(는) 자체 서명된 인증서를 사용합니다. 인증서는 설치 시점에 타사 인증서로 임포트할 수 있습니다.
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 string 서버와 다른 경우 데이터베이스의 루트 CA 인증서 경로 --ssl-db-cert string 데이터베이스 인증서 경로 --ssl-db-key string 데이터베이스 키 경로
중간 CA는 --ssl-ca-root로 지정한 파일에서 사용하거나 --ssl-ca-intermediate을 사용하여 추가 옵션으로 지정할 수 있습니다. --ssl-ca-intermediate 옵션은 여러 번 지정할 수 있습니다.
2. 새 프록시 설치를 위한 인증서 임포트
프록시 인증서는 생성된 구성에 포함되어 있습니다. 타사 인증서를 사용하려면 구성 절차 중에 해당 인증서를 제공해야 합니다.
SUSE Multi-Linux Manager 프록시 설치의 지침에 따라 SUSE Multi-Linux Manager 프록시를 설치합니다.
프롬프트를 따라 설정을 완료합니다.
동일한 인증 기관(CA)을 사용하여 서버 및 프록시에 대한 모든 서버 인증서에 서명합니다. 다른 CA로 서명된 인증서는 일치하지 않습니다.
3. 인증서 바꾸기
SUSE Multi-Linux Manager 설치의 활성 인증서를 새 인증서로 교체할 수 있습니다. 고려해야 할 두 가지 경우는 서버 또는 데이터베이스 인증서만 교체하는 경우와 루트 CA를 교체하는 경우입니다.
루트 인증서를 교체하려면 등록된 모든 프록시와 시스템이 서버 수준에서 새 CA로 전환하기 전에 데이터베이스에 새 CA를 적용해야 하므로 중단을 방지하기 위해 더 많은 시간과 계획이 필요합니다.
중간 CA가 서명한 타사 인증서를 사용할 경우, 중간 CA 인증서를 서버 또는 데이터베이스 인증서 파일에 추가해야 합니다.
순서가 중요합니다. 먼저 서버 인증서가 오고, 그런 다음 해당 인증서를 서명한 CA부터 루트 CA가 서명한 CA의 순서입니다. 루트 CA 인증서를 서버 인증서 파일에 추가해서는 안 됩니다.
다음에서는 사용자에게
root-ca.pem,intermediate-ca1.pem,intermediate-ca2.pem,server.pem및server.key파일이 있는 것으로 가정합니다. 이는 서버 인증서 서명 체인에 포함된 중간 CA의 수에 따라 다를 수 있습니다.중간 CA와 서버 인증서를 결합합니다. 순서가 중요하므로 서버가 먼저 오고 중간 CA의 순서여야 합니다. 루트 CA는
uyuni-ca및uyuni-db-ca시크릿에 별도로 전달되므로 체인의 마지막에 추가되지 않아야 합니다. 중간 CA가 없는 경우 다음 단계에서 결합된 파일 대신server.pem을 사용하면 됩니다.cat server.pem intermediate-ca1.pem intermediate-ca2.pem >combined-server.pemSUSE 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
컨테이너 호스트에서 서비스를 재시작하여 변경사항을 적용합니다.
mgradm restart
프록시를 사용하는 경우, 각 프록시의 호스트 이름과 cname을 사용하여 각 프록시에 대한 서버 인증서 RPM을 생성해야 합니다. 새로운 구성 tarball을 생성하고 배포합니다.
자세한 내용은 installation-and-upgrade:container-deployment/mlm/proxy-deployment-mlm.adoc#_generate_proxy_configuration을 참조하십시오.
루트 CA가 변경된 경우 SUSE Multi-Linux Manager에 연결된 모든 클라이언트에 배포해야 합니다. 이 작업은 미리 수행하는 것이 이상적이며, 이를 통해 혼란을 최소화할 수 있습니다.
|
CA 인증서가 업데이트된 경우, Kiwi 인증서가 포함된 RPM 파일을 다시 패키징해야 합니다. SUSE Multi-Linux Manager 서버 컨테이너 호스트에서 다음 명령을 실행합니다.
그런 다음, 이미지 빌드 호스트에 highstate를 적용하여 Kiwi가 사용할 새 인증서를 배포합니다. |
SUSE Multi-Linux Manager Web UI에서 로 이동합니다.
시스템 설정 관리자에 추가하려면 모든 클라이언트를 선택합니다.
으로 이동합니다.
상태필드에서 적용을 클릭하여 시스템 상태를 적용합니다.
Highstate페이지에서 Highstate 적용을 클릭하여 변경사항을 클라이언트에 전파합니다.