사이드 프로젝트 서버 https 설정하기

게시 2023/11/16 업데이트 2024/02/22

By Hyechan Bang 11 분읽는 시간

Https 설정하기

현재 내가 개발한 사이드 프로젝트는 http 프로토콜을 사용하고 있다.

프로젝트 내부에 Clipboard API를 사용하고 있는데, 로컬서버에서는 잘 동작하지만 배포서버에서는 동작이 안되는 이슈가 발생했다.

Next 서버를 사용하고 있고, 구글링을 통해 여러 방법을 시도해보았지만 효과가 없어서 고민하던 와중, 근본적으로 Clipboard API를 사용하려면 Https 프로토콜을 사용해야 한다는 글을 보았다.

그럼 미루어놓았던 https 설정에 대해 알아보자.

HTTPS 란?

HTTPS : Hypertext Transfer Protocol Secure

간단하게 말하면 기존의 HTTP 프로토콜에 암호화를 적용한 버전이다.

서버와 클라이언트간의 통신을 암호화하는데, 암호화에는 SSL¹ 또는 TLS²를 사용한다.

암호화 하는 이유

기존의 HTTP 통신에서 전송되는 데이터 패킷은 스니핑 등의 해킹에 취약하기 때문에, 패킷을 도청당하면 그 내용이 그대로 보인다.

이 때, 도청당한 내용을 해커가 보지 못하도록 암호화를 하는것이 TLS의 역할이다.

암호화가 된 패킷의 경우, 도청당하더라도 내용이 이미 암호화된 상태이기 때문에 중요한 정보가 유출될 위험에서 벗어날 수 있다.

암호화 방식

TLS의 암호화 방식을 깊게 다루기에는 암호학 자체에 들어간 용어들과 수학 이론이 어렵기때문에, 간단하게만 알아보자.

TLS는 공개 키 암호 방식을 사용한다. 비대칭 암호 방식이라고도 알려져 있으며, 정보의 암호화 / 복호화를 위해 2개의 key 를 사용한다.

Public Key: 데이터를 암호화하는데 사용되는 Key
Private Key: 암호화된 데이터를 복호화하는데 사용되는 Key

간단한 예를 들어보자면 아래와 같다.

암호화에 사용되는 key는 원본 데이터를 뒤죽박죽으로 변형시켜서 랜덤 데이터처럼 보이게 하기위해 사용되는 정보 조각이다.
(대부분의 경우 key는 큰 숫자 혹은 숫자와 문자가 조합된 문자열이다)

원본 데이터가 key와 암호화 알고리즘을 거치면 랜덤 데이터처럼 변환되고, 알맞은 복호화 key를 가진 사람은 누구든 원본 데이터로 복호화 할 수 있다.

이러한 암호화 방식에 사용되는 public key와 private key는 웹 서버에 저장되어 있는 SSL/TLS 인증서에 포함되어 있으며, 클라이언트가 처음 https 웹 사이트에 접속하거나 API 요청, DNS over HTTPS 요청 등에 TLS handshake 방식을 통해 공유된다.

서버에 적용하기

서버에 nginx에 깔려있다는 전제 하에 진행한다.

  
server {
    기타 설정들...

    server_name loaple.site www.loaple.site;

    기타 설정들...
}

nginx 설정에 제대로 도메인이 적혀있나 확인한다.

인증서를 발급해주는 Certbot을 설치하자.

Certbot 설치

  
sudo ufw allow 'Nginx Full' # 80, 443 포트 허용
sudo ufw allow 'OpenSSH' # ssh 포트 허용
sudo ufw enable # 방화벽 활성화

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx

이후 커맨드창에 cerbot 관련 설정이 진행되는데, 현 시점의 설정 과정은 다음과 같다.

Certbot 설정

리뉴얼, 보안 관련 알림에 사용될 이메일 주소 입력
이용약관 동의(필수), 이메일 계정 정보 제공(선택)
사용할 도메인 선택(모두 선택은 그냥 엔터 누르기) /etc/nginx/sites-enabled/default 에 설정한 server_name 항목에 있는 도메인들.

위 과정이 완료된 후 아래와 같이 완료 메세지가 출력되면 끝이다.

이제 해당 도메인으로 접속하면 https 접속이 된다.

인증서 자동 재발급

Certbot이 발급한 인증서의 유효기간은 3개월이다.

crontab³에 스크립트를 추가해서 자동 갱신을 해보자.

crontab 의 기본 문법은 다음과 같다.

minute(0-59) hour(0-23) day(1-31) month(1-12) weekday(0=Sunday - 6=Saturday) command(shell command)

이에 따라 아래와 같이 명령어를 등록했다.

  
0 3 1 * * root certbot renew --quiet --no-self-upgrade --pre-hook "service nginx stop" --post-hook "service nginx start"

crontab 등록 확인은 crontab -l 명령어로 가능하다.

제대로 동작하는지는 3개월 후에 지켜보는 것으로…?(certbot renew --dry-run 실행은 해보았음)

정리

이번 포스트에서는 사이드 프로젝트 웹서버를 http 프로토콜에서 https 프로토콜로 업데이트했다.

단순히 Clipboard API를 사용하기 위한 업데이트였지만, 미루고 미루던 숙제를 한 느낌이라 뭔가 뿌듯하다.

과정 자체가 자동화가 많이 돼있어서 어려울 건 없었다. nginx 설정파일도 자동 수정되는걸 보니 신기하긴 하다.

그리고 다행히도 동작하지 않던 Clipboard API도 잘 동작한다. 만약 https 문제도 아니었다면 생각만 해도 끔찍;

참조

후기

어느날 갑자기 프로젝트 사이트가 접근이 안된다… 브라우저상 뜨는 메세지를 보니 이 사이트는 보안 연결(HTTPS)이 사용되지 않았습니다. 라고 뜬다.

혹시 https 인증서 재발급이 제대로 안됐나 왜이럴까 이런저런 고민하던 중 설마해서 이 포스트를 다시 확인해보았다.

이 포스트를 다시 확인해보니 11월 16일날 업로드된 포스트.. 아마 이때쯤 서버 업데이트도 동시에 진행했을 것이다. 그렇다고 치면 사이트 접근이 막히고 좀 방관하다가(ㅎㅎ;) 다시 포스트를 확인한 날짜가 2월 22일. 3개월이 지난 상태이다. 위에 정리한 crontab 주기를 보니 1개월 간격으로 설정해놓았다.

잘 동작하고 있는지 확인하고 있는지 서버에 원격접속을 시도하는데 안되더라… aws 서버를 확인해보니 상태 검사 중 하나(인스턴스 연결성 검사)가 실패했네? 일단 접속을 못하니 인스턴스 재부팅을 하고나서 서버를 다시 켰다.

재부팅 후 별 동작에 문제 없는거 보면 내가 생각했던 인증서 재발급 문제는 아닌 것 같고 인스턴스 문제가 맞나보다..

물론 이 증상도 내가 해놓은 설정에서 비롯될 수도 있지않을까 생각이 들지만 그건 동일한 문제가 3개월 후에 또 발생하면 그때 확인해보자.(ㅎㅎ;)

각주

Secure Sockets Layer는 클라이언트와 서버 간의 안전한 링크를 통해 송수신되는 모든 데이터를 안전하게 보장하는 과거의 보안 표준 기술이었다. SSL 버전 3.0은 Netscape가 1999년에 발표했으며 현재에는 Transport Layer Security (TLS) 로 대체되었다. ↩
Transport Layer Security. 어플리케이션들이 네트워크 상에서 안전하게 통신하기 위해 사용된 프로토콜이며, 이메일, 웹 브라우징, 메시징, 그리고 다른 프로토콜들의 감청을 통한 정보의 변형을 방지합니다. ↩
소프트웨어 유틸리티 cron은 유닉스 계열 컴퓨터 운영 체제의 시간 기반 잡 스케줄러이다. 소프트웨어 환경을 설정하고 관리하는 사람들은 작업을 고정된 시간, 날짜, 간격에 주기적으로 실행할 수 있도록 스케줄링하기 위해 cron을 사용한다. ↩

Https, Certbot

https