20240905 TIL: 서버 http -> https로 바꾸기

✅ 오늘 배운 것

어제 나름의 시도를 했는데 아직 서버를 HTTPS로 띄우지 못해서, 추가적으로 무엇을 더 할 수 있을지를 알아보았다. 두 가지로 추가로 체크할 사항이 있었다. 첫 번째는 SNI 설정을 통해 하나의 서버가 여러 도메인에 대해 여러 개의 인증서를 제공하도록 해야 했다. 왜냐하면 현재 서브도메인으로 등록된 개발 서버는 HTTPS로 잘 연결되는 상황인데 프로덕션 서버만 HTTP로 연결되는 상황이라, 서버에서 각 도메인에 맞는 인증서를 제공해야 했다. 

 

이를 확인하려면 로드밸런서에 SNI 설정이 잘 되어있는지를 확인해야 했다. 즉 'SNI용 리스너 인증서'가 설정되었는지를 확인했다. 어제 등록한 인증서가 나와 있었다. 

 

두 번째는 ACM 인증서가 현재 도메인을 지원하고 있는지였다. 사용하고 있는 ACM 인증서에 가서 '도메인' 쪽을 보았더니, 앞에 와일드카드(*)가 붙은 도메인을 전부 지원하고 있었다. 

 

그렇다면 다시 문제의 원인을 생각해 보자. 문제가 있을 만한 부분은 Route53, ACM 인증서, ELB의 리스너 등이다. 그런데 서브도메인은 잘 연결되고 그냥 도메인이 잘 연결되지 않는다면, 둘 다 공통적으로 사용하고 있는 ACM 인증서에는 문제가 없을 확률이 높다. 즉 Route53과 ELB의 리스너에 문제가 있을 확률이 높다. 

 

우선 ELB의 리스너 쪽을 보았다. 개발서버의 ELB 리스너와, 프로덕션 서버의 ELB 리스너를 보고 하나씩 설정을 비교해보기로 했다. '보안 정책'의 필드 부분에서 다른 부분이 있었다. 

개발 서버

프로덕션 서버

프로덕션 서버에서 사용하는 설정을 개발 서버와 똑같이 맞춰주었다. 프로덕션 로드밸런서의 보안 그룹도 개발 로드밸런서의 보안 그룹과 동일한 것으로 바꿔 주었다. 여전히 되지 않았다. 

 

그랬는데 팀원들과 얘기하던 와중 프로덕션 서버의 HTTPS 리스너에서 사용하는 인증서에는 인증서에 와일드카드(*)가 포함되어 있었는데, *.domain.com은 domain.com을 포함하지 않냐는 얘기가 나왔다. 찾아보니 *.domain.com은 domain.com을 포함하지 않았다! 즉 지금까지 ACM에서 사용하던 SSL/TLS 인증서는 전부 서브도메인이 있는 URL에서만 유효한 인증서였던 것이다. 

 

그래서 새로 ACM에서 domain.com에 해당하는 인증서를 만들어주고, 해당 인증서를 HTTPS 리스너에 할당해 주었더니 문제가 바로 해결되었다!! 

---

이제 안심하고 context switching을 해 보자. 다음은 디자인을 새로 해야 한다.