[https] nginx로 간단하게 https 설정

https 설정 방법이 블로그글마다 너무 다양해서 골치아팠는데 

내가 사용한 / 할 방법으로 정리

 

와일드카드로 설정할 도메인의 ip를 가진 인스턴스가 없었기 때문에

dns 레코드마다 개별 https 인증서를 발급하였음.

 

시도하기전에 nginx는 stop 해야한다

또, api서버의 경우에는 nginx sites-available의 default를 사용하고 있었다면 새로 파일을 만들어 enabled와 링크해서

그럼 지금부터 갓피티가 알려준 방법

---

 

네, certbot을 사용하여 Let's Encrypt SSL/TLS 인증서를 발급받는 과정을 자세히 안내해 드리겠습니다. 여기서는 Ubuntu Linux를 예로 들어 설명하겠습니다.

1. certbot 설치

Ubuntu에서 certbot을 설치하려면, 다음 단계를 따라야 합니다:

 

1. 저장소 추가:

sudo apt-get update
sudo apt-get install software-properties-common
sudo add-apt-repository universe
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update

 

2. certbot 설치:

sudo apt-get install certbot

2. Nginx를 사용할 경우 certbot 이용

sudo apt-get install python3-certbot-nginx
sudo certbot --nginx -d example.com

// 다른 url더 추가하려면 이런식으로
// sudo certbot --nginx -d example.com -d www.example.com
//  뒤에 -d 더 붙여가며 늘려도 됨.
// 와일드카드는 *.example.com 으로 하면 됨

3. 인증서 자동 갱신 설정

certbot은 인증서를 자동으로 갱신하도록 크론 잡이나 systemd 타이머를 설치합니다. 이렇게 하면 인증서가 만료되기 전에 자동으로 갱신되어 인증서 만료로 인한 서비스 중단을 방지할 수 있습니다. 인증서 갱신이 제대로 설정되어 있는지 확인하려면 다음 명령을 실행해 보세요:

sudo certbot renew --dry-run

이 명령은 실제로 인증서를 갱신하지 않고, 갱신 절차를 시뮬레이션하여 설정이 올바르게 작동하는지 확인합니다.

4. 인증서 확인 및 적용

인증서가 발급된 후에는 /etc/letsencrypt/live/example.com/ 디렉토리에 위치한 fullchain.pem과 privkey.pem 파일을 웹 서버의 SSL/TLS 설정에 적용해야 합니다. 이 부분은 사용하는 웹 서버의 설정에 따라 달라집니다.

이 과정을 통해 certbot을 사용하여 SSL/TLS 인증서를 성공적으로 설치하고 갱신할 수 있습니다. 언제든지 추가 도움이 필요하시면 말씀해 주세요!

 

---

 

sudo certbot renew --dry-run

 

으로 갱신시뮬레이션을 하면 nginx 프로세스가 실행되어 80, 443 포트를 잡아먹고 있는 경우가 있다.

 

그럴떈 

sudo lsof -i :80
sudo lsof -i :443

또는

 

sudo netstat -tulpn | grep :80
sudo netstat -tulpn | grep :443

로 확인 후 있으면,

id로 하나하나 kill 해도 되지만

 

sudo killall nginx

로 다 지워도 좋음

 

그리고 

 

이방식으로 할 경우에는 nginx의 sites-available에 위치한 설정 파일에

80 -> 443 리다이렉트와

ssl / tls 인증서도 자동으로 추가해주고,

인증서 자동갱신도 알아서 추가해줌..

엄청편함

 

또,

certbot의 인증서 자동갱신이 제대로 되어있는지 확인하는 방법

sudo crontab -l
sudo crontab -l -u root

또는

systemctl list-timers | grep certbot

을 실행하여 항목이 있는지 확인.

 

내 경우엔 systemctl ~로 확인했을때 나왔음

 

 

그리고 웹페이지가 없는 api 서버의 경우에는

nginx sites-available의 default 파일을 수정해서 쓰지 말고

파일 하나 더 만들어서 enabled에 링크해서 쓰는 방식으로 해야함.

default에 쓰면 하위 uri들은 404가 뜸

(이유는 정확히 모르겠지만 default에는 root 웹페이지 지정하는 부분이 있기 때문에 웹페이지로부터 navigate 해야 정상 작동하고, 그냥 uri로 직통연결하는 api 서버 방식과는 구조가 안맞아서 그런듯함. 추측임)