[Infra] AWS 배포 후 도메인 연결 및 HTTPS 적용, nginx로 리버스 프록시 적용하기

🌱 들어가기 전

무과금으로 HTTPS 적용 프로젝트를 진행해보았다.

정석대로라면 가비아 + Route53 + ACM or 가비아 + nginx로만 진행하면 좋았겠지만...

여러 제약사항으로 인해서 색다른 방법으로 도메인 연결 및 HTTPS 적용을 진행해보았다.

 

💡 제약사항
- 무료 도메인 사용하기
- 서버 1대로 구축하기 (끊임없이 고통받는 t4g.micro)
- http 접속 시 https로 리다이렉트시키기

 

나중에 Route53 + ACM + ELB를 통해 도입했던 것도 포스팅으로 작성해보고자 한다. (이번 미션에서는 못 했지만 ㅠ)

 

---

 

🌱 도메인 구입하기

사실 가비아에서 구매했던 도메인이 있긴 하지만, 페어 프로그래밍을 하다 보니 나만의 도메인을 사용하기는 좀 그래서 다른 사이트를 찾아보았다. 그러다가 발견한 곳 = 내도메인.한국!

내도메인.한국 - 한글 무료 도메인 등록센터

굉장히 수상하게 생겼지만 속도도 빠르고, 적용하는 데에는 크게 무리가 없어서 여기서 구입하기로 결정하였다.

 

먼저 일반 도메인 검색창에 등록하고 싶은 도메인을 검색한다.

5번은 현재 내가 사용하고 있기 때문에 등록 불가로 뜬다 ㅎㅎ

처음에 구입하면 위와 같이 DNS 연결을 할 수 있는데, 우선 A 레코드에 AWS 인스턴스의 public IP를 작성한다.

여기서 A 레코드를 등록한다는 의미는, DNS 서버에 우리가 구매한 도메인과 IP를 연결한다는 의미인데,

journey-shop.kro.kr로 브라우저에서 접속하면 12.34.56.78 (IP)로 접속할 수 있도록 만든다는 뜻이다.

CNAME은 추후 설정할 예정이지만, 해당 도메인에 대한 별칭을 지정한다는 의미 정도로 생각하면 된다.

 

등록하고 journey-shop.kro.kr:8080/admin으로 접속하게 되면 위와 같이 멋진 창이 뜨게 된다.

더 이상 IP 주소로 접근하지 않고, 사람에게 익숙한 도메인명으로 사이트에 접속이 가능한 것이다.

 

---

 

🌱 HTTPS 연동하기

하지만, 위에서 진행한 과정은 IP 대신에 단순히 도메인명을 사용했을 뿐이다. 

우리가 네이버에 접속할 때 naver.com:8080과 같이 접속하지 않는 것처럼, 포트 번호 없이, https 환경으로 접속하고 싶을 것이다.

(또한, 프론트엔드 서버가 배포 서버라면 https -> http는 CORS에 의해서 통신이 불가능하다 🥲)

그래서 이번에는 간단하게 https를 적용해보고자 한다.

 

https는 암호화된 프로토콜이다. 그렇기 때문에 신뢰된 기관이 제공해주는 인증서가 필요하다.

처음에는 certbot을 사용하려고 했으나... 무료 도메인을 사용하다 보니 kro.kr로 요청이 너무 많이 들어와서 당장 처리할 수 없다는 오류가 발생하고 말았다.

too many certificates already issued for "kro.kr"

그래서 1시간 정도 처음에는 기다리려고 했지만, 바로 진행하고 싶어서 결국 포기...

 

혹시 하고 싶다면 아래와 같이 진행해주면 된다.

sudo apt update

# certbot 설치
sudo apt install certbot

# www의 경우 선택사항
sudo certbot certonly --standalone -d journey-shop.kro.kr -d www.journey-shop.kro.kr

# 인증서 파일 확인
sudo ls /etc/letsencrypt/live/journey-shop.kro.kr/
cert.pem  chain.pem  fullchain.pem  privkey.pem

 

아무튼, 어떤 방법을 사용할지 고민하다가 SSL for Free이라는 사이트를 발견하였다.

SSL For Free - Free SSL Certificates in Minutes

가입하고 나서 Domain 입력해주고, Validity에 90일, Auto-Generate CSR을 켜주면 된다.

그리고, 악의적인 사람이 내 도메인에 대해서 멋대로 접근할 수 있기 때문에 journey.kro.kr이 정말 SSL 발급자의 소유 도메인인지 확인하기 위해 3가지의 인증 방법이 주어진다. (메일 인증, DNS, HTTP File upload)

 

메일 인증의 경우 내도메인.한국을 사용했다 보니 kro.kr의 소유주의 이메일로 전송되기 때문에 사용할 수 없었다.

File upload의 경우 우리의 스프링 부트 서버에 ssl for free에서 지정해준 경로에 파일을 업로드 후 배포하여, 해당 url로 이 사이트가 GET 요청을 보내 health checking을 진행하는 방식인데, 프로덕션 코드가 더럽혀지는 게 싫어서 패스하였다.

그래서 마지막 방법으로, 이 사이트에서 지정한 CNAME을 우리의 도메인에 연결하여 소유권을 검증하는 방법을 채택하였다.

위에서 주어진 NAME, Point to를 각각 입력해주면 된다.

 

다 진행했다면 verify Domain을 클릭해주고, 아래와 같이 문제 없다고 뜬다면 성공이다.

그리고, Certificate 파일을 다운로드 받아야 하는데 'Ubuntu'으로 설정한 다음 다운로드 받았다. 

 

그러면 3가지의 파일을 받을 수 있는데, ca_bundle.crt, certificate.crt, private.key를 얻게 된다.

ca_bundle.crt (= chain.pem)
 : 인증 체인이나 중간 인증 기관의 인증서들을 포함한다.
인증 체인은 인증서 발급 기관에서 최상위 인증 기관까지 계층적 구조로 구성되며, 서버 인증서와 함께 제종되는 CA의 인증서 체인을 의미한다. 보통 클라이언트가 인증서를 검증할 때 사용한다.

certificate.crt (= fullchain.pem)
: 서버의 SSL / TLS 인증서를 포함하며, 웹 서버에 설치되는 인증서이다.
서버의 공개키와 서버 정보가 포함되어 있다.

private.key (= privkey.pem)
: 서버의 개인 키를 포함하며, 서버 측에서 인증서와 매칭되는 일종의 비밀 키이다.
SSL / TLS의 암복호화에서 사용되기 때문에 외부에 노출돼서는 안 된다.

 

하지만, 추후 nginx에서 인증서를 등록하기 위해서는 crt 파일 형식이 아닌 pem 키 형식이 필요하기 때문에 별도로 변환하는 작업이 필요하다.

openssl x509 -inform PEM -in certificate.crt > certificate.pem

 

그래서, 서버의 인증서를 openssl을 통해서 pem 형식으로 변환해주었다.

 

마지막으로 인증서와 키를 내 ec2 쪽으로 옮겨보자.

scp -i {EC2 접속을 위한 키} certificate.pem ubuntu@{EC2 public IP}:{이동할 path}
scp -i {EC2 접속을 위한 키} private.key ubuntu@{EC2 public IP}:{이동할 path}

요렇게 하면 사전 준비는 완료된다!

 

---

 

🌱 Nginx로 리버스 프록시 진행하기

리버스 프록시는 서버의 앞단에서 사용자의 요청을 받아 적절한 위치로 포워딩시키는 것을 말한다.

우리는 여기서 'nginx'라는 친구를 이용해서 http로 온 요청을 https로 바꾸는 작업을 진행해보고자 한다 😊

 

sudo apt install nginx

먼저, nginx를 설치해준다.

sudo ufw enable
sudo ufw status

그리고, 방화벽에 대한 설정을 해줘야 하는데, 우분투는 ufw 방화벽을 사용한다.

기본적으로 비활성화되어 있기 때문에 enable을 통해서 활성화 시켜준다. 이러면 모든 포트가 자동적으로 막히게 된다.

status를 통해 현재 어떤 포트가 열려있는지 확인할 수 있다.

중간에 캡쳐한 거여서 몇몇이 열려있다.

 

sudo ufw allow ssh
sudo ufw allow 'Nginx Full'
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 8080/tcp

나는 다음과 같이 ssh, nginx Full (사실 이게 80이랑 443 열어주긴 함), 80, 443, 8080을 열어주었다.

 

sudo systemctl start nginx
sudo systemctl status nginx

그리고, 잘 가동되는지 확인하기 위해 restart 후 status를 확인한다.

요런 식으로 Active가 떴다면 성공이다.

나중에는 restart 옵션을 많이 사용할 텐데, status로 항상 상태를 함께 확인하는 것을 추천한다.

 

그리고, 이제 포워딩 옵션을 주기 위해서 /etc/nginx/site-enabled로 이동한다.

거기로 가면 'default'라는 파일이 있을 텐데, 해당 파일을 vi로 수정한다. 

cd /etc/nginx/site-enabled
sudo vi default

server {
	listen 80 default_server;
	listen [::]:80 default_server;

	listen 443 ssl default_server;
	listen [::]:443 ssl default_server;

	root /var/www/html;

	index index.html index.htm index.nginx-debian.html;

	server_name journey-shop.kro.kr;
	ssl_certificate /home/ubuntu/certificate.pem;
	ssl_certificate_key /home/ubuntu/private.key;
	ssl_prefer_server_ciphers on;

	location / {
          proxy_pass http://localhost:8080;
          proxy_set_header X-Real_IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header Host $http_host;
	}
}


server {
  listen 80;
  server_name journey-shop.kro.kr;
  return 301 https://$host$request_uri;
}

보기만 해도 어지럽기 때문에 하나씩 쪼개서 확인해보자.

 

---

 

🌱 Nginx 설정 파일 분석하기

여기서 default_server라는 친구를 확인할 수 있다.

nginx에서 어떤 포트로 요청이 들어왔을 때 지정한 server 블록을 기본으로 설정하겠다는 의미이며, 만약 지정하지 않은 경우 요청에 대해 가장 구체적인 서버 블록을 찾으려고 매칭을 시도한다.

⭐️ 여기서, 기본 서버 블록이라는 건 아무것도 매칭되지 않을 때 사용한다는 의미이다.

 

1. 요청한 호스트 이름과 일치하는 server_name 지시문이 있는 서버 블록 지정
2. 요청된 호스트 이름과 일치하는 와일드카드 server_name 지시문이 있는 서버 블록 지정
3. 기본 서버 블록 (default_server)

 

예를 들어서, journey-shop.kro.kr으로 요청이 들어온다면 다음과 같은 순서로 매칭된다.

server {
    listen 80;
    server_name *.journey-shop.kro.kr;
}

server {
    listen 80;
    server_name *.journey-shop.kro.kr;
}

server {
    listen 80 default_server;
}

이렇게 3개의 서버 블록이 있다면 가장 구체적인 첫 번째 블록이 선택될 것이며, 만약 첫 번째 블록이 잘못되었다면 두 번째 블록으로, 두 번째 블록도 잘못되었다면 default_server로 설정되어 있는 세 번째 블록이 선택된다.

 

 

사실 이 부분은 기본으로 제공하는 부분을 별도로 건들지 않았다.

root의 경우 정적 파일에 대한 기본 경로이기 때문에, journey-shop.kro.kr/index.html 요청이 들어온다면  /var/www/html/index.html에서 파일을 찾게 된다.

index의 경우, request에 아무 파일도 지정하지 않은 상태로 요청이 들어온다면 /var/www/html/index, /var/www/html/index.html, /var/www/html/index.htm, /var/www/html/index.nginx-debian.html 파일을 순서대로 찾으며 반환한다.

 

 

server_name에는 여러 도메인을 지정할 수 있다.

# 2개의 도메인에 대해서 처리
server_name journey-shop.kro.kr www.journey-shop.kro.kr

# .journey-shop.kro.kr과 동일하다. 서브도메인에 대한 요청을 처리할 수 있다.
server_name *.journey-shop.kro.kr

# 특정 이름으로 시작하는 도메인에 대한 요청을 처리할 수 있다.
server_name journey-shop.kro.kr.*

참고로, nginx의 경우 단순히 HTTP 헤더에 있는 이름을 통해 요청에 응답하기 때문에 도메인 이름이 유효한지는 알 수 없다.

그래서 유효하지 않은 도메인 이름을 server_name에 지정할 수도 있다. (물론 에러 페이지로 가겠지만?)

 

 

아까 crt를 통해 보냈던 인증서와 키를 여기에서 지정해준다.

가장 마지막 옵션의 경우 서버에서 지정한 암호화 알고리즘을 우선한다는 의미이며, off로 설정하면 외부에서 약화된 알고리즘을 사용하여 공격할 수 있기 때문에 웬만하면 키는 게 좋다.

참고로, ssl_protocols을 통해 프로토콜을 지정하거나 ssl_ciphers를 통해 알고리즘 지정도 가능하다.

 

 

여기서 proxy_pass를 통해 http, https로 들어온 요청에 대해서 우리가 스프링부트를 띄운 8080으로 포워딩되도록 설정하였다.

즉, 백엔드 서버로 요청을 보낸다고 생각하면 된다.

 

여기서 호스트 이름이 조금 헷갈렸었는데, 사용자가 journey-shop.kro.kr에 접속했을 때 남는 http 헤더의 host 값 = journey-shop.kro.kr을 프록시 헤더로 지정해주는 것이었다. 즉, 클라이언트가 어디로 요청을 보냈는지 기록하는 것이라고 볼 수 있다.

 

 

가장 마지막 블록이다!

위에서 설명했던 것처럼 journey-shop.kro.kr로 요청이 들어오면 가장 구체적인 server_name이 지정된 이 블록이 매칭된다.

나는 http 요청을 모두 https로 리다이렉트 시키기 위해서 위와 같이 만들어주었다.

 

host의 경우 클라이언트의 요청에서 Host 헤더 값을 의미하며, request_uri는 클라이언트가 요청한 URI이다.

nginx에서 자동으로 설정해주는 값이기 때문에 별도로 재정의할 필요는 없다.

 

💡 참고로, URI의 경우 쿼리 파라미터도 포함한다.
ex) https://journey-shop.kro.kr/products?name='치킨'

host: https://journey-shop.kro.kr
request_uri: journey-shop.kro.kr/products?name='치킨'

 

다 끝났다! 이제 브라우저에서 journey-shop.kro.kr/admin로 들어가면 바로 https로 디라이렉트된다!

 

---

 

사실 캠퍼스에서 썼어야 했는데... 

다 못 써서 뒤늦게 기억을 의존하여 작성하였다 😅

캠퍼스 등교하면 www도 추가해야겠다 ^^...