aws 에서 도메인, ssl 인증서 발급 및 적용하기

 

본 포스팅의 모든 과정은 나도 처음 해보고 헤매느랴

중간중간 스샷만 뜨면서 계속 작업했음.

그래서 중간중간 완료된 화면이 나타날 수 도 있다. 

 

 

1. 도메인 신청은 Route53 메뉴를 이용하면 된다.

도메인 등록 버튼 누르고 본인이 원하는 도메인 입력하고 사용가능한지 확인하고 비용 확인하고 신청하면 됨.

smc-secu.net 은 1년에 1.3만원 정도였던 듯..

 

aws 에서는 .com .net .kr .jp .org 같은 최상위 도메인(탑레벨 도메인)의 일부를 지원한다.

대략 .com .net .io 정도에서 선택 가능한데

도메인 주소를 sec.smc 로 맞추기 위한 smc 도메인은 지원하지 않음.

 

comics.smc-secu.net 와 같은 식의 서브도메인을 활용하고 싶으면

사용자가 직접 도메인과 네임서버를 구성해야 한다.

 

 

2.  당연히 신청한 도메인은 elastic ip 같은 고정 ip 와도 연결해줘야 한다.

그리고 해당 도메인이 작동하려면 호스팅 영역에 A 레코드를 생성해줘야 한다. 

실제 인터넷 세계에서 작동 중인 네임서버에게 내 도메인을 등록하고 관리해달라고 알려야 함.

 

밑에 보이는 NS 레코드가 아마존이 관리하는 네임서버 주소다.

실제 내 도메인이 해당 네임서버 4대에 등록되어 있다는 거고

얘들이랑 딴 애들이랑 라우팅 정보를 교환하면서 내 도메인으로 가는 길을 알려주는 거임.

 

매우 간단한 작업이라 이 시점의 스샷은 놓쳤다.

레코드 이름 통일하고 유형은 A 유형으로 신규 생성하면 된다.

 

A 레코드는 Address 를 의미한다. 실제 도메인의 ip 주소가 반영되는 레코드임.

SOA 는 Start Of Authority 로 도메인영역에 대한 중요한 정보를 저장하고

NS 와 함께 이 두개 레코드는 도메인 신규 생성시 자동으로 생성된다.

 

물론 외부에서 구입한 도메인을 aws 호스팅에 연결하는 것도 가능하다.

 

참 도메인 신청은 시간이 좀 걸린다.

잘 기억은 안나는데 며칠까진 아니고 1시간 좀 안되게 걸렸던 듯.

 

 

 

3. 그리고 웹서버(아파치) 설정을 좀 잡아주면 됨.

 

/etc/httpd/conf/httpd.conf 를 수정해서

웹 도큐멘트루트와  디렉토리를 본인 경로에 맞게 잡아줘야 한다.

 

 

설정을 마친 후  sudo systemctl restart httpd 로 웹서버 재기동하면

내 도메인으로 index.html 이 잘 작동하는지 확인할 수 있다.

 

사실 여기까지만해도 제법 감격스럽다.

 

하지만 더 나아가서 SSL 인증서도 발급하고 https 접속도 지원해보자.

 

 

 

3. ssl 인증서 발급은 ACM 메뉴를 이용한다.

내 서버 자체에서 인증서 발급하는 수동방식도 있으나 그러면 공인된 ssl 인증서가 아닌

개인의 ssl 인증서로 발급되고 브라우저에서 해당 사이트를 신뢰하기에 애메하다는 메세지가 나올 것이다.

(해보진 않음)

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2023.html#ssl_enable

Amazon Linux 2023에서 SSL/TLS 구성 - Amazon Elastic Compute Cloud

 

하지만 aws 에서 관리해주는 인증서를 사용한다면

편하기도 하고 인증서의 신뢰도가 올라가겠지.

(사실 작업하다가 헤매는 거 생각하면 편한지는 모르겠다.)

 

여튼 acm 에서 인증서를 신청하자.

 

 

 

 

 

smc-secu.net 의 인증서가 검증을 통과해야 해야 하는 아래 구간에서 많이 헤맸다.

 

순순히 알려주지 않고 애들도 헤매게 만들고 싶으나...

그래도 내가 학교 선생인데 알려줘야지 ㅋ

 

위 스샷의 도메인 항목의 레코드 생성 버튼을 누르면 도메인의 CNAME 레코드가 자동으로 반영된다.

근데 이건 인증서 생성한 직후 한번만 가능한 듯.

 

만약 기존 도메인에서 레코드를 지웠거나 다른 이유로 재등록이 필요하다면

Route53 의 DNS 레코드를 직접 편집하면 된다.

 

 

Route53 의 호스팅 영역에서 해당 도메인 선택 후 세부영역 정보를 확인하면 

2번 항목에서 설명했던 화면이 나오고 레코드 생성 및 삭제가 가능함.

여기에 CNAME 유형으로 CNAME 값과 이름을 반영해준다.

 

CNAME 이름과 CNAME 값은 ACM 에서 인증서에서 확인 가능하다.

 

이게 잘 되면 검증완료로 바로 전환됨.

 

 

 

CNAME 레코드는 실제 도메인을 찾아가게끔 해주는 기능을 한다.

 

예를 들어 blog.example.com 같은 서브도메인의 경우

CNAME으로 반영되어 있는 루트 도메인 example.com 을 가리키거거나

CNAME  으로 반영되어 있는 루트 도메인에서 주소값 변경이 발생하면 이를 따라간다는 개념임.

 

그러니까 우리는 ACM 에서 SSL/TLS 인증서를 발급 요청했고 

이를 위해 도메인의 소유권을 인증한 작업을 한 것이다.

 

ACM 에서 제공한 CNAME 레코드를 Route53 의 호스팅에 추가한 것은

ACM 이 내 도메인을 관리할 수 있는 권한을 가지고 있다는 의미이다.

 

CNAME 레코드가 성공적으로 DNS에 추가되고 인증이 완료되면

ACM 이 그제서야 SSL/TLS 인증서를 발급하고 이 인증서는 해당 도메인에 서HTTPS 연결에 사용된다.

 

 

특이점은  AWS의 ACM(AWS Certificate Manager)에서 발급받은 SSL/TLS 인증서는

AWS 클라우드 서비스 내에서 관리되며, 일반적으로 직접 서버에 설치되지 않는다는 점이다.

 

즉 내 서버에 인증서가 잘 설치되었나는 확인할 수 없고

웹 콘솔로 들어가서 인증서 목록을 보는게 다임.

 

대신 이 인증서는 AWS의 다른 서비스(예를 들어 Elastic Load Balancer(ELB), Amazon CloudFront, API Gateway 등)

와 함께 사용되느데 이러한 서비스들은 ACM에서 관리되는 인증서를 자동으로 불러와 사용한다.

 

서버에 직접 설치하는 전통적인 SSL/TLS 인증서와는 다르게 작동하므로

AWS의 통합된 서비스 관리 방식은 인증서의 설치, 갱신 및 관리를 간소화 하는 장점이 있다.

 

 

 

 

4. 그러므로  이 인증서를 사용하려면 로드밸런서가 필요함.

로드밸런서는 어플리케이션, 네트워크, 게이트웨이 기반으로 여러 종류가 있는데

우리는 웹접속이 주 목적이므로 어플리케이션 로드밸런서를 생성해주면 된다.

 

로드 밸런서를 사용하게 되면 서버들을 하나의 도메인으로 묶을 수도 있고

이를 통해 각 서버별로 TLS 인증서를 설치하지 않고 로드밸런서에 인증서를 설치하는 것이 가능함

 

 

서브넷을 두개 선택해주면 되는데 난 아무생각없이 a,b 선택했다가 나중에 좀 해멨다.

 

리스너 추가 버튼으로 443 연결도 추가해주자.

 

근데 해당 포트를 연결하려면 대상 그룹(target group)이란게 필요함.

타겟 그룹이 없으니 만들어줘야 한다.

 

참고로 AWS의 타겟 그룹(Target Group)은 Elastic Load Balancing 서비스에서 사용되며

특정 로드 밸런서에 대한 트래픽을 처리할 대상 또는 '타겟'들의 집합을 정의한다.

 

타겟 그룹은 로드 밸런서가 트래픽을 전달할 여러 개의 서버(예: EC2 인스턴스), 람다 함수, IP 주소 등을 포함할 수 있고

타겟 그룹을 사용함으로써 사용자는 로드 밸런서를 통해 들어오는 트래픽을 더 효율적이고 유연하게 관리할 수 있다.

 

타겟 그룹은 자동 확장(Auto Scaling) 그룹과 연동하여 사용할 수 있는데

이를 통해 트래픽이 증가할 때 자동으로 EC2 인스턴스를 추가하고, 트래픽이 감소할 때 인스턴스를 줄일 수도 있다.

 

특히 Application Load Balancer에서는 타겟 그룹을 사용하여 룰 기반 라우팅을 구성할 수 있는데

예를 들어 특정 URL 패턴이나 호스트 이름에 따라 다른 타겟 그룹으로 트래픽을 라우팅할 수 있습니다.

타겟 그룹을 통해 사용자는 높은 가용성, 탄력성 및 확장성을 가진 애플리케이션 아키텍처를 구축할 수 있으며

트래픽 분산 및 관리를 더욱 효과적으로 수행할 수 있다. 고 한다.

 

우리는 뭐 복잡한거 할 단계는 아니고 아주 간단한 실습을 해보는 정도라 미리 개념만 잡자.

 

여튼 타켓그룹으로 80, 443 포트를 생성하고 등록해주면 됨.

 

사실 난 80만 등록하고 이후 작업을 하다가

지금 포스팅 쓰면서 작업내역 정리하다 이제야 443 포트를 추가해줬다.

 

지금은 작업이 완료된 시점이라 내 사이트(https://smc-secu.net)로 향하는 모든 80 트래픽은 443으로 강제 전환되고

웹접속도 잘 이루어지고 있음에도 80, 443 포트의 헬스체크는 잘 안되는 것으로 보인다.

 

왜인지는 별로 궁금하지 않지만 나중에 알아봐야지.

여튼 ec2 서비스 내에서 대상그룹(타켓 그룹) 생성했으면 

아까 로드밸런서 리스너 80, 443 에 반영해주자.

 

 

아까 3번에서 ACM 에서 SSL 인증서 발급이 잘 되었다면

로드밸런서에서 해당 인증서를 불러와 적용할 수 있다.

 

인증서 적용하고 로드밸러서 생성하면 됨.

 

스샷에는 내가 80 에 대상그룹 지정안한 걸로 보이지만 사실 잘 해놨다.

 

 

로드밸러서를 잘 만들었으면 얘를 호스팅 A 레코드에 반영해줘야함.

레코드 편집 들어가서 기존 고정 IP 값을 로드밸런서 값으로 수정해주자.

 

 

여기까지 하면 짠 하고 https 접속이 잘 되어야 할 것 같은데 현실은 503 에러임.

이제부턴 각자의 영역이다. 건투를 빈다.

 

 

 

5. 뭐가 문젠지 살펴보자.

일단 ssh 접속이 안되고 ping 도 안나간다.

 

근데 ec2 는 웹콘솔로 접속이 가능하긴 한데 외부 ssh 가 막히다니..

뜨악했지만 로드밸런서에서 ssh 를 통과시켜주지 않으므로 당연한 변화이다.

 

 

근데 어플리케이션 로드밸런서는 7계층 기반이기 때문에 ssh 적용이 불가능하다.

그럼 로드밸런서를 네트워크 기반으로 새로 생성하고 ssh 를 추가 오픈해야 하나?

 

아니다. 도메인이 아닌 본래 ip 로 접속하면 된다.

nslookup 을 쳐보면 실제 ip 가 아닌 elb 의 ip 가 나온다.

 

ssh 를 외부에 오픈하는 것도 보안상 좋지 않은데

나름 적절한 보안적 조치가 취해진 셈이다.

 

 

실제로 ip 로 접속해보면 페이지가 나타남.

그러니까 도메인 적용에 관한 문제이다.

 

 

뭘 어떻게 하다보니 페이지가 다시 보임.

 

아마 관리자 페이지 들어가서 일반 설정에서 워드프레스 도메인을 https:// 로 바꿔줬던거 같은데..

 

근데 이거 하다보면 https 가 제대로 적용안된 상태에서 

관리자 페이지로의 https 연결이 끊겨버리고 그런다.

 

그 땐 DB 의 wp_option 테이블에서 해당 정보를 직접 바꿔 줄 수 있다.

phpMyAdmin 을 잘 활용하던지 직접 DB 에서 update 치던지 해라.

 

위 스샷은 http://my_ip 로 접속한 화면이고 

페이지가 깨진건 워드프레스 dns 가 맞지 않아서인 듯 하다.

(아래 포스팅의 가장 마지막 부분 참고)

운용 중인 워드프레스 마이그레이션하기

 

 

하지만 아직 https://my_ip 로는 연결되지 않는다.

 

 

아래 화면은 원인을 점검하던 중 타겟 그룹이 제대로 사용되지 않음을 발견한 화면이다.

 

지금돌이켜보니 로드밸런서 만들 때 아무생각 없이 적용한 서브넷 A,B 를 조정했음

정작 내 EC2 가 해당 서브넷에 속해있지 않았기 때문에

EC2 의 서브넷 정보를 확인하고 로드밸런서에서 다시 반영해줬다.

 

 

그제서야 페이지가 제대로 보인다.

하지만 아직 http:// 접속임

 

 

https:// 도 접속은 되는데 영 원할하지가 않다.

 

 

어떻게 하다보니 https 연결이 잘 된다 ^0^

어떻게 했는지는 기억이 안남..

각자의 영역입니다.

 

 

참. 난 한참 해메다가 기존 설정에 아래와 같은 .htaccess 를 적용했었는데 이걸 지워줬다.

 

 

 

구글링 하다보면 https 연결을 위해서 워드프레스 웹루트 디렉토리에

.htaccess 에 저 내용을 채워놓으라고 하는데 저게 잘 작동을 안함.

오히려 인터널 에러 내고 그런다.

 

저거 말고 다른 방식으로 적용이 가능하니 .htaccess 는 굳이 만들지 말자.

 

두번재 힌트를 주자면

wordpress 설치 디렉토리에서 wp-config.php 에 추가 설정을 적용해야 함

 

이 설정을 저 주석 위에 넣어줘라.

아무 위치에나 넣으면 동작이 안된다.

define('FORCE_SSL_ADMIN', true);
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
$_SERVER['HTTPS']='on';


/* That's all, stop editing! Happy publishing. */

 

어쨌든 https 로의 접속이 잘 되는 상태가 되었는데

이게 인덱스 껍데기만 잘 되고 하위 url 들은 애메하게 동작한다.

 

사실 아까 .htaccess 설정이 하위url 까지도 ssl 잘 연결하라는 설정이었는데 이게 안먹은 거임.

워드프레스 플러그인 really simple ssl 을 설치하면 그나마 설정이 잘 잡히고 동작한다.

 

 

여기까지 읽어보셨다면 건투를 빈다.

 

사실 나도 elb  헬스체크가 제대로 되지 않고

502 배드게이트웨이가 자꾸 발생하고(근데 새로 고침 3번 하면 됨)

몇몇 이미지는 불러오기가 안되는 등

좀 더 손 봐야하는 상황이다. 

(헬스체크 말고는 해결했다)

 

 

원래 컴퓨터가 되야 하는데 안되는게 흔해서..

안되는 이유를 찾고 되게끔 하는 과정이 공부라는 걸 강조하며

 

각자 잘 해보고 과정도 잘 기록해서

업그레이드된 매뉴얼로 만들어주길 바랍니다.

 

 

[도움을 많이 받은 참고자료]

AWS로 배포하기 (EC2 서버 + AWS Route 53 도메인 연결 + HTTPS 인증서 등록)

 

AWS EC2 워드프레스 블로그에 SSL  적용하기