HTTP에서 HTTPS로 바꾸기 위해 내가 했던 시도들과 삽질들을 소개하려고 한다.
먼저 내가 처음으로 적용했던 SSL 인증 방식에 대해 살펴보자.
환경 : Amazon Linux 2023, AWS Certificate Manager, Route 53, ALB
SSL 인증서 적용 프로세스
-
AWS Certificate Manager : SSL 인증서를 몇번의 클릭만으로 발급해준다. 물론 발급 외에 처리해야 할 건 거의 없다. 아니 아예 없다고 봐도 된다.
-
도메인 구매 및 Route 53 : 먼저 HTTPS로 만들기 위해서는 도메인을 구매해야 하는데 무료 도메인도 있을 수도 있지만 어차피 서비스를 위해서는 도메인이 필요하다고 생각되어 구매하게 되었다.도메인은 가비아 라는 곳에서 구매했다.
구매 이후에 AWS 인스턴스와 도메인을 연결하기 위해 AWS의 Route53을 들어간다.
이런식으로 구매한 도메인을 도메인 이름에 넣게 되면 레코드가 생성되게 된다.
이런식으로 NS, SQA 레코드가 생성되게 되는데 신경써야 할 건 NS 레코드이다. 오른쪽 값/트래픽 라우팅 대상에 있는 네임서버를 가비아 상에서 도메인과 네임서버를 연결해주면 된다. 그리고 A레코드를 생성하여 인스턴스의 Public IP 혹은 탄력적 IP를 적어주면 연결된다. -
Application Load Balancer : ALB 설정을 해야된다. ALB는 특정 port로 들어왔을 때 나가는 port를 지정해줄 수 있다.
생성을 누르게 되면 3가지가 나오게 되는데 맨 Application Load Balancer를 고르자.
여기서 중요한건 Security Group과 Listener 설정이다. Security 그룹에서는 80포트와 443포트 인바운드 규칙을 열어줘야 한다.
그리고 Listener에서는 개인적으로는 443포트를 8080포트로 Forwarding하게 해줬고 80포트는 HTTP가 적용되기 때문에 HTTPS를 위해서 443포트로 Redirect 시켜줬다.
이렇게 크게 3가지를 설정하게 되면 SSL 인증서가 적용되게 된다. 다음과 같이 말이다.
아주 완벽하게 적용이 됐다! 이제 문제가 없을 것이다. 하지만.. 문제는 SSL 인증이 아니라 다른 문제에서 터지게 되는데 바로 OAuth 문제였다.
문제 상황을 정리하자면, localhost에서는 OAuth가 정상적으로 잘 작동되었고 도메인을 연결하기 전 http remote server에서도 OAuth가 잘 적용되었던 상태였다.
그런데.. ACM-Route 53-ALB 조합으로 OAuth가 어디가 잘못되었는지도 모르게 고장났다..
외부에서 주는 api 응답은 잘 됐지만 Spring 내부에서 SSL 인증서를 인식하지 못했던 문제가 발생했었다.
그래서 local과 remote의 변화한 점에 대해서 분석하기 시작했다. (조력자, King 한곤님, 승훈.. 감사합니다)
인증서를 적용했다.- 이것은 AWS 상에서 아주 편리하게 제공해주는 인증서이기 때문에 문제가 없을 거라고 생각했다.도메인- 상식적으로 도메인을 바꿨다고 OAuth의 redirection uri나 그런 것이 잘못되어 있지 않은 이상 문제가 없을 거라고 봤다..Apache(httpd)를 버리고 Nginx를 설치하였다.- 이것도 포트를 잘 열어줬었는데 어떤 디테일한 문제가 있었는지는 정확히 파악은 안되지만 문제가 없을거라고 판단이 된다. (이 문제 해결하느라 덕분에 Nginx 리버스 프록시 공부는 잘한거 같다..)
이 문제점들을 며칠 몇날이고 분석하다가 도저히 문제를 찾지 못하겠어서 ACM을 버리고 한곤님께 도움을 받아 Certbot을 이용하여 인증서를 적용하기로 마음 먹었다.
그런데 또 여기에서 문제가 발생하게 된다..
OS가 계속 업데이트 되는 Amazon Linux 2023이다. Amazon Linux 2도 아니고 말이다.. 그래서 Certbot을 설치하는 레퍼런스도 없었고 이전에 MariaDB를 설치하면서도 굉장히 곤혹을 겪었기 때문에 Amazon Linux 2023이 문제가 있나..? 라는 판단에서 조력자 두분과 함께 인스턴스를 아예 새로 갈아 끼우기로 판단했다. Amazon Linux 2로 말이다.
Amazon Linux 2로 바꾸고 Route 53도 버리고 그냥 가비아 도메인 시스템을 사용하기로 했다. A 레코드를 AWS 인스턴스 Public IP와 연결해주었다.
그리고 let's encrypt + certbot로 인증서 방식을 바꾸기로 했다.
이런식으로 말이다.. 세부적인 Nginx 설정은 필요하면 나중에 다루도록 하겠다.
최종적으로 바꾼 것을 정리하자면,
- OS (Amazon Linux 2023 -> Amazon Linux 2)
- SSL 인증 방식 (AWS Certificate Manager -> Let's encrypt + Certbot)
이 두가지로 압축할 수 있다.
그랬더니..
정상적으로 인증서도 적용된다! 그럼 OAuth를 확인해보자.
지금은 프론트 테스팅 환경으로 localhost:3000으로 바뀌었지만 callback이 login=success로 잘 들어온다!
이렇게 OAuth까지 성공시키는데 새벽 3시~4시까지 엄청나게 고생했다.. 처음부터 끝까지 뜯어보면서..
(다시 한번 Shout out Kim..)
박수를 한 100번은 친 것 같았다.
그럼 마지막으로 결론을 지어보자면, 다음과 같다.
- Amazon Linux 2023 왠만하면 쓰지 말자 : Amazon Linux 2는 yum 패키지 매니저와 굉장히 잘 연계되어 있어서 왠만한건 다 깔 수가 있다. 하지만 Amazon Linux 2023은 dnf라는 새로운 것이 생겨서 복잡할 뿐만 아니라 레퍼런스도 부족해서 거의 설치하려면 진땀을 굉장히 많이 빼야 한다..
- ACM에서 Certbot 방식으로 변경 : 근데 ACM을 다시 적용해보면 될 수도 있을 것 같은데 검증이 안됐다. 그래서 만약에 저 같이 Amazon Linux 2023을 쓰셨는데 OAuth가 고장났다? 그러면 먼저 인스턴스를 Amazon Linux 2로 바꿔보고 그 때 안된다면 ACM에서 Certbot으로 바꿔보는 것을 추천한다.
