ACM(Amazon Certificate Manager)를 사용해서 https 접속이 되지 않을때

REQUEST -> Domain -> Load Balancer -> instance(443->80) -> RESPONSE 순서로 요청이 실행되는데 단계별로 하나씩 확인해보면 된다.

체크사항

Elastic IP와는 관련이 없음

처음에 Elastic IP(탄력적 IP)를 적용하고 있어서 안되는 줄 알앗는데, 그런 건 아니었다.

Elastic IP 설정후 테스트해보고 릴리즈 후 테스트해보고 다 해봤는데 Elastic IP는 관련이 없었다..

로드밸런서의 InService 상태 확인

여기는 InService 상태로 되어 있는데, OutService 상태로 되어 있으면 안되는 것 같다.

health check를 해서 200 응답 코드를 받는지 확인 해서 InService상태로 바꾸고 이때부터 정상적으로 된다.

상태 검사 탭을 들어가서 설정을 확인해 보자. app에서도 해당 상태 검사를 할 수 있는 route가 제공이 되어야 한다.

로드 밸런서 리스너

로드 밸런서의 리스너 목록에 다음과 같이 되어 있어야 한다.

HTTPS(443) -> HTTP(80), 인증서(ACM을 통해 발급 받은 것) 등록

HTTP(80) -> HTTP(80) (사실 없어도 문제 없음.)

ROUTE 53 도메인 설정

도메인이 sub1.sub2.domain.com 과 같이 여러 도메인으로 되어 있는 경우 적용이 안된다. AWS acm-certificate 문서의 Wildcard Names 부분에, 이렇게 명시되어 있다.

*.example.com can protect login.example.com and test.example.com, but it cannot protect test.login.example.com. *.example.com 인 경우 login.example.com, test.example.com은 보호할 수 있는데, test.login.example.com는 적용 불가능하다.

그래서, ROUTE 53에서 A Record 등록할 때 서브도메인의 서브도메인(?)은 등록할 수 없으니 example.com 또는 sub.example.com 형태로만 등록해야 한다.

node 프로세스 실행 상태 확인

로드밸런서 확인, route53, elastic ip 등 여러번 확인하면서 node가 켜진 상태로 ssh가 강제 종료 되는 경우가 종종 있다. 어쩌면 node 프로세스가 켜져 있는 상태여서 테스트가 잘 안되는 거일 수도 있다. ps -e 명령어로 node가 실행중인지, 또는 기타(nodemon, supervisor 등)가 켜져 있는지 확인하고, 좌측 프로세스 ID 숫자를 확인해서 sudo kill 프로세스ID 로 해당 프로세스를 종료 해주자. 그리고 다시 시작해주자.