wget https://example.com/test.txt

그랬더니 다음과 같이 에러가 발생하게 됩니다.

--2020-08-10 05:09:01--  https://example.com/test.txt
Resolving example.com (example.com)... 93.184.216.34
Connecting to example.com (example.com)|93.184.216.34|:443... connected.
ERROR: The certificate of ‘example.com’ is not trusted.
ERROR: The certificate of ‘example.com’ has expired.

이는 https 프로토콜로 접속 시 해당 웹 서버의 인증서가 만료되었거나 보안상의 이슈로 인해 신뢰되지 않은 인증서로 표시되어 발생하는 문제입니다.

해결 방법

이 문제는 다음과 같이 해결할 수 있습니다.

먼저 해당 도메인 접속 시 정말로 문제가 없는지 확인합니다. (인증서가 만료되었거나 신뢰하지 못한 경우) 이상이 없다고 판단될 경우 다음 명령어를 사용하여 인증서 확인을 건너뛸 수 있습니다.

wget https://example.com/test.txt --no-check-certificate

위와 같이 --no-check-certificate 옵션을 붙여서 시도하면 아래와 같이 경고를 표시하지만 중단하지 않고 다운로드를 진행하게 됩니다.

--2020-08-10 05:10:27--  https://example.com/test.txt
Resolving example.com (example.com)... 93.184.216.34
Connecting to example.com (example.com)|93.184.216.34|:443... connected.
WARNING: The certificate of ‘example.com’ is not trusted.
WARNING: The certificate of ‘example.com’ has expired.
HTTP request sent, awaiting response... 200 OK
Length: 28100 (27K) [text/plain]
Saving to: ‘test.txt’

test.txt. 100%[==================================>]  27.80K   103KB/s    in 0.3s    

2020-08-10 05:10:28 (103 KB/s) - ‘test.txt’ saved [28100/28100]

The post ERROR: The certificate of ‘example.com’ is not trusted. 해결 appeared first on JooTC.

일반적으로 SSL 인증서는 취급하는 기관에서 유료 인증서를 구매하여 직접 설치하거나, 호스팅 서비스에서 제공하는 설치 서비스를 사용합니다. 무료 인증서(Let’s Encrypt)를 사용하여 설치할 수도 있는데 이와 관련해서는 아래 포스트를 참고해보시기 바랍니다.

여기서는 Amazon Web Services (이하 AWS)에서 제공하는 SSL 인증서 서비스인 ACM(Amazon Certificate Manager)을 사용하여 인증서를 발급하고, EC2와 같은 서비스에 적용해보도록 하겠습니다.

ACM 인증서 발급받기

ACM 인증서는 아마존 웹 서비스의 각종 서비스를 연동해 사용할 경우 무료로 발급 받을 수 있습니다. 인증서 발급 시 유의해야 할 점은 ACM 인증서는 EC2 인스턴스가 위치한 리전과 동일한 리전이어야 한다는 것입니다. EC2에 적용하기 위해서 다른 리전의 ACM 인증서 리스트를 불러올 수 없기 때문에 주의해야 합니다.

AWS의 CDN 서비스인 CloudFront를 사용했었다면, CloudFront용 ACM 인증서가 버지니아 북부에서만 발급 및 사용할 수 있기 때문에 이미 같은 도메인의 인증서가 버지니아 북부 리전에 발급되었을 수 있습니다. 그러나 이와는 별개로 다른 리전에 동일한 도메인에 대한 ACM 인증서를 추가로 발급할 수 있으므로 CloudFront로 인해 생성된 인증서를 무시하고 EC2 인스턴스 리전과 같은 리전에서 다시 발급받아야 합니다.

이제 본격적으로 인증서를 발급해보겠습니다. AWS 메뉴상에서 ‘Certificate Manager’를 검색하거나 직접 찾아서 클릭합니다.

Certificate Manager 메인 페이지에 들어왔다면 인증서 프로비저닝 항목에 있는 ‘시작하기’ 버튼을 눌러줍니다.

그러면 인증서 요청 페이지가 나타날 것입니다. 여기서 ‘공인 인증서 요청’을 선택한 후 하단의 ‘인증서 요청’ 버튼을 클릭합니다.

다음으로 도메인 이름 추가 페이지가 나타납니다. 여기서 인증서가 필요한 도메인을 입력해주어야 합니다. 일반적으로 example.com의 도메인이라면 www.example.com과 같이 www를 붙여서 기입해줍니다.

만약 여러 서브 도메인에 대한 인증서가 필요한 경우 하단의 ‘이 인증서에 다른 이름 추가’를 클릭하여 진행해주시면 됩니다. 서브 도메인이 많아질 것을 고려해서 와일드카드(*)를 사용한 도메인 인증서 또한 만들 수 있습니다. *.example.com과 같이 입력하면 이후에 인증서를 추가 발급받지 않고 모든 서브 도메인을 하나의 인증서로 처리할 수 있습니다. 단 와일드 카드 인증서를 사용할 때에는 기존 도메인인 example.com을 추가해야 합니다. (*.example.com과 example.com, 총 2개가 되겠죠.)

아래 사진의 예시에서는 현재 사이트 도메인을 입력했지만 실제로는 각자의 사이트 도메인을 입력해주셔야 합니다.

이제는 발급 받을 인증서 도메인이 자신이 소유하고 있는 도메인임을 인증해야 합니다. 검증 방법을 선택해야 하는데, 해당 도메인이 Route 53 서비스로 DNS를 관리하고 있다면 ‘DNS 검증’을 선택하는 것을 권장합니다. 그렇지만 DNS를 자신이 관리하지 못하거나 다른 DNS 서비스를 사용 중이라면 ‘이메일 검증’을 사용하셔야 합니다. 여기서는 DNS 검증으로 진행해보겠습니다.

다음으로 이 인증서에 대한 태그를 추가합니다. 이는 선택사항이며 아래는 Name 태그를 사용한 예시입니다. Name 태그는 인증서를 구분하기 쉽게 라벨을 부여하는 역할을 합니다. 모든 것이 완료되었다면 ‘검토’를 클릭합니다.

검토 페이지에서는 자신이 설정한 내용을 확인한 후 ‘확인 및 요청’을 클릭하면 됩니다.

마지막으로 방금 전 선택한 검증을 진행할 것입니다. DNS 검증의 경우 기존에 등록한 Route 53 호스트 영역에 그대로 아래의 CNAME만 추가하면 됩니다. 수동으로 추가하는 것도 가능하지만 하단의 ‘Route 53에서 레코드 생성’ 버튼을 클릭하면 자동으로 CNAME을 추가해 줄 것입니다. 이후 검증 상태가 ‘성공’이 되면 하단 버튼의 ‘계속’을 클릭합니다.

이제 ACM 인증서 발급이 완료되었습니다! 현재는 사용 중도 아니고 갱신도 불가능하다고 나타날 것입니다. (이후 사용 중인 상태가 되면 아래 상태는 자동으로 갱신됩니다.)

발급된 ACM 인증서를 EC2에 적용하기

이제 발급받은 ACM 인증서를 EC2 인스턴스에 로드 밸런싱 서비스(ELB)를 사용하여 적용해보도록 하겠습니다.

먼저 AWS EC2 대시보드 페이지로 이동하겠습니다. EC2 대시보드 페이지의 좌측 메뉴를 살펴보면 ‘로드 밸런싱’ 메뉴 그룹이 보일 것입니다. 여기에 ‘로드 밸런서’ 메뉴가 있을텐데 이를 클릭합니다.

로드 밸런서 페이지로 이동하였다면 상단 버튼의 ‘로드 밸런서 생성’을 클릭합니다.

로드 밸런서 유형은 아래와 같이 세가지가 있습니다.

• Application Load Balancer: 애플리케이션 계층에서 라우팅을 합니다. HTTP 및 HTTPS 트래픽에 대한 로드 밸런싱에 유리합니다. Layer 7에서 동작합니다.
• Network Load Balancer: TCP/UDP 트래픽을 중심으로 낮은 지연 시간을 가진 로드 밸런서입니다.
• Classic Load Balancer: AWS에서 가장 먼저 서비스된 기존 로드 밸런서입니다. 하나의 서버 주소를 가지며 Layer 4에서 동작합니다.

이 내용에 대해서는 아래 문서에 자세히 설명되어있습니다: https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/load-balancer-types.html

웹 서비스를 사용하는 경우 첫번째 선택지가 유리하므로 여기서는 Application Load Balancer를 선택하겠습니다.

이제 단계별 구성 내용 입력이 필요합니다. 여기서는 인스턴스 운영 상황에 따라 달라질 수 있으므로 반드시 이 과정 그대로 따라가기 전 검토해보시고 진행하시기 바랍니다.

먼저 구축할 로드 밸런서 이름을 자유롭게 입력하고 IP 주소 유형을 ipv4로 선택하겠습니다.

이후 리스너 그룹의 로드 밸런서 프로토콜을 HTTP 및 HTTPS 모두 추가해줍니다. HTTP는 처음에 추가되어 있기 때문에 하단의 리스너 추가 버튼을 클릭하여 HTTPS (보안 HTTP)를 선택하고 로드 밸런서 포트는 443으로 지정하여 HTTPS 프로토콜만 등록해줍니다.

다음은 가용 영역을 설정하는 화면입니다. 여기서 선택해야 하는 가용 영역 중 하나는 반드시 EC2 인스턴스에서 사용하는 VPC, 가용 영역의 서브넷과 일치해야 합니다. 적어도 두개 이상을 선택해야 하기 때문에 여기서는 EC2 인스턴스에서 사용하는 ap-northease-2c 영역을 포함한 ap-northeast-2a와 ap-northeast-2c를 선택하였습니다.

다음으로 보안 설정을 구성해야 합니다. 인증서 유형은 ‘ACM에서 인증서 선택 (권장)’을 선택한 후, 인증서 이름은 상단에서 만들었던 ACM 인증서를 찾아서 선택해줍니다. (없다면 우측 새로고침을 이용해보세요.) 보안 정책은 그대로 두어도 됩니다.

다음으로 보안 그룹을 구성할 수 있는 화면이 나오는데요, EC2 인스턴스를 설정할 때 만들었던 보안 그룹과 동일합니다. 새로 만들거나 기존의 보안 그룹을 선택해서 인바운드/아웃바운드 규칙을 설정합니다. 이 보안 그룹의 인바운드 규칙에서도 80/tcp 및 443/tcp 포트는 개방되어있어야 합니다.

다음으로 라우팅 구성 화면에서 아래와 같이 각 항목을 입력해줍니다. 여기서는 로드 밸런서가 EC2 인스턴스와 통신할 것이므로 대상 유형을 인스턴스로, HTTP(TCP 80번 포트) 통신 프로토콜로 선택합니다. 상태 검사는 필요에 따라 사용자 지정하거나, 그대로 둔 채 다음으로 넘어갑니다. (기본값으로 최상단 index 페이지에 대한 Health Check를 진행할 것입니다. Health Check에 대한 응답 코드가 20X가 아닌 경우 라우팅이 원활하지 못할 수 있습니다. 이럴 때는 Health Check가 가능한 URL 경로와 프로토콜을 입력해야 할 수 있습니다.)

마지막 대상 등록 화면에서는 로드 밸런싱을 수행할 인스턴스를 지정합니다. 이 도메인과 관련된 인스턴스만 찾아서 하나 이상 선택해줍니다. 선택한 후 ‘등록된 항목에 추가’ 버튼을 눌러야만 제대로 등록되니 체크만 했다면 이점 꼭 확인해주세요.

이후 검토 화면에서는 자신이 작성한 내용을 검토한 뒤에 하단의 ‘생성’을 클릭합니다.

이제 시간이 지난 후 로드 밸런서가 활성화되었는지 확인해봅니다. EC2 대시보드에서 좌측 메뉴 ‘로드 밸런싱’ 그룹의 ‘로드밸런서’를 클릭한 후 생성한 로드 밸런서의 상태가 ‘active’인지 확인합니다.

Route 53에 로드 밸런서를 연결하기

이제 마지막 과정만 남았습니다. Route 53에서 기존 도메인에 연결된 호스팅 대상 서버의 IP 주소를 로드 밸런서의 IP로 설정해야 합니다.

Route 53 대시보드로 들어간 후, 좌측 메뉴의 ‘호스팅 영역’을 클릭한 뒤 연결할 도메인을 클릭합니다.

이제 연결이 필요한 도메인(또는 서브 도메인) 이름에 대한 A 레코드를 수정합니다. 수정해야 할 도메인이 여러개라면(예: example.com, www.example.com, *.example.com…), 이를 모두 로드 밸런서에 연결해야 한다면 각각 A 레코드를 모두 수정해주어야 합니다. 만약 아직 설정된 A 레코드 규칙이 없다면 상단의 ‘레코드 생성’으로 만들어주겠습니다.

모든 내용이 편집되었다면 ‘레코드 세트 저장’을 클릭합니다. 레코드 세트 규칙이 반영되는 데에는 최대 1일이 소요될 수 있습니다.

이제 모든 과정이 완료되었습니다. 해당 도메인으로 접속하여 로드 밸런서가 문제 없이 연결되어 웹페이지가 잘 나타나는지 확인해봅니다.

또한 ACM 인증서가 적용되었는지도 확인해봅니다.

The post AWS ELB 생성 및 ACM 인증서 EC2에 적용하기 appeared first on JooTC.

웹사이트 인증서, 그리고 Let’s Encrypt란?

SSL 또는 TLS 인증서는 웹 사이트를 운영하면서 거의 필수적인 요소입니다. 클라이언트와 서버 간의 통신이 발생할 때 전송되는 모든 패킷 데이터를 암호화하여 감청이나 식별을 어렵게하여 보안에 있어 강력한 역할을 합니다.

웹 사이트 인증서를 발급해주는 대표적인 발급 기관(CA)으로는 Verisign, Comodo나 GlobalSign 등이 있으며 대개 호스팅 업체에서 등록을 대행해주기도 합니다.

민감한 정보를 교환하거나 개인정보를 취급하는 웹 사이트는 SSL/TLS 인증서를 발급하는 것이 좋습니다.

특히 법률에 의해 개인정보를 취급하는 웹 사이트에는 SSL 인증서를 무조건 달아야 할 것입니다. 그러나 대부분의 인증서 발급은 무료가 아니기 때문에 매년 새로운 인증서를 갱신함으로서 발생하는 시간과 비용은 만만치 않습니다. 물론 무료 인증서도 몇몇 있었지만 인증서 기관의 신용이 높은 편은 아닙니다.

이러한 가격적인 부담을 줄이고 인증서 발급의 복잡한 절차를 줄이고자 등장한 것은 Let’s Encrypt라는 비영리 기관입니다.

2016년 4월이라는 오래되지 않은 시기에 등장하였지만 현재는 모질라(Mozilla)와 시스코(Cisco), 구글(Google) 등의 다양한 업체가 스폰서로 참여하고 있으며 수많은 웹 사이트에 널리 사용되고 있는 추세입니다.

Let’s Encrypt를 사용하면 어떤 점이 좋은가요?

• 인증 절차가 단순화되었을 뿐만 아니라 발급 대기 시간이 없어 빠르게 인증서를 적용할 수 있습니다.
• TLS 인증서 발급이 가능하며 와일드 카드 인증서를 지원합니다.
• 발급을 위한 정보는 발급자 이메일만 요구됩니다.
• 만료된 인증서 갱신을 자동화할 수 있습니다.
• 심지어 무료입니다!

웹사이트 인증서를 발급하기 전에

먼저 인증서 발급을 위해서는 아래와 같은 조건이 필요합니다.

• 인증서를 설치할 서버의 터미널에 접속할 수 있어야 하며 root 권한을 사용할 수 있어야 합니다.

만약 일부 기능이 제한된 웹 호스팅 서비스를 사용 중이라면, 해당 업체에 문의하여 사용/설치 가능 여부를 확인해보셔야 합니다.

예를 들어 카페24나 가비아에서 서비스하는 웹 서비스 호스팅(서버 호스팅과는 다름)의 경우 유료 SSL 구매 및 설치만 가능하므로 불가능할 수 있습니다. 그러나 가상 또는 물리 서버를 구매/임대하였거나 클라우드 서비스(AWS, Azure 등)를 사용 중인 경우 서버 내 터미널에 접속할 수 있다면 Let’s Encrypt 인증서를 설치할 수 있습니다.

또한 터미널에 접속하여 root 권한(또는 root 계정 로그인)을 사용할 수 있어야 합니다. 일부 호스팅 업체에선 root 권한 취득을 제한하기도 합니다. 대표적으로 SSH 프로토콜을 사용하여 원격으로 서버에 접속할 수 있으며 해당 내용은 여기(https://jootc.com/p/201808031462)에 설명되어 있습니다.

Let’s Encrypt는 퍼블릭 도메인이 할당된 서버에서만 발급이 가능합니다. 내부 테스트용으로 구성된 서버이거나 공개 서버가 아닌 등의 이유로 자신의 서버에 IP만 할당되어 있는 경우에는 인증서 발급과 설치에 어려움이 있으므로 반드시 도메인을 할당해주어야 합니다.

인증서 유효기간은 90일이므로 지속적인 갱신 과정이 필요합니다. 다행히 갱신 과정을 자동화할 수 있음은 물론 Let’s Encrypt에서도 자동화에 대한 규제를 하지는 않기 때문에 유효기간에 있어 특별한 문제는 없을 것입니다. (물론 자동화 과정이 쉽지는 않습니다.)

그 외에 Let’s Encrypt 인증서에 대해 주의해야 할 내용은 다음과 같습니다.

• 인증서로 인해 발생한 피해에 대해 해당 기관으로부터 보상 받을 수 없습니다.
• 일부 오래 된 운영체제나 브라우저에서 인증서로 인한 올바르지 않은 동작이 발생할 수 있습니다.

인증서 설치 1단계 – Certbot 설치하기

Let’s Encrypt 인증서를 설치하기 위해서는 Certbot이라는 커맨드라인 도구를 사용해야 합니다. Certbot 도구는 수많은 웹 서비스와 운영체제를 지원하며 각각의 환경에 따라 설치 방법이 달라질 수 있습니다.

이 포스트에서는 가장 많이 쓰이는 리눅스 운영체제인 CentOS/Ubuntu, 그리고 웹 서비스 Apache와 Nginx를 중심으로 기술되었습니다.

설치를 위한 테스트 환경은 다음과 같이 구성해보았습니다.

• 운영체제 : Linux CentOS 7
• 도메인 : www.example.com (주의 – 이 도메인으로 실제로 테스트하시면 안됩니다.)
• 웹 서비스 : Nginx

먼저 인증서 발급에 필요한 패키지를 설치해주어야 합니다.

[Step 1-1] CentOS 설치 (CentOS 7 기준)

CentOS의 경우 EPEL 저장소를 활성화시켜주어야 합니다. 다음 명령어로 EPEL-Repository를 설치합니다.

$ sudo yum install epel-release

[Step 1-2] Ubuntu 설치 (18.04 LTS 기준)

우분투(Ubuntu)에서는 다음 명령어를 하나씩 실행시켜줍니다.

$ sudo apt-get update
$ sudo apt-get install software-properties-common
$ sudo add-apt-repository universe
$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt-get update

[Step 2] Certbot 설치

상단의 운영체제별 설치가 완료되었다면 이제 Certbot 패키지를 설치해줍니다. 패키지관리자는 운영체제에 따라 서로 다르게 입력합니다. (하단에서는 yum으로 진행합니다.)

• RedHat 계열 / CentOS : yum
• Debian 계열 / Ubuntu : apt

이제 certbot을 설치해보겠습니다.

$ sudo yum install certbot

이후 각각의 웹 서비스에 맞는 플러그인을 설치해줍니다.

Apache

$ sudo yum install python2-certbot-apache

Nginx

$ sudo yum install python2-certbot-nginx

인증서 설치 2단계 – 발급 과정 파악하기

이제 설치 작업은 완료되었으며 본격적으로 Certbot을 사용하여 인증서를 생성해보도록 하겠습니다.

발급할 때 주의해야 할 점은 하나의 호스트 또는 도메인에서 1일에 3회 이상의 발급을 시도할 수 없으므로 가능하면 발급 절차 시 실수를 하지 않도록 해야 합니다.

인증서를 발급하는 방법은 주로 webroot와 Standalone, DNS의 3가지 방식이 있습니다.

먼저 webroot 방식은 실제 웹 디렉토리 내에 인증서의 유효성을 확인할 수 있는 파일을 업로드하여 인증서를 발급하는 방법입니다. 한 번의 명령에 하나의 도메인 인증서만 발급받을 수 있습니다.

다음으로 Standalone 방식은 일시적으로 호스트 내의 웹 서비스를 빌려 인증서 유효성을 확인하는 방법입니다. 여러 도메인을 발급받을 수 있으나 이 방법을 사용하면 인증서가 발급되는 동안 운영 중인 웹 서비스가 잠시 중단될 것입니다.

마지막으로 DNS 방식은 도메인을 쿼리하여 나타나는 TXT 레코드에서 인증서 유효성을 확인하는 방법입니다. 이 경우 해당 도메인의 DNS를 관리/수정할 수 있는 조건이 되어야 합니다.

결론적으로 인증 기관(CA)이 발급할 서버에 방문하여 인증서와 동일한 도메인인지 확인하는 과정이 진행되며, 이러한 과정에 ACME 프로토콜을 사용하여 CA와 서버 간의 유효성 검증을 시도(Challenge) 합니다. 따라서 투명성을 위해 인증 도중 서버의 IP와 트랜잭션 내역이 인증 기관에 기록되게 됩니다.

아무튼 다양한 발급 방법들이 있지만, 여기에는 각자의 장단점이 있고 어떠한 방식으로 해도 무관하므로 원하시는 방법을 선택하여 진행하면 되겠습니다.

인증서 설치 3단계 – Certbot 명령어 사용

Certbot의 일반적인 명령 예시는 다음과 같습니다.

$ sudo certbot --apache --standalone -d example.com certonly

–apache / –nginx

기본 명령에 웹 서비스(예 : apache, nginx 등) 이름을 옵션값으로 붙여주어 해당 웹 서비스에 맞는 발급 과정을 진행하도록 합니다.

–standalone / –webroot

인증서 발급 방식은 옵션을 붙여 사용할 수 있습니다. (예 : webroot 방식인 경우 --webroot를 붙입니다.) 세가지 방식을 직접 선택할 경우 --manual 옵션을 붙이면 됩니다.

DNS 방식의 경우 --preferred-challenges dns 값을 붙여줍니다.

-d [도메인 이름]

-d 옵션은 발급할 인증서의 도메인을 입력하는 부분입니다. 여러 도메인을 사용하는 경우 계속 -d 옵션을 붙이거나 콤마(,)로 구분하여 입력하면 됩니다. (예 : -d example.com,sub1.example.com,sub2.example.com...)

certonly

원래는 인증서 발급 시 웹 서비스의 설정 파일을 직접 편집해줍니다. (다만 가능하다면 직접 수정하는 것이 안전합니다.) certonly 값을 붙이면 웹 서비스 설정 파일에 인증서 관련 내용을 임의로 수정하지 않도록 합니다.

이제 파악한 정보를 토대로 본격적인 인증서를 발급해보도록 하겠습니다.

여기서는 TXT 레코드를 수정하거나 임의의 파일을 생성할 필요가 없는 Standalone 방식으로 진행할 것입니다. 사실상 간편하고 빠르기 때문이기도 합니다.

Standalone 방식은 웹 서비스를 임시로 빌리기 때문에 현재 구동되고 있는 웹 서비스를 잠시 중지하도록 하겠습니다. 아래는 Nginx 웹 서비스를 중지하는 예시입니다. 만약 Apache를 사용한다면 httpd 또는 apache2로 시도해보시면 됩니다.

$ sudo service nginx stop

이제 다음 명령을 입력해보겠습니다.

$ sudo certbot certonly --standalone -d example.com

먼저 다음과 같은 내용이 나타나면 도메인 관리자의 이메일 주소를 입력해줍니다. 해당 이메일로 갱신 알림이나 주요한 소식들이 발송될 수 있습니다.

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel):

이번에는 이용원칙 동의 및 인증 기관에 등록되는 사항에 관한 내용입니다.

Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel:

어차피 동의해야 하므로 A를 입력하고 엔터를 입력해줍니다.

이번 내용은 제 3자 업체에게 정보를 공유하겠냐는 내용입니다. 원치 않은 경우 N을 입력하여 거부할 수 있습니다.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o:

이제 특별한 문제가 나타나지 않는다면 발급 과정이 진행됩니다.

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for example.com
Waiting for verification...
Cleaning up challenges
Resetting dropped connection: acme-v02.api.letsencrypt.org

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
   Your cert will expire on 2019-04-06. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le


Congratulations! 문구가 나타났다면 발급이 정상적으로 완료된 것입니다.

인증서 설치 4단계 – 웹 서비스에 반영하기

인증서가 생성되면 인증서 파일은 다음 경로에 저장 될 것입니다.

/etc/letsencrypt/live/[신청한 인증서의 도메인명].com

여기서는 example.com 으로 시도했으므로 /etc/letsencrypt/live/example.com 디렉토리가 될 것입니다. (서브 도메인이어도 마찬가지입니다.)

대략적인 파일들은 다음과 같습니다.

[root@localhost ~]# ls -al
total 4
drwxr-xr-x. 2 root root  93 Jan  5 20:56 .
drwx------. 7 root root 136 Jan  5 21:04 ..
lrwxrwxrwx. 1 root root  34 Jan  5 20:56 cert.pem -> ../../archive/example.com/cert1.pem
lrwxrwxrwx. 1 root root  35 Jan  5 20:56 chain.pem -> ../../archive/example.com/chain1.pem
lrwxrwxrwx. 1 root root  39 Jan  5 20:56 fullchain.pem -> ../../archive/example.com/fullchain1.pem
lrwxrwxrwx. 1 root root  37 Jan  5 20:56 privkey.pem -> ../../archive/example.com/privkey1.pem
-rw-r--r--. 1 root root 692 Jan  5 20:56 README

(가능하면 이 파일들은 현재 위치에 그대로 두는 것이 좋습니다.)

이제 웹 서비스의 설정 파일에 발급한 인증서를 등록해보겠습니다. 웹 서비스의 설정 파일 특성과 환경에 따라 여기서 언급된 내용과 다르게 설정해야할 수 있으므로 아래 예시는 언제까지나 참고용으로만 봐주셨으면 합니다.

Apache 설정 예시

example.com의 Apache 설정 파일은 일반적으로 다음 경로에 있습니다.

• Debian 계열 : /etc/apache2/apache2.conf
• RedHat 계열 : /etc/httpd/conf/httpd.conf

해당 경로의 파일을 편집하여 하단에 다음과 같이 VirtualHost를 추가해줍니다.

<VirtualHost *:443>
DocumentRoot /var/www/html
ServerName example.com:443
</VirtualHost>

필요한 설정을 작성해주신 후 하단의 내용을 VirtualHost 내에 붙여넣어줍니다. (인증서 경로가 올바른지 다시 한 번 검토해보시기 바랍니다.)

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/example.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/example.com/fullchain.pem

이제 중지했었던 웹 서비스를 다시 시작해보도록 하겠습니다. 다음 명령어를 실행합니다. (Debian 계열은 httpd 대신 apache2로 입력해야 할 수 있음)

$ sudo service httpd start

Nginx 설정 예시

example.com의 Nginx 설정 파일(/etc/nginx/nginx.conf) 내용은 다음과 같습니다.

server {
        listen  443 ssl http2;
        listen  [::]:443 ssl http2;
        server_name example.com www.example.com;
        root    /usr/share/nginx/html;
        include /etc/nginx/example.com.conf.d/*.conf;
}

443 포트로 listen하고 있는 server 블록 내에 하단의 내용을 붙여넣습니다. (인증서 경로가 올바른지 다시 한 번 검토해보시기 바랍니다.)

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

이제 중지했었던 웹 서비스를 다시 시작해보도록 하겠습니다. 다음 명령어를 실행합니다.

$ sudo service nginx start

인증서 설치 5단계 – 적용된 인증서 확인하기

이제 웹 사이트에 정상적으로 인증서가 설치되었는지 확인해보도록 하겠습니다. 간단히 해당 웹 사이트에 접속하여 인증서 적용 여부를 확인해보시면 됩니다.

예를 들어 대부분의 브라우저의 경우 (하단의 예시는 구글 크롬) 다음과 같이 자물쇠 아이콘이 나타날 것입니다.

구글 크롬의 경우 하단의 ‘인증서’ 버튼을 클릭하면 자세한 인증서 정보가 나타날 것입니다.

여기에서 발급자가 Let’s Encrypt Authority X3인지, 유효 기간이 올바른지 확인해보시면 됩니다.

인증서는 90일 동안만 유효하므로 서버 내에서 갱신을 자동화 할 수 있도록 설계하는 것이 좋습니다. 이 내용은 추가 포스팅으로 작성해보도록 하겠습니다.

기타 – 인증서 설치 시 다른 웹 서비스를 사용 중인 경우

이외의 웹 서비스나 운영체제를 사용 중인 경우 하단의 Certbot 공식 웹 페이지에서 설치 문서를 확인할 수 있습니다.

https://certbot.eff.org/

참고자료

• Let’s Encrypt Wikipedia : https://ko.wikipedia.org/wiki/Let%27s_Encrypt

The post Let’s Encrypt 인증서 발급 및 Certbot 설치하기 (Apache/Nginx) appeared first on JooTC.

Let’s Encrypt를 사용한 SSL 인증서를 갱신하기 위해 certbot 명령을 실행할 때 다음과 같은 에러 메세지를 출력하며 진행되지 않는 경우가 있습니다.

[user@localhost ~] certbot renew
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator nginx, Installer nginx
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for mydomain.com
tls-sni-01 challenge for www.mydomain.com
TLS-SNI-01 is deprecated, and will stop working soon.
Waiting for verification...
Cleaning up challenges
Attempting to renew cert (mydomain.com) from /etc/letsencrypt/renewal/mydomain.com.conf produced an unexpected error: Failed authorization procedure. www.mydomain.com (tls-sni-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested a6f5c6278e55ab77829c7728f131b23c.db022d95c42b0caa977421e2e211e889.acme.invalid from ###.###.###.###:443. Received 2 certificate(s), first certificate had names "mydomain.com, www.mydomain.com", mydomain.com (tls-sni-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested 4d9061a564da289e018e014e209e40c9.b725884a7a9819e0a91856f4d12d9bc7.acme.invalid from ###.###.###.###:443. Received 2 certificate(s), first certificate had names "mydomain.com, www.mydomain.com". Skipping.

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/mydomain.com/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:
 - The following errors were reported by the server:

Domain: www.mydomain.com
   Type:   unauthorized
   Detail: Incorrect validation certificate for tls-sni-01 challenge.
   Requested
   a6f5c6278e55ab77829c7728f131b23c.db022d95c42b0caa977421e2e211e889.acme.invalid
   from ###.###.###.###:443. Received 2 certificate(s), first
   certificate had names "mydomain.com, www.mydomain.com"

   Domain: mydomain.com
   Type:   unauthorized
   Detail: Incorrect validation certificate for tls-sni-01 challenge.
   Requested
   4d9061a564da289e018e014e209e40c9.b725884a7a9819e0a91856f4d12d9bc7.acme.invalid
   from ###.###.###.###:443. Received 2 certificate(s), first
   certificate had names "mydomain.com, www.mydomain.com"

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address.

에러 메세지가 길게 표시되었는데 여기서 하단의 ‘Detail’ 에러 메세지를 참고하면 다음과 같이 나와있습니다.

Incorrect validation certificate for tls-sni-01 challenge.

해결 방법

이 문제를 해결하기 위해 다음 명령어로 인증서를 갱신해야 합니다.

certbot certonly -d mydomain.com --manual --preferred-challenges dns

--preferred-challenges dns 옵션을 붙여주면 ACME(Automated Certificate Management Environment) 프로토콜이 인증서 서명 요청을 위한 선호 방법을 DNS로 지정하게 됩니다.

명령을 실행하면 다음과 같이 진행될 것입니다.

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Cert not yet due for renewal

이후 만약 기존에 설정된 인증서가 존재한다면 다음과 같이 나타날 것입니다.

You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/mydomain.com.conf)

What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Keep the existing certificate for now
2: Renew & replace the cert (limit ~5 per 7 days)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

여기서는 기존의 인증서를 폐기하고 새로운 인증서로 갱신하기로 하여 2를 입력하였습니다.

다음으로 나타나는 메세지는 인증서 갱신을 요청한 장치의 IP가 공개적으로 기록되는 것임을 알리는 프롬프트입니다.

Renewing an existing certificate
Performing the following challenges:
dns-01 challenge for mydomain.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: Y

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Y를 입력하여 계속 진행합니다.

마지막으로 acme 요청을 위해 DNS 서버를 수정하라는 내용입니다. 아래 내용에서 Enter를 누르지 않은 상태로 유지해주세요.

Please deploy a DNS TXT record under the name
_acme-challenge.mydomain.com with the following value:

V9f2_ay6H-HfBAYDkco07wNjdYdxSjX-TfFxsAJS8vS

Before continuing, verify the record is deployed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue

이제 도메인을 관리하는 호스팅이나 클라우드에서 TXT 레코드를 추가해주어야 합니다. 직접 편집할 수 없는 경우 서버 관리자에게 요청해야 할 수도 있습니다.

TXT레코드 설정 예시

• 도메인 : _acme-challenge.mydomain.com
• TTL : 1800 / 3600
• 값(Value) : V9f2_ay6H-HfBAYDkco07wNjdYdxSjX-TfFxsAJS8vS
• Routing Policy (AWS Route 53인 경우) : Simple

만약 서브 도메인이 여러개 있다면 각각의 서브 도메인 이름으로 명령을 실행해주어야 합니다. 물론 TEXT 레코드 또한 개별적으로 등록되어야 합니다. 만약 서브 도메인 이름이 subdomain인 경우 이 때의 레코드 이름은 _acme-challenge.subdomain.mydomain.com 이 될 것입니다.

새로운 터미널 창을 열고 dig 명령어를 실행하여 TXT 레코드가 정상적으로 나타나는지 확인해봅니다.

dig TXT _acme-challenge.mydomain.com

결과는 대략 다음과 같습니다.

dig TXT _acme-challenge.mydomain.com

; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> TXT _acme-challenge.mydomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26750
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_acme-challenge.mydomain.com.	IN	TXT

;; ANSWER SECTION:
_acme-challenge.mydomain.com. 60	IN	TXT	"V9f2_ay6H-HfBAYDkco07wNjdYdxSjX-TfFxsAJS8vS"

;; Query time: 2 msec
;; SERVER: ###.###.###.1#53(###.###.###.1)
;; WHEN: Sun Dec 30 13:32:00 KST 2018
;; MSG SIZE  rcvd: 111

TXT 값에 상단의 _acme-challenge TXT 값과 일치하다면 이제 기존 터미널에서 엔터를 입력하여 갱신을 진행할 수 있습니다.

Waiting for verification...
Cleaning up challenges
Resetting dropped connection: acme-v02.api.letsencrypt.org

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/mydomain.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/mydomain.com/privkey.pem
   Your cert will expire on 2019-03-30. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

The post Incorrect validation certificate for tls-sni-01 challenge 에러 appeared first on JooTC.