항해99 11주차 WIL - Https 와 NginX

Ming-Gry·2022년 12월 4일

항해99 WIL

목록 보기

11/12

실전프로젝트 4주차에 우리를 가장 괴롭혔던 Https 와 NginX 에 대해 써보고자 한다. 백엔드는 물론 프론트엔드의 Https 배포도 AWS 에서 인증서 발급이 되지 않는다는 심각한 문제가 있어서 정말 고생을 많이했다... 결국 프론트엔드는 CloudType 이라는 서비스를 이용해 비교적 손쉽게 배포할 수 있었으나 백엔드는 NginX 설정에 엄청 애를 먹어서 결코 쉽지 않았던 것 같다.

결국 우리가 사용한 NginX 설정에 대한 포스팅을 하기에 앞서 Https 와 NginX 에 대해 먼저 알아보도록 하자.

1) Https

1-1) Https 란?

Https 란 HyperText Transfer Protocol over Secure Socket Layer 의 약자로, Http over SSL, Http over TLS, Http Secure 로 불리기도 한다. 암호화된 Http Protocol 이라는 뜻으로 SSL / TLS 로 Http 통신을 암호화해 악의적인 사용자로부터 Http 통신을 보호하는 방식을 말한다.

로그인, 비밀번호 변경, 결제 등의 민감한 정보가 단순 Http 로 전송되는 경우가 있다고 가정해보자. Http 는 평문 데이터 전송이기 때문에 악의적인 사용자가 이 Http 통신을 가로챈다면 Http Body, Header 등에 들어있는 민감한 정보가 유출될 가능성이 있다.

위의 사진의 자물쇠 모양이 Https 가 적용되었음을 알려주고 있다.

Https 는 과거에도 있긴 했지만 2014년 구글에서 Https 를 적용한 사이트에 대해 SEO(검색 엔진 최적화) 가산점을 주는 정책으로 인해 더욱 보편화되었다.

1-2) SSL / TLS

SSL 과 TLS 가 무엇이길래 Http 통신을 암호화할 수 있을까?

SSL 은 Secure Socket Layer 의 약자로, 보안 소켓 계층이라는 뜻이다. 인터넷 상에서 데이터를 안전하게 전송하기 위한 인터넷 암호화 통신 프로토콜로써 데이터 보안을 위해서 개발된 통신 레이어다.

이는 Netscape 社 가 1995년 처음 개발하였는데, 이를 IETF(국제 인터넷 표준화 기구) 에서 인터넷 표준화 시킨 것이 TLS 이다. 오늘날 SSL 로 불리는 것은 모두 TLS 이며 같은 의미로 통용되곤 한다.

SSL 프로토콜은 OSI 7계층 모델의 어느 한 계층에서 동작한다기 보다는 응용계층과 전송계층 사이에 독립적인 프로토콜 계층을 만들어서 동작한다. 응용계층의 프로토콜들은 TCP 가 아닌 SSL 에 보내지고, SSL 은 응용계층에서 받은 데이터를 암호화하여 TCP 로 전달한다. 전달 받을 때 역시 TCP 로부터 받은 데이터를 복호화해 응용계층에 전달한다.

그래서 URL 도 Http:// 가 아닌 Https:// 로 시작하며, 기본 포트 번호도 80이 아닌 443을 사용한다.

아래는 이를 이해하기 위해 참고하면 좋을 자료들이다.

[10분 테코톡] 👶에단의 TLS : https://www.youtube.com/watch?v=EPcQqkqqouk
[10분 테코톡] 🔮 히히의 OSI 7 Layer : https://www.youtube.com/watch?v=1pfTxp25MA8&list=PLq6YHA1IXXnknjlwxAJqW7oq6pNjcOgwT&index=61
[네트워크] OSI 7계층 : https://yjkim97.tistory.com/35
[네트워크] 전송 계층 : https://velog.io/@gndan4/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EC%A0%84%EC%86%A1-%EA%B3%84%EC%B8%B5
[네트워크] 응용 계층 : https://velog.io/@gndan4/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EC%9D%91%EC%9A%A9-%EA%B3%84%EC%B8%B5

1-3) Https 동작 과정

Https 에서는 대칭키, 비대칭키가 모두 사용되는데 암호화 관련 기술이므로 이에 대한 추가적인 내용은 아래를 참고하도록 하자.

[10분 테코톡] 🔐 마갸의 암호 : https://www.youtube.com/watch?v=itehKMMBVjc
암호화 알고리즘 종류 : https://jusungpark.tistory.com/34
[Programming] 암호화 알고리즘 종류와 분류 : https://velog.io/@inyong_pang/Programming-%EC%95%94%ED%98%B8%ED%99%94-%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98-%EC%A2%85%EB%A5%98%EC%99%80-%EB%B6%84%EB%A5%98

대칭키와 비대칭키

대칭키는 클라이언트와 서버가 동일한 키를 사용해 암호화와 복호화를 진행한다. 동일한 키로 암호화와 복호화를 모두 진행하기 때문에 키가 노출되면 정보가 탈취될 위험이 있지만 연산속도는 빠르다.

비대칭키는 1개의 쌍으로 구성된 공개키와 개인키로 암호화와 복호화를 한다. 공개키는 말 그대로 모두에게 공개 가능한 키이고, 개인키는 자신만 알고 있어야 하는 하나의 고유한 키이다. 대칭키와 다르게 공개키로 암호화를 하면 개인키로만 복호화할 수 있으며, 개인키로 암호화할 경우 공개키로만 복호화가 가능하다.

CA

CA 는 Certificate Authority 의 약자로, SSL 인증서를 발급해주는 기관을 말한다. 이 인증서는 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지 보장하는 역할을 한다. 아무나 쉽게 CA 가 될 수 있는 것도 아닐 뿐더러 CA 목록들은 크롬, 엣지, IE 등 브라우저에 내장되어 있어 SSL 인증서가 CA 에서 발급된 것이 맞는지 검증해준다.

SSL 인증서에는 서비스의 정보 (인증서를 발급한 CA, 서비스의 도메인 등) 과 서버 측 공개키 (공개키의 내용, 공개키의 암호화 방법) 가 포함되어 있다. 또한 CA 는 서버 측에서 사용할 비밀키까지 발급해준다.

더 자세히 알아보기

Https 에 대칭키와 비대칭키가 사용되고, SSL 인증서에는 어떠한 내용이 담기는지까지 확인했다. 이제 진짜 Https 가 어떻게 동작하는지 확인해보자. 여기서 대칭키와 비대칭키(공개키와 개인키) 가 굉장히 헷갈릴 수 있으므로 이에 유념하도록 하자.

글로는 잘 이해가 되지 않는다면 얄코님의 영상을 참고하도록 하자.

HTTPS가 뭐고 왜 쓰나요? (Feat. 대칭키 vs. 비대칭키) : https://youtu.be/H6lpFRpyl14?t=453

Https 통신은 Handshake, Session, Session 종료의 단계로 이루어진다.
먼저, Handshake 단계이다.

Handshake

클라이언트가 서버에 접속, 클라이언트는 서버에 아래의 정보를 전달한다.
- 클라이언트 측에서 생성한 랜덤 데이터 (Handshake 3번에서 사용)
- 클라이언트가 지원하는 암호화 방식들 (클라이언트와 서버가 지원하는 암호화 방식이 다를 수 있기 때문)
- 세션아이디 (이미 SSL Handshake 을 했다면 비용과 시간을 줄이기 위해 사용)
서버가 클라이언트에 대해 응답, 서버는 클라이언트에 아래의 정보를 전달한다.
- 서버 측에서 생성한 랜덤 데이터 (마찬가지로 Handshake 3번에서 사용)
- 서버가 선택한 암호화 방식 (클라이언트가 지원하는 암호화 방식 중 서버 측에서도 사용가능한 암호화 방식을 선택해 보냄)
- SSL 인증서
서버에서 보낸 SSL 인증서가 CA 에 의해서 발급된 것인지 확인 후 서버에 대칭키 전송
- 브라우저에 내장된 CA 목록을 확인
- CA 목록과 일치하면 브라우저에 내장된 CA 의 공개키를 이용해 인증서 복호화 (SSL 인증서는 CA 의 개인키로 암호화되어 있음)
- 서버와 클라이언트에서 생성한 랜덤 데이터를 조합해 대칭키(Pre Master Secret) 생성
- 대칭키를 SSL 인증서 내에 포함된 서버의 공개키로 암호화
클라이언트가 전송한 Pre Master Secret 를 개인키로 복호화 후 Master Secret 값으로 만들어 Session Key 생성 → Session Key 값을 이용해 데이터를 대칭키 방식으로 암호화하여 데이터를 주고 받는다.
Handshake 종료

생각보다 복잡한 과정이 소요된다. 여기에서 중요한 것은, 대칭키와 비대칭키가 혼합되어 사용된다는 점이다. 매번 비대칭키를 사용하지 않는 것은 역시나 비용과 시간 때문이다. 대신 3번에서 보듯이 클라이언트에서 서버로 대칭키를 보낼 때 서버의 공개키를 이용해 비대칭키 방식으로 암호화해 보내는 방식을 사용한다.

Session

실제로 서버와 클라이언트가 데이터를 주고 받는 단계이다. 위에서 생성한 Session Key 값을 이용해 대칭키 방식으로 데이터를 암호화 한다.

Session 종료

데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알리고 대칭키인 Session Key 를 폐기한다.

2) NginX

2-1) NginX 란?

NginX 란 트래픽이 많은 WAS 를 도와주기 위해 개발된 이벤트 기반 구조의 경량화 Web Server이다. 라고 단순하게 정의할 순 있겠지만 먼저 Web Server 와 WAS 가 어떤 것인지 알아보고 NginX 의 탄생 배경을 살펴봄으로써 NginX 가 지원하는 다양한 기능에 대해 알아보자.

2-2) WebServer 와 WAS

정적 페이지와 동적 페이지

웹페이지는 정해진 url 에 http 요청을 보내면 그에 맞는 html 을 내려받는 식으로 작동한다. 여기서 웹페이지는 동작 방식에 따라 정적 페이지냐 동적 페이지냐로 나뉠 수 있다.

정적 페이지

정적 페이지는 아래의 그림과 같이 파일 경로에 해당하는 컨텐츠를 응답받는다. 예를 들면 어느 회사 홈페이지의 회사 소개 페이지와 같이 항상 동일한 페이지를 띄워주는 것이다. 항상 동일한 페이지를 띄워주면 되기 때문에 html, css, image 파일과 같은 파일들을 띄워주면 된다.

동적 페이지

반면 동적 페이지는 요청하는 내용에 맞게 동적인 컨텐츠를 응답받는다. 사진에서 보다시피 uid=abc 혹은 uid=user2 와 같이 특정 값에 해당하는 컨텐츠가 반환되어 페이지화 되는 것이다. 예를 들면 게시판에 뼈대는 같지만 글 마다 다른 내용이 들어가는 것 혹은 계속 새로운 내용이 업데이트 되는 특정 유저의 SNS 화면 같은 경우가 이에 해당할 수 있다.

자세한 내용은 아래의 영상을 참고하면 이해가 더욱 쉽게될 것이다.

정적 웹은 뭐고 동적 웹은 뭔가요? : https://www.youtube.com/watch?v=C06xRvXIAUk

WebServer 와 WAS 의 차이

쉽게 말하면 WebServer 는 정적 컨텐츠를 전달하는 서버이고, WAS 는 동적 컨텐츠를 전달하는 서버이다. 다시 말해 WAS 는 DB 조회나 다양한 로직 처리가 된 동적 컨텐츠를 전달하는 셈이다.

WebServer

웹 서버를 사용하는 데에는 크게 두 가지 방법이 있다. 첫째는 위에서 말했듯이 WAS 를 거치지 않고 바로 정적 컨텐츠를 전달하는 서버이고, 두 번째는 클라이언트의 요청을 WAS 로 보내어 WAS 가 처리한 결과를 응답하여 WAS 의 기능을 보조하는 것이다.

가장 대표적인 웹 서버로는 Apache 와 NginX 정도를 들 수 있을 것이다.

WAS

WAS 는 Web Server 와 Web Container 로 이루어져, 정적 페이지에서 담기 어려운 비즈니스 로직이나 DB 조회 같은 동적 컨텐츠를 제공한다.

내가 사용했던 SpringBoot 의 Apache Tomcat 의 경우, 웹 서버는 Apache 가 담당하고 WAS 는 Tomcat 이 담당하는 격이다.

그렇다면 웹 서버는 프론트엔드 서버, WAS 는 백엔드 서버라고 정의할 수 있을까? 솔직히 말하면 이 부분에 대한 대답이 굉장히 모호하다. Apache 와 NginX 에서 제공하는 기능이 다르고, 프론트엔드에서 동적 컨텐츠를 제공할 수도 있기 때문에 명확하게 딱 정의를 내릴 수는 없는 것 같다.

확실한 건 정적 컨텐츠를 담당하는 쪽이 웹 서버이고, 비즈니스 로직을 담당하여 동적 컨텐츠를 담당하는 부분이 WAS 라는 것이라고 생각한다. ~~이에 대한 답을 아시는 분은 댓글 남겨주세요...!!~~

웹 서버와 WAS 관련 내용은 아래의 영상을 통해 조금 더 자세히 알아보도록 하자.

[10분 테코톡] 👳‍♂️ 알리의 Web Server vs WAS : https://www.youtube.com/watch?v=mcnJcjbfjrs&list=PLq6YHA1IXXnknjlwxAJqW7oq6pNjcOgwT&index=2

그렇다면 내가 사용했던 SpringBoot 에 Apache Tomcat 에는 Apache 라고 하는 웹 서버가 있는 데 왜 굳이 여기에 NginX 를 사용해야 했을까?

이에 대한 답은 아래를 보며 확인해보도록 하자.

2-3) NginX 의 탄생 배경

결론부터 말하자면, NginX 는 90년대 후반부터 200년대 초반을 주름잡던 Apache Server 를 보조하기 위해 만들어졌다.

Apache Server 는 과거 Unix 기반의 NCSA HTTPd 라는 서버를 보완하여 만들어진 서버였다. Apache Server 가 인기가 많았던 이유 중 하나는 다양한 모듈을 만들어 서버에 빠르게 기능을 추가할 수 있다는 장점이 있었다. 그러나 이것이 나중에 발목을 잡는 하나의 요소가 된다.

또한 Apache Server 는 프로세스 / 스레드 기반의 방식으로 처리했다.

클라이언트의 요청이 올 때마다 Connection 을 형성하기 위해 Process 를 할당하는 방식이다. 이는 Unix 계열 OS 가 Connection 을 형성하는 모델과 같다고 한다. 그러나 Process 를 만드는 데에는 시간이 오래 걸리기 때문에 미리 Process 를 만들어 새로운 Connection 이 생성되면 미리 만들어놓은 Process 를 할당해주게 되었다.

그러나 밀레니엄을 맞는 1999년에 컴퓨터의 보급이 확장되면서 서버에 연결된 Connection 이 늘어나고 C10K(Connection 10,000 Problem) 문제가 발생된다. 동시에 연결된 Connection 이 만 단위를 넘어가는 순간 서버가 더 이상 Connection 을 생성하지 못하는 것이었다.

자세한 C10K 의 이유는 아래와 같다.

메모리 부족 : 동시에 연결된 Connection 이 많아져 생성된 Process 가 많아짐

무거운 프로그램 : 다양한 모듈로 인해 Process 가 차지하는 리소스가 부족해짐

CPU 부하 증가 : 많은 Connection 에서 요청이 들어와 Context Switching 횟수가 증가함

이러한 Apache 의 문제점을 보완하기 위해 2004년, 드디어 NginX 가 세상에 나왔다. Apache Server 앞에 NginX 를 둠으로써 수 많은 Connection 을 NginX 가 대신하여 Apache Server 의 부하를 낮추기 위함이었다.

NginX 자체가 웹 서버의 역할도 하기 때문에 정적 컨텐츠는 자체적으로 처리하고 동적 컨텐츠가 필요할 때만 Apache Server 에 데이터를 요청하는 방식으로 동작했다.

2-4) NginX 의 구조와 프로세스 관리

NginX 가 이렇게 동시 Connection 을 유지할 수 있는 비결은 NginX 의 구조와 프로세스 관리에 있다고 할 수 있다.

위 사진에서 보는 것과 같이 NginX 는 설정 파일을 읽고 설정에 맞게 Worker Process 를 생성하는 Master Process 와 실제 일을 하는 Worker Process 로 구성되어 있다.

Worker Process 는 Listen 소켓을 배정받아 새로운 클라이언트의 요청이 들어오면 Connection 을 형성하고 처리한다. Connection 은 Keep-Alive 시간만큼 유지되지만 Apache Server 와 다르게 Connection 이 생성되었다고 해서 Worker Process 가 해당 Connection 만 붙잡고 있는 것은 아니다.

위 사진과 같이 형성된 Connection 으로부터 어떠한 요청도 없다면 새로운 Connection 을 형성하거나 이미 만들어진 다른 Connection 으로부터 들어온 요청을 처리한다. NginX 에서는 이러한 Connection 형성과 제거, 그리고 새로운 요청을 처리하는 것을 Event 라고 한다.

이 이벤트들은 OS 커널이 큐 형식으로 Worker Process 에 전달한다. 이렇게 Worker Process 가 계속 일하게 하는 데, 기존 Apache Server 와 달리 유휴 Process 가 크게 줄어 Process 를 더욱 효율적으로 사용하게 되는 것이다.

또한 Disk I/O 와 같이 시간이 오래걸리는 작업의 경우에는 Thread Pool 에 작업을 위임하고 다음 Event 를 처리하기도 한다.

Apache Server 가 Connection 에 Process 를 할당해 위와 같은 구조로 요청을 처리했다면,

NginX 는 여러 개의 Connection 을 Event 방식으로 비동기 처리하는 방식으로 움직이기 때문에 2-1) 에서 서술한 것과 같이 경량화된 Web Server 로 사용할 수 있게 되었다.

NginX 의 역사와 구조 관련 내용은 아래의 영상을 참고하도록 하자.

[10분 테코톡] 🤫 피케이의 Nginx : https://www.youtube.com/watch?v=6FAwAXXj5N0

2-5) NginX 의 다양한 기능

NginX 는 WAS 를 지원하기 위해 다양한 기능을 제공하는 데, 그 중 대표적인 기능 세 가지에 대해 서술해보고자 한다.

리버스 프록시

프록시란 대리자라는 뜻으로, 프록시 객체나 프록시 서버 등을 예로 들 수 있겠다. 여기서 리버스 프록시란 프록시 서버의 한 방식으로 서버 앞에서 중계 및 대리 역할을 하는 서버를 말한다. 반대로 포워드 프록시는 클라이언트의 중계 및 대리 역할을 한다.

포워드 프록시는 로컬 네트워크와 인터넷을 오가는 트래픽을 가로채는 것을 말한다. 학창시절에 컴퓨터실이나 회사 등에서 유해 사이트나 게임 사이트에 들어가지 못하도록 막는 역할을 하는 것을 떠올리면 쉽게 이해할 수 있을 것 같다.

리버스 프록시는 위에서 말했듯이 서버와 인터넷 사이에 위치해서 서버의 요청이나 응답을 대신 받아 처리하는 방식이다. 클라이언트는 리버스 프록시 서버에 요청을 하기 때문에 실제 서버의 IP 를 감출 수 있고, 이를 통해 보안을 높일 수 있다.

로드 밸런싱

이렇듯 리버스 프록시 서버에서 요청을 가로채기 때문에 부하 분산 역할도 가능하다. 한 대의 서버로 감당하기 힘든 트래픽이 몰린다면 다른 서버로 요청을 분산시켜 부하를 줄이는 것이다.

리버스 프록시, 로드 밸런싱 관련 내용은 아래의 영상을 참고해보도록 하자.

[10분 테코톡] 🌟조앤의 Forward Proxy vs Reverse Proxy vs Load Balancer
: https://www.youtube.com/watch?v=u4O4zHdiFhk&list=PLq6YHA1IXXnknjlwxAJqW7oq6pNjcOgwT&index=11

SSL Termination

위의 사진은 NginX 관련 설명은 아니지만 SSL Termination 관련 설명이 잘되어 있는 것 같아 가져왔다. 위에서 설명했듯이 Https 연결 과정은 생각보다 복잡한 과정을 수반한다. 따라서 각 WAS 에 SSL 인증서를 두는 것보다 리버스 프록시 서버에 SSL 인증서를 두는 방법을 사용하는 것이다. 이렇게 된다면 클라이언트와 리버스 프록시 서버 간에는 Https 통신을 하되 리버스 프록시 서버와 각 WAS 는 Http 통신을 함으로써 Https 통신에 대한 WAS 의 부하를 상당히 낮출 수 있다.

글을 써보고 나니 리버스 프록시 서버의 파생 기능 정도로 보여지는데 이 외에도 캐싱, Http2 등 다양한 기능을 제공해주고 있으니 NginX 공식 패이지의 블로그나 공식 문서를 참고해보도록 하자.

NginX Blog : https://www.nginx.com/category/tech/
NginX 공식 문서 : https://docs.nginx.com/

이 중에서 내가 사용한 기능은 리버스 프록시와 SSL Termination 기능이었다. 초기 서비스라 동시 접속자가 많지 않을 것이라고 생각해 로드 밸런싱 기능은 사용하지 않았다. 조금 늦긴 했지만 한 대의 EC2 안에 NginX 와 WAS 를 모두 설치한 것이 Configuration 오류를 초래했던 것 같고 추후 성능 저하의 원인이 될 가능성이 생길 수도 있었을 것 같다는 생각을 했다. 물론 동작은 했다...

3) NginX 로 Https 웹 서비스 배포하기

3-1) NginX 세팅

우리는 AWS 에서 알 수 없는 이유로 인해 인증서 발급이 되지 않아 Let's Encrypt 로 인증서를 발급하였다. 이 방법은 구글링에 다양한 방법이 나와있으므로 따로 포스팅하지 않고 Let's Encrypt 인증서가 발급되었다는 가정 하에 NginX 세팅을 진행하도록 하겠다.

NginX 설치

WAS 를 설치하는 법은 넘어가고 아래의 명령어를 입력해 NginX 서버를 설치한다.

$ sudo apt update
$ sudo apt install nginx

NginX 리버스 프록시 설정

설치된 디렉토리 중 /etc/nginx/conf.d 로 이동하여 설정 파일을 생성후 이를 실행해 아래의 내용을 채우면 된다.

$ cd /etc/nginx/conf.d
$ vim default.conf

server {
    listen 80;
    server_name your.domain.com;

    location / {
        proxy_pass http://192.168.XXX.XXX;
        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_name 은 SSL 을 적용할 도메인이고, Certbot 이 server_name 을 기준으로 NginX 설정 파일을 찾아 설정을 자동으로 추가해준다. proxy_pass 에는 WAS 가 설치된 서버의 주소를 적는다. 여기서는 임의의 서버 주소를 입력했지만 나의 경우에는 EC2 한 대에 NginX 와 WAS 모두를 설치했기 때문에 Local IP 인 127.0.0.1 을 입력했다.

SSL 인증서 발급 및 Certbot 설치

Certbot 은 인증서를 자동 발급할 수 있도록 도와주는 도구이다. 아래의 명령어를 입력해 Certbot 을 설치하자.

$ sudo snap install certbot --classic

그리고 아래의 명령을 실행해서 SSL 인증서를 발급받으면 된다. 이 때 적용할 도메인에 대한 A 레코드가 반드시 적용되어 있어야 한다.

$ sudo certbot --nginx

여기까지 완료되었다면 Certbot 은 Let's Encrypt 를 통해 자동으로 SSL 인증서를 발급해온다. 그 후 Certbot 이 default.conf 에 Https 적용을 위한 설정을 자동으로 한 것을 확인할 수 있다.

server {
    server_name your.domain.com;

    location / {
        proxy_pass http://192.168.XXX.XXX: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;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/your.domain.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/your.domain.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server {
    if ($host = your.domain.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    listen 80;
    server_name your.domain.com;
    return 404; # managed by Certbot
}

SSL 인증서 자동 갱신 설정

Let's Encrypt 는 무료 서비스로 보안 이슈 발생 시 보상금이 없고 90일 짜리 단기 인증서를 발급해준다. 90 일 마다 SSL 인증서를 수동으로 갱신할 수 없으므로 자동화하는 방법을 사용해보자.

Crontab 이란 Linux 에서 제공해주는 기능으로 특정 시간이나 주기로 명령을 수행해준다. 아래의 명령으로 cron job 하나를 생성한다.

$ crontab -e

그 이후 vim 을 선택해 매월, 매일 0시 0분에 certbot 을 실행하여 SSL 인증서를 갱신하고 NginX 설정 파일을 Reload 해주는 명령어를 입력하자.

0 0 * * * certbot renew --post-hook "sudo service nginx reload"

사실 NginX 설정에 정말 많은 오류와 시행착오를 겪었기 때문에 이를 제대로 다뤘다고 말하긴 어려울 것 같다. 대신 수 많은 구글링을 통해 통하는(?) 방법과 포스팅을 찾았고 이를 기반으로 글을 작성했다. 원작자의 글은 아래를 참고하자.

Nginx와 Let's Encrypt로 HTTPS 웹 서비스 배포하기 (feat. Certbot) : https://hudi.blog/https-with-nginx-and-lets-encrypt/

마무리

Https 와 NginX 를 공부해보기 전에는 이렇게나 내용이 방대하고 어려울지 생각을 못했었다. 그러나 덕분에 또 한 번 성장하는 계기를 가질 수 있었고 많은 내용을 배울 수 있었다. 다만 NginX Configuration 에 정말 많은 어려움을 겪으면서 Linux 공부와 NginX 를 더 다양한 방법으로 다뤄보고 싶다는 생각이 들었다. 특히나 로드 밸런싱 관련 기능을 사용해보지 못했기 때문에 이 부분에 대해서 더 다뤄보고 싶다. 이에 대해서는 추후 공부를 통해 추가 포스팅할 수 있도록 하겠다.

참고 :
[10분 테코톡] 🍭 다니의 HTTPS : https://www.youtube.com/watch?v=wPdH7lJ8jf0
HTTPS가 뭐고 왜 쓰나요? (Feat. 대칭키 vs. 비대칭키) : https://www.youtube.com/watch?v=H6lpFRpyl14
[10분 테코톡] 👶에단의 TLS : https://www.youtube.com/watch?v=EPcQqkqqouk
[10분 테코톡] 🔐 마갸의 암호 : https://www.youtube.com/watch?v=itehKMMBVjc
[10분 테코톡] 🌟조앤의 Forward Proxy vs Reverse Proxy vs Load Balancer : https://www.youtube.com/watch?v=u4O4zHdiFhk&list=PLq6YHA1IXXnknjlwxAJqW7oq6pNjcOgwT&index=10
[10분 테코톡] 🔮 히히의 OSI 7 Layer : https://www.youtube.com/watch?v=1pfTxp25MA8&list=PLq6YHA1IXXnknjlwxAJqW7oq6pNjcOgwT&index=61
정적 웹은 뭐고 동적 웹은 뭔가요? : https://www.youtube.com/watch?v=C06xRvXIAUk
[10분 테코톡] 👳‍♂️ 알리의 Web Server vs WAS : https://www.youtube.com/watch?v=mcnJcjbfjrs
[10분 테코톡] 🤫 피케이의 Nginx : https://www.youtube.com/watch?v=6FAwAXXj5N0
HTTPS, SSL(Secure Socket Layer) 개념 : https://www.crocus.co.kr/1387
[네트워크] OSI 7 계층 : https://yjkim97.tistory.com/35
[네트워크] 전송 계층 : https://velog.io/@gndan4/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EC%A0%84%EC%86%A1-%EA%B3%84%EC%B8%B5
[네트워크] 응용 계층 : https://velog.io/@gndan4/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EC%9D%91%EC%9A%A9-%EA%B3%84%EC%B8%B5
HTTP vs HTTPS의 차이점을 알아보자 : https://devjem.tistory.com/3
[Web] HTTP와 HTTPS의 개념 및 차이점 : https://mangkyu.tistory.com/98
HTTPS와 SSL/TLS의 의미 및 차이점 : https://bumday.tistory.com/43
네트워크 - HTTP/HTTPS 차이점, HTTPS란? : https://coding-start.tistory.com/208
HTTPS와 SSL 인증서 : https://www.opentutorials.org/course/228/4894
암호화 알고리즘 종류 : https://jusungpark.tistory.com/34
[Programming] 암호화 알고리즘 종류와 분류 : https://velog.io/@inyong_pang/Programming-%EC%95%94%ED%98%B8%ED%99%94-%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98-%EC%A2%85%EB%A5%98%EC%99%80-%EB%B6%84%EB%A5%98
SSL이란?, SSL과 TLS 정의 및 차이 : https://kanoos-stu.tistory.com/46
HTTPS는 프론트엔드, 백엔드 어디에 적용되어야 하나? : https://velog.io/@pjh612/HTTPS%EB%8A%94-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EB%B0%B1%EC%97%94%EB%93%9C-%EC%96%B4%EB%94%94%EC%97%90-%EC%A0%81%EC%9A%A9%EB%90%98%EC%96%B4%EC%95%BC-%ED%95%98%EB%82%98
[NginX] NginX 시작하기 1/3 - 기초편 : https://blog.naver.com/PostView.nhn?blogId=pjt3591oo&logNo=222242046633&parentCategoryNo=&categoryNo=92&viewDate=&isShowPopularPosts=false&from=postView
Nginx란 무엇인가? : https://dkswnkk.tistory.com/513
Web Server와 WAS의 차이 : https://dkswnkk.tistory.com/503?category=551275
[Nginx] 웹 서버 Nginx 에 대해서... : https://hyeo-noo.tistory.com/205#Nginx%EB%-E%--%-F%--%---
웹 서버와 NginX : https://tecoble.techcourse.co.kr/post/2021-07-30-web-server-and-nginx/
[7장] 5-4. SSL Termination 및 보안 기능 : https://nulls.co.kr/AWS/234
SSL 보안인증서 무료와 유료 차이점이 있나요? : https://sir.kr/qa/426007
Nginx와 Let's Encrypt로 HTTPS 웹 서비스 배포하기 (feat. Certbot) : https://hudi.blog/https-with-nginx-and-lets-encrypt/

Ming-Gry

항상 진심이지만 뭔가 안풀리는 개발 (주의! - 코린이가 배우고 이해한 내용을 끄적이는 공간이므로 실제 개념과 일부 다를 수 있음!)

이전 포스트