aws ACM으로 SSL/TLS 인증서 발급하기(feat. 가비아)

 

 

 

 

cloudfront, elb를 사용할 때 https를 쓰려면 인증서가 필요합니다. aws가 아닌 인증서 발급 업체에서 발급받아도 되지만 지금은 aws의 ACM에서 발급받겠습니다.

 

인증서는 클라이언트와 서버 간에 안전하게 데이터를 암호화하고, 서버의 신뢰성을 보장하는 데 사용됩니다.

 

 

※ 주의!!!
CloudFront 를 쓸 계획이 있는 경우에는 버지니아 북부 US East (N. Virginia) us-east-1 리전에서 인증서를 만들어야 합니다! 발급 전에 리전 바꾸기 필수!!

ACM 인증서는 특정 리전에 종속되어 발급되기때문에 서울 리전에서 발급된 인증서는 오리건 리전이나 버지니아 리전에서 사용할 수 없습니다. 그래서 여러 리전에서 서비스를 운영하는 경우, 각 리전마다 인증서를 발급받아야 합니다.

ACM 인증서은 리전별 적용인데, cloudfront는 글로벌 서비스라서 cloudfront 에 쓸 수 있는 인증서는 버지니아 북부 리전으로 aws 가 정한 것입니다.

 

 

 

발급 시작

만들려고 딱 들어갔더니 무슨 권한이 없답니다. 그래서 발급 못 받는건가?? 했는데 그건 아니고 private 인증서 발급만 안되는 것이었습니다. 그래서 Request a private certificate 가 회색처리 되어 있지만 Next 가 가능합니다.

 

public 인증서는 외부로부터 공개된 도메인에 사용되고, 대외적으로 신뢰받습니다.

private 인증서는 내부 시스템이나 사설 네트워크에서 사용하고, 대외적으로 신뢰받지 않습니다. 브라우저에서 "신뢰되지 않는 인증서" 경고가 표시되면 이 경우 입니다. 그래서 수동으로 설치해줘야 합니다.

 

저는 외부에서 접근하는 도메인이기 때문에 public 인증서를 만들것이므로 경고는 무시하겠습니다.

 

 

 

Domain names

도메인 이름은 루트 도메인과 앞에 *. 을 추가한 와일드카드(Wildcard) 도메인을 적습니다. 와일드카드 도메인은 모든 서브도메인(http://www.example.com, app.example.com, api.example.com 등)을 포함하는 도메인입니다.

와일드카드 도메인을 쓰는 이유

 - 여러 개의 서브도메인에 대해 개별 인증서를 발급받지 않고 하나의 인증서로 적용 가능

 - 새로운 서브도메인을 추가할 때에도 인증서를 새로 발급할 필요 없음

 

참고

*.example.com 인증서는 api.example.com까지 가능하지만, 하위 서브도메인인 sub.api.example.com에는 적용되지 않습니다.

 

 

 

Validation method

제가 해당 도메인의 주인인지 검증할건데 어떤걸로 검증받을래? 입니다.

검증방법은 두가지가 있습니다.

 

DNS 검증

aws : 너가 이 도메인의 소유자가 맞다면 DNS 설정 변경할 수 있지? CNAME 레코드 만들어서 줄테니까 추가해봐~ 그럼 그거 보고 우리가 확인해줄게

 

이메일 검증

hostmaster@example.com 같은 이메일로 인증 메일 발송, 사용자가 직접 확인 후 승인. 근데 본인이 직접 운영중인 메일 서버가 있나요?? 없지요. 그러면 Google Workspace, Zoho Mail, 네이버 웍스 등과 같은 도메인 이메일 서비스를 이용해서 hostmaster@example.com 이메일을 만들 수는 있니다만.. 귀찮ㅠ

가비아는 메일 서비스를 제공해서 hostmaster@example.com을 생성할 순 있습니다. 근데 이것도 어쨌든 뭘 추가로 해야하는거죠.


네, 그냥 DNS 검증으로 하겠습니다. 이게 가장 빠르고 편합니다. 괜히 recommended가 아니죠.

 

 

 

Key algorithm

RSA 2048

 - RSA는 가장 널리 사용되어 호환성이 뛰어나고, 다양한 시스템에서 지원됩니다.

 - ECDSA보다 성능이 떨어질 수 있습니다.

 

ECDSA P 256 (RSA 3072 급 보안성)

 - ECDSA는 RSA보다 작은 키로 더 높은 보안성을 제공합니다.

 - 오래된 시스템에서는 ECDSA를 지원하지 않을 수 있습니다.

 

ECDSA P 384 (RSA 7680 급 보안성)

 - P-256보다 더 높은 보안성을 제공합니다.

 - P-256보다 더 많은 시스템에서 지원되지 않을 수 있습니다.

 - 계산이 더 복잡하여 성능이 조금 떨어질 수 있습니다.

 

보안성: ECDSA P-384 > ECDSA P-256 > RSA 2048
성능: ECDSA P-256 > RSA 2048 > ECDSA P-384
호환성: RSA 2048 > ECDSA P-256 > ECDSA P-384

 

대부분의 경우 무난하게 호환성 높은 RSA 2048을 선택합니다.

 

 

이제 Request 를 누르면 성공적으로 요청되었다고 나옵니다.

그리고 status 를 보면 Pending validation(검증 대기 중) 으로 되어 있고 CNAME value 가 생겼습니다. 위에서 DNS 검증을 선택했었죠? CNAME 레코드 추가해봐~ 를 이제 해야합니다. 다행히 우리는 route53으로 도메인을 관리하고 있기 때문에 딸깍! 으로 바로 가능합니다. route53으로 관리하는게 아닌 경우엔 해당 사이트 들어가서 뭘 또 수정하고 해야할겁니다.

Create records in Route 53 (Route 53에서 레코드 생성) 을 눌러줍니다. 

 

아래 화면이 뜨면 바로 create records 를 눌러줍니다.

 

그러면 성공적으로 DNS 레코드가 생성되었다고 뜹니다.

 

확인해볼까요? Route53으로 가서 Hosted zones 에 Records 를 보면

 

기존에 없던 CNAME 레코드가 생성된 것을 볼 수 있습니다.

 

이제 다시 ACM 으로 가서 확인해보면

 

status가 success 로 바뀌어 있습니다. 인증서 발급 완료~

 

 

 

이렇게 cloudfront 용 인증서는 버지니아 리전으로 발급을 완료했습니다. 하지만 우리의 alb는 서울리전에 있겠죠? 인증서는 리전별로 적용되기 때문에 서울리전으로 바꾸고 인증서를 하나 더 발급해주어야 합니다. 리전을 바꾸고 동일하게 발급해주세요!

 

그런데 이때 Create records in Route 53 을 안눌러도 잠시 후에 자동으로 발급이 될 것입니다! CNAME 등록을 안했는데 왜 인증이 됐지?? 왜냐하면!

 

✅ 왜 CNAME을 등록 안 해도 Issued가 됐을까?
1️⃣ CloudFront용으로 버지니아 리전에 ACM 인증서를 발급했었음

이때 Create records in Route 53을 눌러서 CNAME을 Route 53에 등록했음
2️⃣ 이번에는 서울 리전에서 ACM 인증서를 새로 발급하려고 함

하지만 ACM은 같은 도메인에 대해 기존에 검증된 CNAME이 있으면 자동으로 인증을 통과시킴
3️⃣ Route 53에 기존 CNAME 레코드가 남아 있어서, 자동 검증됨

그래서 이번에는 Create records in Route 53을 안 눌러도 Issued 상태로 변경된 것!