기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # AWS CloudHSM OpenSSL 공급자와 함께 NGINX 또는 HAProxy를 사용하여 Linux에서 SSL/TLS 오프로드 이 주제에서는 OpenSSL 공급자와 함께 NGINX 또는 HAProxy AWS CloudHSM 를 사용하여 Linux 웹 서버에서를 사용하여 SSL/TLS 서버 자격 증명 오프로드를 설정하는 step-by-step 지침을 제공합니다. **Topics** + [개요](#ssl-offload-linux-openssl-provider-overview) + [1단계: 사전 조건 설정](#ssl-offload-provider-prerequisites) + [2단계: 프라이빗 키 생성 또는 가져오기 및 인증서 가져오기](#ssl-offload-provider-generate-key-and-certificate) + [3단계: 웹 서버 구성하기](#ssl-offload-provider-configure-web-server) + [4단계: HTTPS 트래픽 활성화 및 인증서 확인하기](#ssl-offload-enable-traffic-and-verify-certificate-provider) ## 개요 Linux에서는 [NGINX](https://nginx.org/en/) 및 [HAProxy](https://www.haproxy.org/) 웹 서버 소프트웨어가 [OpenSSL](https://www.openssl.org/)과 통합되어 HTTPS를 지원합니다. [AWS CloudHSM OpenSSL 공급자는](openssl-provider-library.md) 웹 서버 소프트웨어가 암호화 오프로드 및 키 스토리지를 위해 클러스터의 HSMs을 사용할 수 있는 인터페이스를 제공합니다. OpenSSL 공급자는 웹 서버를 AWS CloudHSM 클러스터에 연결하는 브리지입니다. 이 자습서를 완료하려면 AWS CloudHSM OpenSSL 공급자를 사용하도록 NGINX 또는 HAProxy를 구성합니다. 이 자습서에서는 다음을 수행하는 방법을 보여줍니다. + Amazon EC2 인스턴스에 웹 서버 소프트웨어를 설치합니다. + AWS CloudHSM 클러스터에 프라이빗 키가 저장되는 HTTPS를 지원하도록 웹 서버 소프트웨어를 구성합니다. + (선택 사항) Amazon EC2를 사용하여 두 번째 웹 서버 인스턴스를 만들고 Elastic Load Balancing을 사용하여 로드 밸런서를 만듭니다. 로드 밸런서를 사용하면 여러 서버에 부하를 분산하여 성능을 향상할 수 있습니다. 또한 하나 이상의 서버에 장애가 발생할 경우 중복성과 더 높은 가용성을 제공할 수 있습니다. 시작할 준비가 되면 [1단계: 사전 조건 설정](#ssl-offload-provider-prerequisites)로 이동합니다. ## 1단계: 사전 조건 설정 플랫폼마다 필요한 필수 조건이 다릅니다. 플랫폼에 맞는 아래의 사전 조건 섹션을 사용하세요. ### AWS CloudHSM OpenSSL 공급자의 사전 조건 클라이언트 SDK 5용 AWS CloudHSM OpenSSL 공급자를 사용하여 웹 서버 SSL/TLS 서버 자격 증명 오프로드를 설정하려면 다음이 필요합니다. + 하드웨어 보안 모듈(HSM)이 2개 이상 있는 활성 AWS CloudHSM 클러스터 **참고** 단일 HSM 클러스터를 사용할 수 있지만 먼저 클라이언트 키 내구성을 비활성화해야 합니다. 자세한 내용은 [클라이언트 키 내구성 설정 관리](working-client-sync.md#client-sync-sdk8) 및 [클라이언트 SDK 5 구성](configure-sdk-5.md) 도구를 참조하세요. + 다음 소프트웨어가 설치된 Linux 운영 체제를 실행하는 Amazon EC2 인스턴스. + 웹 서버(NGINX 또는 HAProxy) + 클라이언트 SDK 5용 AWS CloudHSM OpenSSL 공급자 + HSM에서 웹 서버의 프라이빗 키를 소유하고 관리할 [CU(Crypto User)](understanding-users.md#crypto-user-chsm-cli)입니다. **HSM에서 Linux 웹 서버 인스턴스를 설정하고 CU를 생성하려면** **참고** 이 절차의 많은 명령에는 승격된 권한이 필요합니다. 시스템 구성에 따라 루트 사용자로 `sudo` 또는를 사용하여 명령을 실행해야 할 수 있습니다. 1. 클라이언트 SDK 5용 AWS CloudHSM OpenSSL 공급자를 설치하고 구성합니다. OpenSSL 공급자 설치에 대한 자세한 내용은 [AWS CloudHSM 클라이언트 SDK 5용 OpenSSL 공급자](openssl-provider-install.md)를 참조하세요. 1. 클러스터에 액세스할 수 있는 EC2 Linux 인스턴스에 NGINX 또는 HAProxy 웹 서버를 설치합니다. ------ #### [ Amazon Linux 2023 ] + NGINX ``` $ yum install nginx ``` + HAProxy ``` $ yum install haproxy ``` ------ #### [ RHEL 9 (9.2\+) ] + NGINX ``` $ yum install nginx ``` + HAProxy ``` $ yum install haproxy ``` ------ #### [ RHEL 10 (10.0\+) ] + NGINX ``` $ yum install nginx ``` + HAProxy ``` $ yum install haproxy ``` ------ #### [ Ubuntu 24.04 ] + NGINX ``` $ apt install nginx ``` + HAProxy ``` $ apt install haproxy ``` ------ 1. CloudHSM CLI를 사용하여 [Crypto User](understanding-users.md#crypto-user-chsm-cli)를 생성합니다. HSM 사용자 관리에 대한 자세한 내용은 [CloudHSM CLI를 사용한 HSM 사용자 관리](manage-hsm-users-chsm-cli.md)를 참조하십시오. **작은 정보** CU의 사용자 이름과 암호를 기록합니다. 나중에 웹 서버용 HTTPS 프라이빗 키와 인증서를 생성하거나 가져올 때 이 정보가 필요합니다. 이 단계들을 완료한 후 [2단계: 프라이빗 키 생성 또는 가져오기 및 인증서 가져오기](#ssl-offload-provider-generate-key-and-certificate)로 이동합니다. #### 참고 + 보안이 강화된 리눅스(SELinux) 및 웹 서버를 사용하려면 클라이언트 SDK 5가 HSM과 통신하는 데 사용하는 포트인 포트 2223에서 아웃바운드 TCP 연결을 허용해야 합니다. + 클러스터를 생성 및 활성화하고 EC2 인스턴스에 클러스터 액세스 권한을 부여하려면 [AWS CloudHSM시작하기](getting-started.md)의 단계를 완료하십시오. 시작하기에서는 HSM 1개와 Amazon EC2 클라이언트 인스턴스 1개로 활성 클러스터를 생성하는 방법에 대한 단계별 지침을 제공합니다. 이 클라이언트 인스턴스를 웹 서버로 사용할 수 있습니다. + 클라이언트 키 내구성을 비활성화하지 않으려면 클러스터에 HSM을 두 개 이상 추가하십시오. 자세한 내용은 [AWS CloudHSM 클러스터에 HSM 추가](add-hsm.md) 섹션을 참조하십시오. + SSH 또는 PuTTY를 사용하여 클라이언트 인스턴스에 연결할 수 있습니다. 자세한 정보는 Amazon EC2 설명서의 [SSH를 사용하여 Linux 인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html)과 [PuTTY를 사용하여 Windows에서 Linux 인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html) 단원을 참조하세요. ## 2단계: 프라이빗 키 생성 또는 가져오기 및 인증서 가져오기 HTTPS를 활성화하려면 웹 서버 애플리케이션(NGINX 또는 HAProxy)에 프라이빗 키와 해당 SSL/TLS 인증서가 필요합니다. 에서 웹 서버 SSL/TLS 서버 자격 증명 오프로드를 사용하려면 AWS CloudHSM 클러스터의 HSM에 프라이빗 키를 저장 AWS CloudHSM해야 합니다. 먼저 프라이빗 키를 생성한 후 해당 키를 사용하여 인증서 서명 요청(CSR)을 생성합니다. 그런 다음 HSM에서 *가짜 PEM 프라이빗 키*를 내보냅니다. 즉 HSM에 저장된 프라이빗 키에 대한 참조를 포함하는 PEM 형식의 프라이빗 키 파일입니다(실제 프라이빗 키가 아님). 웹 서버는 가짜 PEM 프라이빗 키 파일을 사용하여 SSL/TLS 서버 자격 증명 오프로드 중에 HSM의 프라이빗 키를 식별합니다. ### 프라이빗 키 생성 이 섹션에서는 [CloudHSM CLI](cloudhsm_cli.md)를 사용하여 키 페어를 생성하는 방법을 보여줍니다. HSM 내부에 키 페어가 생성되면 이를 가짜 PEM 파일로 내보내고 해당 인증서를 생성할 수 있습니다. **CloudHSM CLI 설치 및 구성** 1. CloudHSM CLI를 [설치 및 구성](cloudhsm_cli-getting-started.md)합니다. 1. 다음 명령을 사용하여 CloudHSM CLI를 시작합니다. ``` $ /opt/cloudhsm/bin/cloudhsm-cli interactive ``` 1. 다음 명령을 실행하여 HSM에 로그인합니다. {{}}을 Crypto User의 사용자 이름으로 변경 ``` aws-cloudhsm>login --username {{}} --role crypto-user ``` **프라이빗 키 생성** 사용 사례에 따라 RSA 또는 EC 키 페어를 생성할 수 있습니다. 다음 중 하나를 수행하십시오. + HSM에서 RSA 프라이빗 키를 생성하려면 [`key generate-asymmetric-pair rsa`](cloudhsm_cli-key-generate-asymmetric-pair-rsa.md) 명령을 사용하여 RSA 키 페어를 생성합니다. 이 예제에서는 모듈러스가 2048, 퍼블릭 지수가 65537, 퍼블릭 키 레이블이 {{tls\_rsa\_pub}}, 프라이빗 키 레이블이 {{tls\_rsa\_private}}인 RSA 키 페어를 생성합니다. ``` aws-cloudhsm > key generate-asymmetric-pair rsa \ --public-exponent 65537 \ --modulus-size-bits 2048 \ --public-label tls_rsa_pub \ --private-label tls_rsa_private \ --private-attributes sign=true { "error_code": 0, "data": { "public_key": { "key-reference": "0x0000000000280cc8", "key-info": { "key-owners": [ { "username": "cu1", "key-coverage": "full" } ], "shared-users": [], "cluster-coverage": "full" }, "attributes": { "key-type": "rsa", "label": "tls_rsa_pub", "id": "", "check-value": "0x01fe6e", "class": "public-key", "encrypt": true, "decrypt": false, "token": true, "always-sensitive": false, "derive": false, "destroyable": true, "extractable": true, "local": true, "modifiable": true, "never-extractable": false, "private": true, "sensitive": false, "sign": false, "trusted": false, "unwrap": false, "verify": false, "wrap": false, "wrap-with-trusted": false, "key-length-bytes": 512, "public-exponent": "0x010001", "modulus": "0xb1d27e857a876f4e9fd5de748a763c539b359f937eb4b4260e30d1435485a732c878cdad9c72538e2215351b1d41358c9bf80b599c73a80fdb457aa7b20cd61e486c326e2cfd5e124a7f6a996437437812b542e3caf85928aa866f0298580f7967ee6aa01440297d7308fdd9b76b70d1b67f12634df6e6296d6c116d5744c6d60d14d3bf3cb978fe6b75ac67b7089bafd50d8687213b31abc7dc1bad422780d29c851d5102b56f932551eaf52a9591fd8c43d81ecc133022653225bd129f8491101725e9ea33e1ded83fb57af35f847e532eb30cd7e726f23910d2671c6364092e834697ec3cef72cc23615a1ba7c5e100156ae0acac3160f0ca9725d38318b7", "modulus-size-bits": 2048 } }, "private_key": { "key-reference": "0x0000000000280cc7", "key-info": { "key-owners": [ { "username": "cu1", "key-coverage": "full" } ], "shared-users": [], "cluster-coverage": "full" }, "attributes": { "key-type": "rsa", "label": "tls_rsa_private", "id": "", "check-value": "0x01fe6e", "class": "private-key", "encrypt": false, "decrypt": true, "token": true, "always-sensitive": true, "derive": false, "destroyable": true, "extractable": true, "local": true, "modifiable": true, "never-extractable": false, "private": true, "sensitive": true, "sign": true, "trusted": false, "unwrap": false, "verify": false, "wrap": false, "wrap-with-trusted": false, "key-length-bytes": 1217, "public-exponent": "0x010001", "modulus": "0xb1d27e857a876f4e9fd5de748a763c539b359f937eb4b4260e30d1435485a732c878cdad9c72538e2215351b1d41358c9bf80b599c73a80fdb457aa7b20cd61e486c326e2cfd5e124a7f6a996437437812b542e3caf85928aa866f0298580f7967ee6aa01440297d7308fdd9b76b70d1b67f12634df6e6296d6c116d5744c6d60d14d3bf3cb978fe6b75ac67b7089bafd50d8687213b31abc7dc1bad422780d29c851d5102b56f932551eaf52a9591fd8c43d81ecc133022653225bd129f8491101725e9ea33e1ded83fb57af35f847e532eb30cd7e726f23910d2671c6364092e834697ec3cef72cc23615a1ba7c5e100156ae0acac3160f0ca9725d38318b7", "modulus-size-bits": 2048 } } } } ``` + HSM에서 EC 프라이빗 키를 생성하려면 [`key generate-asymmetric-pair ec`](cloudhsm_cli-key-generate-asymmetric-pair-ec.md) 명령을 사용하여 EC 키 페어를 생성합니다. 이 예제에서는 `prime256v1` 곡선(`NID_X9_62_prime256v1` 곡선에 해당)에 기반하여 퍼블릭 키 레이블이 {{tls\_ec\_pub}}, 프라이빗 키 레이블이 {{tls\_ec\_private}}인 EC 키 페어를 생성합니다. ``` aws-cloudhsm > key generate-asymmetric-pair ec \ --curve prime256v1 \ --public-label tls_ec_pub \ --private-label tls_ec_private \ --private-attributes sign=true { "error_code": 0, "data": { "public_key": { "key-reference": "0x000000000012000b", "key-info": { "key-owners": [ { "username": "cu1", "key-coverage": "full" } ], "shared-users": [], "cluster-coverage": "session" }, "attributes": { "key-type": "ec", "label": "tls_ec_pub", "id": "", "check-value": "0xd7c1a7", "class": "public-key", "encrypt": false, "decrypt": false, "token": false, "always-sensitive": false, "derive": false, "destroyable": true, "extractable": true, "local": true, "modifiable": true, "never-extractable": false, "private": true, "sensitive": false, "sign": false, "trusted": false, "unwrap": false, "verify": false, "wrap": false, "wrap-with-trusted": false, "key-length-bytes": 57, "ec-point": "0x047096513df542250a6b228fd9cb67fd0c903abc93488467681974d6f371083fce1d79da8ad1e9ede745fb9f38ac8622a1b3ebe9270556000c", "curve": "secp224r1" } }, "private_key": { "key-reference": "0x000000000012000c", "key-info": { "key-owners": [ { "username": "cu1", "key-coverage": "full" } ], "shared-users": [], "cluster-coverage": "session" }, "attributes": { "key-type": "ec", "label": "tls_ec_private", "id": "", "check-value": "0xd7c1a7", "class": "private-key", "encrypt": false, "decrypt": false, "token": false, "always-sensitive": true, "derive": false, "destroyable": true, "extractable": true, "local": true, "modifiable": true, "never-extractable": false, "private": true, "sensitive": true, "sign": true, "trusted": false, "unwrap": false, "verify": false, "wrap": false, "wrap-with-trusted": false, "key-length-bytes": 122, "ec-point": "0x047096513df542250a6b228fd9cb67fd0c903abc93488467681974d6f371083fce1d79da8ad1e9ede745fb9f38ac8622a1b3ebe9270556000c", "curve": "secp224r1" } } } } ``` **가짜 PEM 프라이빗 키 파일 내보내기** HSM에 프라이빗 키가 있으면 가짜 PEM 프라이빗 키 파일을 내보내야 합니다. 이 파일에은 실제 키 데이터가 포함하지 않지만 OpenSSL 동적 엔진이 HSM의 프라이빗 키를 식별할 수 있도록 해줍니다. 그런 다음 프라이빗 키를 사용하여 CSR(인증서 서명 요청)을 생성하고 CSR에 서명하여 인증서를 생성할 수 있습니다. [`key generate-file`](cloudhsm_cli-key-generate-file.md) 명령을 실행하여 가짜 PEM 형식의 프라이빗 키를 내보내고 파일에 저장합니다. 다음 값을 사용자의 값으로 대체합니다. + {{}} - 이전 단계에서 생성한 프라이빗 키의 레이블입니다. + {{}} - 가짜 PEM 키가 기록될 파일의 이름입니다. ``` aws-cloudhsm > key generate-file --encoding reference-pem --path {{}} --filter attr.label={{}} { "error_code": 0, "data": { "message": "Successfully generated key file" } } ``` **CloudHSM CLI 종료** 다음 명령을 실행하여 CloudHSM CLI를 종료합니다. ``` aws-cloudhsm > quit ``` 이제 이전 명령에서 {{}}로 지정된 경로에, 시스템에 새 파일이 있어야 합니다. 이 파일은 가짜 PEM 프라이빗 키 파일입니다. ### 자체 사인된 인증서를 생성합니다. 가짜 PEM 프라이빗 키를 생성한 후에는 이 파일을 사용하여 인증서 사인 요청(CSR) 및 인증서를 생성할 수 있습니다. 프로덕션 환경에서는 일반적으로 CA(인증 기관)을 사용하여 CSR에서 인증서를 생성합니다. 테스트 환경에는 CA가 필요하지 않습니다. CA를 사용하는 경우 CA에 CSR 파일을 보내고 CA가 웹 서버에서 HTTPS용으로 제공하는 서명된 SSL/TLS 인증서를 사용하세요. CA를 사용하는 대신 AWS CloudHSM OpenSSL Dynamic Engine을 사용하여 자체 서명된 인증서를 생성할 수 있습니다. 자체 사인된 인증서는 브라우저에서 신뢰하지 않으며 프로덕션 환경에서 사용해서는 안 됩니다. 테스트 환경에서는 이러한 인증서를 사용할 수 있습니다. **주의** 자체 사인된 인증서는 테스트 환경에서만 사용해야 합니다. 프로덕션 환경의 경우 인증 기관과 같은 추가 보안 방법을 사용하여 인증서를 생성하십시오. **OpenSSL Dynamic Engine 설치 및 구성** 1. 클라이언트 인스턴스에 연결합니다. 1. [AWS CloudHSM 클라이언트 SDK 5용 OpenSSL Dynamic Engine 설치](openssl5-install.md) **인증서 생성** 1. 이전 단계에서 생성한 가짜 PEM 파일의 사본을 확보하세요. 1. CSR 생성 다음 명령을 실행하여 AWS CloudHSM OpenSSL Dynamic Engine을 사용하여 인증서 서명 요청(CSR)을 생성합니다. {{}}를 가짜 PEM 프라이빗 키가 포함된 파일 이름으로 바꿉니다. {{}}을 CSR이 포함된 파일의 이름으로 바꿉니다. `req` 명령은 대화식입니다. 각 필드에 응답합니다. 필드 정보가 SSL/TLS 인증서에 복사됩니다. **참고** CSR 생성은 현재 OpenSSL 공급자에서 지원되지 않습니다. 이 단계에서는 OpenSSL 엔진을 사용해야 하지만 TLS 암호 작업은 공급자와 함께 작동합니다. ``` $ openssl req -engine cloudhsm -new -key {{}} -out {{}} ``` 1. 자체 서명된 인증서 생성 다음 명령을 실행하여 AWS CloudHSM OpenSSL Dynamic Engine을 사용하여 HSM의 프라이빗 키로 CSR에 서명합니다. 이렇게 하면 자체 사인된 인증서가 생성됩니다. 명령의 다음 값을 사용자의 값으로 바꿉니다. + {{}} – CSR이 포함된 파일 이름 + {{}} – 가짜 PEM 프라이빗 키가 포함된 파일 이름 + {{}} – 웹 서버 인증서가 포함될 파일 이름 ``` $ openssl x509 -engine cloudhsm -req -days 365 -in {{}} -signkey {{}} -out {{}} ``` 프라이빗 키와 인증서가 있으면 로 이동합니다[3단계: 웹 서버 구성하기](#ssl-offload-provider-configure-web-server). ## 3단계: 웹 서버 구성하기 [이전 단계](#ssl-offload-provider-generate-key-and-certificate)에서 생성한 HTTPS 인증서와 이에 해당되는 가짜 PEM 프라이빗 키를 사용하려면 웹 서버 소프트웨어의 구성을 업데이트하십시오. 시작하기 전에 기존 인증서와 키를 백업해야 한다는 점을 잊지 마십시오. 그러면 SSL/TLS 서버 자격 증명 오프로드를 위한 Linux 웹 서버 소프트웨어 설정이 완료됩니다 AWS CloudHSM. 다음 섹션 중 하나에 있는 단계를 완료합니다. **Topics** + [NGINX 웹 서버를 구성합니다](#ssl-offload-provider-configure-nginx) + [HAProxy 웹 서버 구성](#ssl-offload-provider-configure-haproxy) ### NGINX 웹 서버를 구성합니다 이 섹션을 사용하여 OpenSSL 공급자로 NGINX를 구성합니다. **OpenSSL Provider용 NGINX를 구성하려면** 1. 클라이언트 인스턴스에 연결합니다. 1. 다음 명령을 실행하여 웹 서버 인증서 및 가짜 PEM 프라이빗 키에 필요한 디렉터리를 생성합니다. ``` $ mkdir -p /etc/pki/nginx/private ``` 1. 다음 명령을 실행하여 웹 서버 인증서를 필요한 위치에 복사합니다. {{}}를 웹 서버 인증서 이름으로 바꿉니다. ``` $ cp {{}} /etc/pki/nginx/server.crt ``` 1. 다음 명령을 실행하여 가짜 PEM 프라이빗 키를 필요한 위치에 복사합니다. {{}}를 가짜 PEM 프라이빗 키가 포함된 파일 이름으로 바꿉니다. ``` $ cp {{}} /etc/pki/nginx/private/server.key ``` 1. 다음 명령을 실행하여 *nginx*라는 이름의 사용자가 파일을 읽을 수 있도록 파일 소유권을 변경합니다. ``` $ chown nginx /etc/pki/nginx/server.crt /etc/pki/nginx/private/server.key ``` 1. AWS CloudHSM 공급자를 사용하도록 OpenSSL을 구성합니다. OpenSSL 공급자 구성에 대한 자세한 내용은 [AWS CloudHSM 클라이언트 SDK 5용 OpenSSL 공급자](openssl-provider-install.md)를 참조하세요. 1. OpenSSL 구성 파일을 찾습니다. ``` $ openssl version -d ``` 다음과 비슷한 출력이 표시되어야 합니다. ``` OPENSSLDIR: "/etc/pki/tls" ``` 구성 파일은이 디렉터리`openssl.cnf`에 있습니다. 1. **참고** 시스템의 기본 openssl.cnf 파일을 직접 수정하지 마십시오. 이렇게 하면 시스템 전체의 OpenSSL 작업(SSH, TLS 연결 및 기타 서비스)이 의도치 않게 CloudHSM 공급자를 통해 라우팅되는 것을 방지할 수 있습니다. 별도의 구성 파일을 사용하면 HSM 지원 암호화 작업이 필요한 특정 애플리케이션으로만 CloudHSM 공급자 사용량의 범위를 지정할 수 있습니다. 다음 내용이 포함된 새 OpenSSL 구성 파일을 생성합니다. ``` $ cat > {{}} << 'EOF' ## NOTE: This should point to the system default openssl config file. # Replace /etc/pki/tls with the path to your OpenSSL configuration directory .include {{}}/openssl.cnf # Override the existing provider_section to include AWS CloudHSM OpenSSL Provider as a 3rd party OpenSSL provider [provider_sect] default = default_sect # Include AWS CloudHSM CloudHSM OpenSSL provider cloudhsm = cloudhsm_sect [default_sect] activate = 1 [cloudhsm_sect] activate = 1 EOF ``` 1. `CLOUDHSM_PIN` 환경 변수가 CU(Crypto User) 자격 증명으로 설정되어 있는지 확인합니다. ``` $ export CLOUDHSM_PIN={{}}:{{}} ``` 1. 업데이트된 구성 파일을 가리키도록 `OPENSSL_CONF` 환경 변수를 설정하고 공급자가 로드되었는지 확인합니다. ``` $ OPENSSL_CONF=/path/to/example-cloudhsm-openssl.cnf openssl list -providers ``` 기본 공급자와 CloudHSM 공급자가 모두 나열되어야 합니다. ``` OPENSSL_CONF=/path/to/example-cloudhsm-openssl.cnf openssl list -providers Providers: default name: OpenSSL Default Provider version: 3.2.2 status: active cloudhsm name: AWS CloudHSM OpenSSL Provider version: 5.17.0 status: active ``` 1. 다음 명령을 실행하여 `/etc/nginx/nginx.conf` 파일을 백업합니다. ``` $ cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup ``` 1. NGINX 구성을 업데이트합니다. **참고** 각 클러스터는 모든 NGINX 웹 서버에서 최대 1000개의 NGINX 작업자 프로세스를 지원할 수 있습니다. ------ #### [ Amazon Linux 2023 ] 텍스트 편집기를 사용하여 `/etc/nginx/nginx.conf` 파일을 편집합니다. 여기에는 Linux 루트 권한이 필요할 수 있습니다. 파일의 맨 위에 다음 행을 추가합니다. ``` env CLOUDHSM_PIN; env OPENSSL_CONF; ``` 그런 다음 파일의 TLS 섹션에 다음을 추가합니다. ``` # Settings for a TLS enabled server. server { listen 443 ssl http2 default_server; listen [::]:443 ssl http2 default_server; server_name _; root /usr/share/nginx/html; ssl_certificate "/etc/pki/nginx/server.crt"; ssl_certificate_key "/etc/pki/nginx/private/server.key"; # It is *strongly* recommended to generate unique DH parameters for DHE ciphers # Generate them with: openssl dhparam -out /etc/pki/nginx/dhparams.pem 2048 # ssl_dhparam "/etc/pki/nginx/dhparams.pem"; ssl_session_cache shared:SSL:1m; ssl_session_timeout 10m; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"; ssl_prefer_server_ciphers off; # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; location / { } error_page 404 /404.html; location = /40x.html { } error_page 500 502 503 504 /50x.html; location = /50x.html { } } ``` ------ #### [ RHEL 9 (9.2\+) ] 텍스트 편집기를 사용하여 `/etc/nginx/nginx.conf` 파일을 편집합니다. 여기에는 Linux 루트 권한이 필요할 수 있습니다. 파일의 맨 위에 다음 행을 추가합니다. ``` env CLOUDHSM_PIN; env OPENSSL_CONF; ``` 그런 다음 파일의 TLS 섹션에 다음을 추가합니다. ``` # Settings for a TLS enabled server. server { listen 443 ssl http2 default_server; listen [::]:443 ssl http2 default_server; server_name _; root /usr/share/nginx/html; ssl_certificate "/etc/pki/nginx/server.crt"; ssl_certificate_key "/etc/pki/nginx/private/server.key"; # It is *strongly* recommended to generate unique DH parameters for DHE ciphers # Generate them with: openssl dhparam -out /etc/pki/nginx/dhparams.pem 2048 # ssl_dhparam "/etc/pki/nginx/dhparams.pem"; ssl_session_cache shared:SSL:1m; ssl_session_timeout 10m; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"; ssl_prefer_server_ciphers off; # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; location / { } error_page 404 /404.html; location = /40x.html { } error_page 500 502 503 504 /50x.html; location = /50x.html { } } ``` ------ #### [ RHEL 10 (10.0\+) ] 텍스트 편집기를 사용하여 `/etc/nginx/nginx.conf` 파일을 편집합니다. 여기에는 Linux 루트 권한이 필요할 수 있습니다. 파일의 맨 위에 다음 행을 추가합니다. ``` env CLOUDHSM_PIN; env OPENSSL_CONF; ``` 그런 다음 파일의 TLS 섹션에 다음을 추가합니다. ``` # Settings for a TLS enabled server. server { listen 443 ssl http2 default_server; listen [::]:443 ssl http2 default_server; server_name _; root /usr/share/nginx/html; ssl_certificate "/etc/pki/nginx/server.crt"; ssl_certificate_key "/etc/pki/nginx/private/server.key"; # It is *strongly* recommended to generate unique DH parameters for DHE ciphers # Generate them with: openssl dhparam -out /etc/pki/nginx/dhparams.pem 2048 # ssl_dhparam "/etc/pki/nginx/dhparams.pem"; ssl_session_cache shared:SSL:1m; ssl_session_timeout 10m; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"; ssl_prefer_server_ciphers off; # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; location / { } error_page 404 /404.html; location = /40x.html { } error_page 500 502 503 504 /50x.html; location = /50x.html { } } ``` ------ #### [ Ubuntu 24.04 ] 텍스트 편집기를 사용하여 `/etc/nginx/nginx.conf` 파일을 편집합니다. 여기에는 Linux 루트 권한이 필요할 수 있습니다. 파일의 맨 위에 다음 행을 추가합니다. ``` env CLOUDHSM_PIN; env OPENSSL_CONF; ``` 그런 다음 파일의 TLS 섹션에 다음을 추가합니다. ``` # Settings for a TLS enabled server. server { listen 443 ssl http2 default_server; listen [::]:443 ssl http2 default_server; server_name _; root /var/www/html; ssl_certificate "/etc/ssl/certs/server.crt"; ssl_certificate_key "/etc/ssl/private/server.key"; # It is *strongly* recommended to generate unique DH parameters for DHE ciphers # Generate them with: openssl dhparam -out /etc/ssl/certs/dhparams.pem 2048 # ssl_dhparam "/etc/ssl/certs/dhparams.pem"; ssl_session_cache shared:SSL:1m; ssl_session_timeout 10m; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"; ssl_prefer_server_ciphers off; # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; location / { } error_page 404 /404.html; location = /40x.html { } error_page 500 502 503 504 /50x.html; location = /50x.html { } } ``` ------ 파일을 저장합니다. 1. `systemd` 구성 파일을 백업한 후, `EnvironmentFile` 경로를 설정합니다. ------ #### [ Amazon Linux 2023 ] 1. `nginx.service` 파일을 백업합니다. ``` $ cp /lib/systemd/system/nginx.service /lib/systemd/system/nginx.service.backup ``` 1. 텍스트 편집기에서 `/lib/systemd/system/nginx.service`을 엽니다. [서비스] 섹션에서 다음을 추가합니다. ``` EnvironmentFile=/etc/sysconfig/nginx ``` ------ #### [ RHEL 9 (9.2\+) ] 1. `nginx.service` 파일을 백업합니다. ``` $ cp /lib/systemd/system/nginx.service /lib/systemd/system/nginx.service.backup ``` 1. 텍스트 편집기에서 `/lib/systemd/system/nginx.service`을 엽니다. [서비스] 섹션에서 다음을 추가합니다. ``` EnvironmentFile=/etc/sysconfig/nginx ``` ------ #### [ RHEL 10 (10.0\+) ] 1. `nginx.service` 파일을 백업합니다. ``` $ cp /lib/systemd/system/nginx.service /lib/systemd/system/nginx.service.backup ``` 1. 텍스트 편집기에서 `/lib/systemd/system/nginx.service`을 엽니다. [서비스] 섹션에서 다음을 추가합니다. ``` EnvironmentFile=/etc/sysconfig/nginx ``` ------ #### [ Ubuntu 24.04 ] 1. `nginx.service` 파일을 백업합니다. ``` $ cp /lib/systemd/system/nginx.service /lib/systemd/system/nginx.service.backup ``` 1. 텍스트 편집기에서 `/lib/systemd/system/nginx.service`을 엽니다. [서비스] 섹션에서 다음을 추가합니다. ``` EnvironmentFile=/etc/sysconfig/nginx ``` ------ 1. `/etc/sysconfig/nginx` 파일이 있는지 여부를 확인한 후, 다음 중 하나를 수행합니다. + 파일이 있는 경우 다음 명령을 실행하여 파일을 백업합니다. ``` $ cp /etc/sysconfig/nginx /etc/sysconfig/nginx.backup ``` + 파일이 없는 경우 텍스트 편집기를 연 후 `/etc/sysconfig/` 폴더에 `nginx`라는 파일을 생성합니다. 1. NGINX 환경을 구성합니다. ------ #### [ Amazon Linux 2023 ] Linux 루트 사용자는 텍스트 편집기에서 `/etc/sysconfig/nginx` 파일을 엽니다. 예: ``` vi /etc/sysconfig/nginx ``` CU(Cryptography User) 자격 증명과 OpenSSL 구성 파일의 경로를 추가합니다. ``` CLOUDHSM_PIN={{}}:{{}} OPENSSL_CONF={{}} ``` {{}} 및 {{<암호>}}를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다. {{}}를에서 생성한 구성 파일의 전체 경로로 바꿉니다[OpenSSL Provider용 NGINX를 구성하려면](#configure-nginx-provider). 파일을 저장합니다. ------ #### [ RHEL 9 (9.2\+) ] 텍스트 편집기에서 `/etc/sysconfig/nginx` 파일을 엽니다. 여기에는 Linux 루트 권한이 필요할 수 있습니다. CU(Cryptography User) 자격 증명과 OpenSSL 구성 파일의 경로를 추가합니다. ``` CLOUDHSM_PIN={{}}:{{}} OPENSSL_CONF={{}} ``` {{}} 및 {{<암호>}}를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다. {{}}를에서 생성한 구성 파일의 전체 경로로 바꿉니다[OpenSSL Provider용 NGINX를 구성하려면](#configure-nginx-provider). 파일을 저장합니다. ------ #### [ RHEL 10 (10.0\+) ] 텍스트 편집기에서 `/etc/sysconfig/nginx` 파일을 엽니다. 여기에는 Linux 루트 권한이 필요할 수 있습니다. CU(Cryptography User) 자격 증명과 OpenSSL 구성 파일의 경로를 추가합니다. ``` CLOUDHSM_PIN={{}}:{{}} OPENSSL_CONF={{}} ``` {{}} 및 {{<암호>}}를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다. {{}}를에서 생성한 구성 파일의 전체 경로로 바꿉니다[OpenSSL Provider용 NGINX를 구성하려면](#configure-nginx-provider). 파일을 저장합니다. ------ #### [ Ubuntu 24.04 ] 텍스트 편집기에서 `/etc/sysconfig/nginx` 파일을 엽니다. 여기에는 Linux 루트 권한이 필요할 수 있습니다. CU(Cryptography User) 자격 증명과 OpenSSL 구성 파일의 경로를 추가합니다. ``` CLOUDHSM_PIN={{}}:{{}} OPENSSL_CONF={{}} ``` {{}} 및 {{<암호>}}를 암호화 사용자(Cryptography User) 자격 증명으로 바꿉니다. {{}}를에서 생성한 구성 파일의 전체 경로로 바꿉니다[OpenSSL Provider용 NGINX를 구성하려면](#configure-nginx-provider). 파일을 저장합니다. ------ 1. NGINX 웹 서버를 시작합니다. ------ #### [ Amazon Linux 2023 ] 모든 NGINX 프로세스 중지 ``` $ systemctl stop nginx ``` `systemd` 구성을 다시 로드하여 최신 변경 사항 찾아내기 ``` $ systemctl daemon-reload ``` NGINX 시작 ``` $ systemctl start nginx ``` ------ #### [ RHEL 9 (9.2\+) ] 실행 중인 NGINX 프로세스를 모두 중지하기 ``` $ systemctl stop nginx ``` `systemd` 구성을 다시 로드하여 최신 변경 사항 찾아내기 ``` $ systemctl daemon-reload ``` NGINX 프로세스 시작하기 ``` $ systemctl start nginx ``` ------ #### [ RHEL 10 (10.0\+) ] 실행 중인 NGINX 프로세스를 모두 중지하기 ``` $ systemctl stop nginx ``` `systemd` 구성을 다시 로드하여 최신 변경 사항 찾아내기 ``` $ systemctl daemon-reload ``` NGINX 프로세스 시작하기 ``` $ systemctl start nginx ``` ------ #### [ Ubuntu 24.04 ] 실행 중인 NGINX 프로세스를 모두 중지하기 ``` $ systemctl stop nginx ``` `systemd` 구성을 다시 로드하여 최신 변경 사항 찾아내기 ``` $ systemctl daemon-reload ``` NGINX 프로세스 시작하기 ``` $ systemctl start nginx ``` ------ NGINX를 구성한 후 로 이동합니다[HTTPS가 사용자가 구성한 인증서를 사용하는지 확인](#ssl-offload-verify-https-connection-linux). ### HAProxy 웹 서버 구성 이 섹션을 사용하여 OpenSSL 공급자로 HAProxy를 구성합니다. 다음 예제에서는 CloudHSM 인증서 및 키를 사용하여 HAProxy를 설정하는 방법을 보여줍니다. **OpenSSL 공급자용 HAProxy를 구성하려면** 1. 기존 통합 인증서 파일이 있는 경우 백업합니다. ``` $ cp server-combined.pem server-combined.pem.backup ``` 1. 인증서와 CloudHSM 가짜 PEM 키를 사용하여 HAProxy에 대한 결합된 인증서 파일을 생성합니다. ``` $ cat server.crt server.key > server-combined.pem ``` 1. 기존 HAProxy 구성을 백업합니다. ``` $ cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.backup ``` 1. 에서 새 CloudHSM TLS 오프로드 구성을 생성합니다`/etc/haproxy/haproxy.cfg`. ``` global daemon ssl-provider cloudhsm # It is *strongly* recommended to generate unique DH parameters # Generate them with: openssl dhparam -out /etc/haproxy/dhparams.pem 2048 # ssl-dh-param-file /etc/haproxy/dhparams.pem ssl-default-bind-ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305 ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets defaults mode http timeout connect 5000ms timeout client 50000ms timeout server 50000ms frontend haproxy_frontend bind *:443 ssl crt /path/to/server-combined.pem default_backend web_servers backend web_servers server web1 127.0.0.1:8080 check ``` 파일 위치와 일치하도록 인증서 경로를 업데이트합니다. 1. HAProxy용 환경 파일을 사용하도록 systemd를 구성합니다. 위치는 Linux 배포판에 따라 다릅니다. ------ #### [ Amazon Linux and RHEL ] HAProxy 서비스 파일을 백업하고 수정합니다. ``` $ cp /lib/systemd/system/haproxy.service /lib/systemd/system/haproxy.service.backup ``` [서비스] 섹션 아래에 다음 줄을 편집`/lib/systemd/system/haproxy.service`하고 추가합니다. ``` EnvironmentFile=/etc/sysconfig/haproxy ``` ------ #### [ Ubuntu ] HAProxy 서비스 파일을 백업하고 수정합니다. ``` $ cp /lib/systemd/system/haproxy.service /lib/systemd/system/haproxy.service.backup ``` [서비스] 섹션 아래에 다음 줄을 편집`/lib/systemd/system/haproxy.service`하고 추가합니다. ``` EnvironmentFile=/etc/default/haproxy ``` ------ 1. 시스템에 적합한 위치에 환경 파일을 생성합니다. ------ #### [ Amazon Linux and RHEL ] HAProxy 환경 파일이 있는 경우 백업합니다. ``` $ cp /etc/sysconfig/haproxy /etc/sysconfig/haproxy.backup ``` 다음 내용을 `/etc/sysconfig/haproxy` 사용하여 HAProxy 환경 파일을 생성합니다. ``` CLOUDHSM_PIN={{}}:{{}} ``` ------ #### [ Ubuntu ] HAProxy 환경 파일이 있는 경우 백업합니다. ``` $ cp /etc/default/haproxy /etc/default/haproxy.backup ``` 다음 내용을 `/etc/default/haproxy` 사용하여 HAProxy 환경 파일을 생성합니다. ``` CLOUDHSM_PIN={{}}:{{}} ``` ------ {{}} 및 {{<암호>}}를 CU 자격 증명으로 바꿉니다. 1. 시스템 구성 다시 로드: ``` $ systemctl daemon-reload ``` 1. CloudHSM TLS 오프로드 구성으로 HAProxy를 시작합니다. ``` $ systemctl start haproxy ``` 사용자 지정 구성 파일을 사용하여 HAProxy를 직접 실행할 수도 있습니다. ``` $ haproxy -f /path/to/haproxy-cloudhsm.cfg ``` HAProxy를 구성한 후 로 이동합니다[HTTPS가 사용자가 구성한 인증서를 사용하는지 확인](#ssl-offload-verify-https-connection-linux). ## 4단계: HTTPS 트래픽 활성화 및 인증서 확인하기 를 사용하여 SSL/TLS 오프로드를 위해 웹 서버를 구성한 후 인바운드 HTTPS 트래픽을 허용하는 보안 그룹에 웹 서버 인스턴스를 AWS CloudHSM추가합니다. 이렇게 하면 웹 브라우저와 같은 클라이언트가 웹 서버와 HTTPS 연결을 설정할 수 있습니다. 그런 다음 웹 서버에 HTTPS를 연결하고 SSL/TLS 오프로드에 대해 구성한 인증서를 사용하고 있는지 확인합니다 AWS CloudHSM. **Topics** + [인바운드 HTTPS 연결 활성화](#ssl-offload-add-security-group-linux) + [HTTPS가 사용자가 구성한 인증서를 사용하는지 확인](#ssl-offload-verify-https-connection-linux) ### 인바운드 HTTPS 연결 활성화 클라이언트(예: 웹 서버)에서 웹 서버에 연결하려면 인바운드 HTTPS 연결을 허용하는 보안 그룹을 생성합니다. 구체적으로 포트 443에서 인바운드 TCP 연결을 허용해야 합니다. 이 보안 그룹을 웹 서버에 할당합니다. **HTTPS용 보안 그룹을 생성하여 웹 서버에 할당하려면** 1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다. 1. 탐색 창에서 **보안 그룹**을 선택합니다. 1. **보안 그룹 생성**을 선택합니다. 1. **보안 그룹 생성**에서 다음을 수행합니다. 1. **보안 그룹 이름**에 생성하려는 보안 그룹의 이름을 입력합니다. 1. (선택 사항) 생성하려는 보안 그룹에 대한 설명을 입력합니다. 1. 웹 서버 Amazon EC2 인스턴스가 포함된 VPC를 **VPC**로 선택합니다. 1. **규칙 추가**를 선택합니다. 1. 드롭다운 창에서 **HTTPS**를 **유형**으로 선택합니다. 1. **소스**에 소스 위치를 입력합니다. 1. **보안 그룹 생성**을 선택합니다. 1. 탐색 창에서 **인스턴스(Instances)**를 선택합니다. 1. 웹 서버 인스턴스 옆에 있는 확인란을 선택합니다. 1. 페이지 상단의 **작업** 드롭다운 메뉴를 선택합니다. **보안**을 선택한 다음 **보안 그룹 변경**을 선택합니다. 1. **연결된 보안 그룹**에서 검색 상자를 선택하고 HTTPS용으로 생성한 보안 그룹을 선택합니다. 그런 다음 **보안 그룹 추가**를 선택합니다. 1. **저장**을 선택합니다. ### HTTPS가 사용자가 구성한 인증서를 사용하는지 확인 웹 서버를 보안 그룹에 추가한 후 SSL/TLS 오프로드가 자체 서명 인증서를 사용하고 있는지 확인할 수 있습니다. 웹 브라우저 또는 [OpenSSL s\_client](https://www.openssl.org/docs/manmaster/man1/s_client.html)와 같은 도구를 사용하여 이 작업을 수행할 수 있습니다. **웹 브라우저를 사용하여 SSL/TLS 오프로드를 확인하려면** 1. 웹 브라우저를 사용하여 서버의 퍼블릭 DNS 이름 또는 IP 주소를 사용해 웹 서버에 연결합니다. 주소 표시줄의 URL이 https://로 시작하는지 확인합니다. 예를 들어 **https://ec2-52-14-212-67.us-east-2.compute.amazonaws.com/**입니다. **작은 정보** Amazon Route 53과 같은 DNS 서비스를 사용하여 웹사이트의 도메인 이름(예: https://www.example.com/)을 웹 서버로 라우팅할 수 있습니다. 자세한 내용은 *Amazon Route 53 개발자 안내서* 또는 DNS 서비스 설명서의 [Amazon EC2 인스턴스로 트래픽 라우팅](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-ec2-instance.html)을 참조하십시오. 1. 웹 브라우저를 사용하여 웹 서버 인증서를 봅니다. 자세한 내용은 다음을 참조하십시오. + Mozilla Firefox의 경우 Mozilla Support 웹 사이트의 [View a Certificate(인증서 보기)](https://support.mozilla.org/en-US/kb/secure-website-certificate#w_view-a-certificate)를 참조하십시오. + Google Chrome의 경우 Google Tools for Web Developers 웹 사이트의 [보안 문제 이해](https://developers.google.com/web/tools/chrome-devtools/security)를 참조하십시오. 다른 웹 브라우저에도 웹 서버 인증서를 보는 데 사용할 수 있는 유사한 기능이 있을 수 있습니다. 1. SSL/TLS 인증서가 웹 서버에서 사용하도록 구성한 것인지 확인합니다. **OpenSSL s\_client를 사용하여 SSL/TLS 오프로드를 확인하려면** 1. 다음 OpenSSL 명령을 실행하여 HTTPS를 사용해 웹 서버에 연결합니다. {{}}을 웹 서버의 퍼블릭 DNS 이름 또는 IP 주소로 바꿉니다. ``` openssl s_client -connect {{}}:443 ``` **작은 정보** Amazon Route 53과 같은 DNS 서비스를 사용하여 웹사이트의 도메인 이름(예: https://www.example.com/)을 웹 서버로 라우팅할 수 있습니다. 자세한 내용은 *Amazon Route 53 개발자 안내서* 또는 DNS 서비스 설명서에서 [Amazon EC2 인스턴스로의 라우팅 트래픽](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-ec2-instance.html)을 참조하십시오. 1. SSL/TLS 인증서가 웹 서버에서 사용하도록 구성한 것인지 확인합니다. 이제 웹 사이트가 HTTPS로 보안됩니다. 웹 서버의 프라이빗 키는 AWS CloudHSM 클러스터의 HSM에 저장됩니다. 로드 밸런서를 추가하려면 [Elastic Load Balancing을 사용하여 로드 밸런서 추가 AWS CloudHSM(선택 사항)](third-offload-add-lb.md) 섹션을 참조하십시오.