안녕! 안녕!
이 페이지에 들어오신 분들은 필경 Let's Encrypt SSL 인증서 (Certificates)를 발급받기 위해 기를 쓰고 있었겠지?
그것도 Cent-OS 환경에서 말이다.
구글링을 반복하고, 또 반복하다가 결국에는 여기까지 흘러 들어왔겠지.
안 봐도 뻔하다.
그렇다면 잘 찾아오셨다.
필자 역시 온갖 시행착오를 다 겪어본 다음에 재차 글을 올리는 것이기 때문이다.
일전에도 매뉴얼이랍시고 만들어 놓기는 했지만...
정말이지 성의 없었다.
여러분이 보건, 말건 나만 내용을 참고하기 위해서였지.
업무시간에 블로그를 할 수는 없지 않은가?
...라는 안일한 생각이 결국 사달을 내고 말았다.
하루는 이전과 똑같이 매뉴얼 (...)을 보면서 SSL 인증서를 웹 서버에 설치하고 있었지.
그런데 Config 파일을 잘못 건드려서 실제로 돌아가고 있는 쇼핑몰의 서버가 하루 동안 다운되었던 것이다.
결국에는 업무를 지시한 선배 개발자가 사고를 수습했지만...
자책감과 송구스러운 마음에 밤잠을 설치고 말았다.
부디 여러분은 필자와 같은 사고를 치지 말라는 마음에 글을 전면적으로 수정해서 다시 올리는 것이다.
그리고 지금 이 시간에도 속앓이를 하고 있을 수많은 초보 개발자들의 건승을 기원한다.
우리라고 언제까지 초보이겠는가?
버그가 발생했으면 수단과 방법을 가리지 않고 해결을 하고...
철저하게 원인을 분석해서 내 것으로 만들면 되는 것이다.
다들 그 과정이 즐거워서 개발을 시작한 거잖아?
오케이! 그럼 기합 차게 시작해보자.
0. Convert HTTP To HTTPS
구글링을 하다 보면 간혹 이런 페이지를 만나볼 수 있다.
"님이 지금 보고 계시는 웹 사이트의 보안이 심히 우려돼요...!"
라고 웹 서버가 경고 아닌 경고를 하고 있는 것이다.
어차피 몇 초 후에 뒤로 가기를 누를 우리들이야 알 바 아니지만...
그 사이트를 운영하는 입장에서는 어떨까?
예컨대 끊임없이 고객을 유치해야 하는 쇼핑몰이라면 가볍게 볼 문제가 아니다.
회원들의 개인정보는 물론, 구매 및 결제 내역까지 전부 데이터베이스 (DB)로 관리해야 하지.
그렇기 때문에 신뢰할 수 있는 기관에서 보안 인증서 (SSL)을 발급받아 웹 서버에 배포해야 하는 것이다.
그것만으로 보안에 저해되는 요소가 전부 해결되는 것은 아니지만...
우리의 핵심 과제인 'HTTP → HTTPS'는 우선 일단락되는 셈이다.
바로 이렇게 말이다!
물론 SSL 인증서를 발급해주는 기관이 Let's Encrypt 한 곳만 있는 것은 아니다.
점유율만 놓고 보자면 순위권에서 보이지도 않지.
문제는 SSL 인증서 자체가 워낙 비싸다는 것이다.
건 당 3만 원부터 시작해서 최대 15만 원 까지 펌핑되는데?
하지만 Let's Encrypt는 가장 신뢰할 수 있는 무료 인증서라는 점..!
여러분이 1인 개발자라면 얕잡아 볼 수 있겠는가?
비록 90일마다 한 번씩 인증서를 새롭게 갱신해줘야 해서 약간 번거롭기는 하지만...
그것도 다 방법이 있다.
이번 시간에는 그 모든 과정을 '풀 코스'로 밟아보도록 하자.
1. Apache 서버에 개발환경 구축하기
필자가 근무하는 회사에서는 서버사이드 개발 언어로 PHP를 쓰고 있다.
규모가 작은 웹 에이전시로서 다른 선택지가 없기는 하지.
그렇기 때문에 'A.P.M'을 능숙하게 핸들링할 줄 알아야 한다.
'Apache'
'PHP'
'MySQL'
요 세 놈들 말이다.
세 가지 스택 중에 만만한 녀석은 단 하나도 없다.
각자 카테고리를 따로 만들어 시리즈로 포스팅을 해도 무언가 미진할 만큼 양이 방대하지만...
필자는 아직 그 정도 역량을 갖추지 못하였다.
미. 안. 하. 다!!!
우선은 PHP와 MySQL (내지 MariaDB)를 이용해 로컬 서버는 구축했다고 가정하자.
내 컴퓨터에서만 접속이 가능한 웹 사이트 말이다.
거기서 한 걸음 더 나아가 Cafe24, Gabia, AWS와 같은 호스팅 업체에서 도메인까지 구매했다고 가정하자.
서버 엔진은 기본적으로 Apache VS Ngin-X일 것이고...
그렇다면 선택할 수 있는 운영 체제는 Cent-OS VS Linux가 될 것이다.
우리는 이제부터 Cent-OS 체제에서 운영되는 Apache 서버를 가지고 놀아볼 것이다.
벌써부터 어렵게 느낄 필요가 하나도 없다.
맥도널드 (Apache) 코리아 (Cent-OS)라고 해서 뭐 특별한 게 있겠는가?
새로 부임한 사장님의 성함이 '루트 (root@)'라는 것 정도?
(...)
비유가 그렇다는 거다.
제발 좀 그냥 찰떡같이 알아 들어라.
※ Linux OS는 문법이 약간 다르니 참고 바람...
1-1) 저장 공간을 확보하라!
주객이 전도되어서는 안 되지...
우리의 최종적인 목표는 싼마이 느낌이 물씬 풍기는 HTTP 헤더를 도메인에서 날려버리는 것이다.
대신 예쁜 자물쇠 모양과 함께 HTTPS 헤더를 보고자 하는 것이지.
...
오로지 이것만을 위한 빌드업이었다.
'HTTP → HTTPS'를 위해서 필요한 것이 SSL 인증서라고 했지?
그 인증서를 저장할 공간 (Repository)을 우선적으로 확보해야 쓰겠다.
누추하신 분을 귀한 곳에 모실 수는 없지 않겠는가?
우선 편집기부터 깔도록 하자...
필자는 요 MobaXterm이라는 녀석을 추천하는데...
그전에 질문 하나만 하자.
여러분은 우리가 늘 쓰고 있는 Windows 역시 하나의 OS인 것을 알고 있는가?
연식이 조금 있으신 분들은 DOS 역시 알겠지.
당시 잼민이들이 게임을 하기 위해서는 일일이 명령어를 입력해서 해당 경로를 찾아 들어가야 했다.
컴퓨터를 잘 아는 형이나 삼촌이 없었다면 결코 쉬운 일이 아니었음...
거기에 UX / UI 개념을 도입해서 Personal Computer를 널리 도입시킨 인물이 바로 빌 게이츠다.
(무덤에서 벌떡 일어날 고인은 무시하도록 하자...)
컴퓨터가 그래서 비싼 거야...
단!
지금도 서버 전용 컴퓨터는 원시적인 형태를 유지하고 있는 경우가 많다.
그 서버 위에서 무언가를 작업하려면 새까만 (...) 도화지 위에 골조부터 그려 나가야 하는 것이다.
OS가 Cent-OS냐, Linux냐에 따라서 문법 역시 다르지.
이런 환경에서 명령어를 하나하나 입력해서 무언가를 만들라고 하면 욕부터 나올 것이 아닌가?
그래서 조금이나마 윈도우처럼 쓸 수 있는 편집기를 추천해주는 것이다.
필자 말 들어라 제발...
ssh root@Domain or IP Address
→ Enter Password:
필자를 따라 첫 관문에 진입하도록 하자.
준비된 아쎄이라면 도메인이 되었건, IP 주소가 되었건...
실제로 서버가 살아있는 웹 사이트를 가지고 있겠지?
아까 전에 맥도널드 코리아에 새로 부임한 사장님의 성함이 '루트 (root)'라고 했다.
비유를 든 것이지만 실로 적절하다고 할 수 있다.
사옥 건물에 들어가기 위해서는 사장부터 인턴까지 신분 인증을 해야 할 것 아닌가?
ssh는 여러분이 목에 걸고 다닐 사원증 정도로 생각하면 좋겠다.
도메인 / IP 주소는 여러분의 ID가 되겠고..
처음 방문하시는 분들은 개인적으로 통보받은 비밀번호를 입력하셔야 합니다.
이 럇 샤 이 마 세!!!
예, 뭐...
그렇습니다!
yum -y install epel-release
필자가 두 번 정도 강조했던 것 같다.
Cent-OS와 Linux는 문법이 약간 상이하다고...
Cent-OS는 관리자 권한으로 명령을 실행할 때 'yum'을 먼저 부여한다.
Linux에서 sudo로 시작하는 것 빼고는 과정 자체는 다를 게 없다.
우리는 Cent-OS 체제에서 작업하고 있으니 yum을 써 줘야지.
귀하디 귀한 SSL 인증서를 따로 모시기 위한 객실을 만들어 준 것이다.
그다음에는 명령이 제대로 실행되었는지를 확인해야겠지?
yum repolist
다음과 같이 근사한 방이 하나 생겨버렸다.
필자가 개소리를 잔뜩 늘어뜨려 놓는 것 같겠지만... (아니었어?)
이게 다 여러분의 이해를 돕기 위해서이다.
서버 관련 사고 치니까 입술이 바짝바짝 마르더라.
yum -y install snapd: Now install snapd
이번에는 snap이라는 파일을 또 만들어줘야 한다.
필자도 이 녀석이 자세히 어떤 기능을 수행하는지 까지는 잘 모르겠다.
다만 인증서가 작동하기 위한 필수 응용 프로그램인 것만은 확실하다.
systemctl enable --now snapd.socket
# → Created symlink from /etc/systemd/system/sockets.target.wants/snapd.socket to /usr/lib/systemd/system/snapd.socket.
snapd.socket 파일을 강제로 활성화시켜주고 있는 것이다.
이번에는 yum이 아니라 systemctl이라는 녀석이 붙어있지?
Apache 서버에 관한 명령을 수행할 때는 systemctl로 권한을 부여한다.
기억하기 바란다.
systemctl list-unit-files | grep snapd.socket
# → snapd.socket enabled
설치된 snap이 제대로 활성화되었는지도 확인해줘야지.
정상적으로 명령을 수행하였다면 저렇게 'enabled' 결과가 출력될 것이다.
ln -s /var/lib/snapd/snap /snap
내친김에 경로까지 설정하자.
systemctl start snapd
snapd.socket이 disabled이 아니라 enabled 상태라면 다음 명령이 정상적으로 실행될 것이다.
필자 역시 아직 서버에 관해서는 초짜지만 이렇게 Line by Line으로 작업하는 게 맞다고 본다.
자! 우리는 지금까지 왕 (?)이 기거할 만한 행궁 (行宮)을 만들었다.
정말 중요한 작업이라고 할 수 있지만 아직 화룡점정을 찍은 건 아니지.
옥좌 (玉座)를 만들어야 할 것 아닌가?
2. Certbot & Python2 모듈 설치하기
방금 뭔가 거창하게 비유한 거 같은데..
그냥 Let's Encrypt 인증서를 실행하기 위한 모듈을 두 개 깔아준다는 말이다.
우선은 snap의 버전을 확인하고, 최신 버전으로 업데이트해주도록 하자.
sudo snap install core; sub snap refresh core
ssh에 접속되어 있는 계정이 root가 아니라면 Linux처럼 sudo를 부여해줘야 한다.
이미 root로 접속되어 있다면 사족이 되겠지.
snap version
버전 체크!
yum install certbot
인증서에 관한 작업은 yum으로 권한을 부여하는 경우가 많다.
일사천리로 Certbot을 설치해주도록 하자.
certbot --version
버전 체크까지 꼼꼼하게 실행해주도록 하자.
설치가 정상적으로 진행되었다면 불필요한 과정이기는 하지만 그냥 해... ㅡㅡ
yum install python-certbot-apache
이번에는 Python2 모듈을 깔아주도록 하자.
왜 하필 파이썬인지는 필자도 모른다.
파고들자니 한 세월일 것 같아서...
python --version
Python2 모듈까지 최신 버전으로 설치 완료!
여기까지 오느라 정말이지 고생 많았지만 아직 끝이 아니다.
정확히 말하자면 이제부터가 시작이야.
인증서만 발급한다고 끝나는 게 아닐뿐더러..
뭐가 안 풀리다 보면 인증서를 여러 번 설치하는 일 또한 피해 갈 수 없을 것이다.
하지만 기억해라.
※ Let's Encrypt 인증서는 일주일에 5회만 설치할 수 있다.
※ 그 이상으로 시도하면 웹 서버에서 일주일 록 다운을 걸어버림.
※ 즉, 일주일이 지난 다음에야 다시 인증서를 발급받을 수 있다.
3. Let's Encrypt 보안 인증서 (SSL) 발급받기
필자의 선배 개발자가 고생한 흔적이다.
시작부터 밝혔듯이 config 파일을 잘못 건드린 관계로 웹 서버 자체가 먹통이 되어버렸고..
이런저런 시도를 한 결과 저렇게 두 개의 경로에 각각 핵심 인증서 파일들 (*. pem)을 다운로드하였다.
HTTPS를 Listen (443) 하기 위해 필요한 가장 중요한 Key 파일이라고 할 수 있다.
/letsencrypt/live 경로가 텅텅 비어있다면 무엇인가 잘못되었다는 뜻이겠지.
certbot --apache certonly -d yourDomain.com
※ 경로: /etc/letsencrypt/live/
우리는 Apache 서버에 Certbot 모듈을 설치해줬다.
그렇기 때문에 certbot을 먼저 실행하는 것이 당연한 것이고...
대부분의 경우에는 [certonly] 명령 하나만으로 설치가 정상적으로 진행이 된다.
하지만 여기에는 치명적인 단점이 하나 존재한다.
우선적으로 Apache 서버를 죽여야 한다는 것이다.
이 과정에서부터 무언가 꼬이기 시작한 것이지.
다시는 겪고 싶지 않은 끔찍한 경험이었기 때문에 이 과정은 배제할 것이다.
대신 Apache 서버를 죽이지 않아도 되는 [webroot] 명령으로 작업을 진행하였다.
문법 구조를 잘 살펴보길 바란다.
-w 뒤에는 보안 인증서가 설치될 디렉터리를 설정해주고 있으며..
-d 뒤에는 실제 도메인 주소를 멘션 해주고 있다.
여기까지는 별 차질 없이 진행될 것이다.
앞으로 남아있는 허튼짓이 가장 중요하다는 뜻이지.
자! 그전에 지금까지의 과정을 다시 한번 리마인드 해보도록 하자.
왕을 모시기 위한 행궁 (Repel)을 만들었고..
왕을 왕답게 보이기 위한 옥좌와 홀 (Certbot & Python2) 또한 갖추었다.
마침내 왕을 옥좌에 앉히는 과정 (certonly --webroot)까지 거사가 순조롭게 진행되었다.
이제 우리의 웹 사이트가 안전하다는 것을 만 천하에 선포 (ssl.conf)하는 일만 남았다!
4. Httpd Activate!
아직까지는 도메인이 HTTP 상태 그대로일 것이다.
최종 단계가 남아있다.
certbot --apache -d gidshopping.com
여태까지 뭐 빠지게 인증서를 설치했으니...
웹 서버에 HTTPS를 리다이렉션 시키는 과정 역시 빼놓을 수 없겠다.
만일을 위해서 'www' 헤더는 생략 바란다.
웹앱을 AOS / IOS 앱으로 빌드하는 과정에서 오류가 나는 것 같더라.
변경사항을 서버에 배포하기 위해 마지막으로 Apache 서버를 재시작 하도록 하자.
systemctl status httpd.service
그 전에 서버의 상태부터 확인해보자.
문제가 없다면 파란 불이 들어와있을 것이고, 그렇지 않다면...
systemctl restart httpd.service
Apache 서버 재시작을 위한 명령어이다.
서버가 다운되지는 않을 것이다.
그 외에 다른 명령어도 있지만 여기까지만 알아도 충분하다.
이번에 데인 게 너무 크다..
5. 인증서 수동갱신 & 자동갱신
시작부터 언급하였지만 Let's Encrypt 인증서는 90일의 유효기간을 가지고 있다.
발급받은 날짜로부터 만 90일 (89일)이 경과되면 인증서로서의 효력을 상실하는 것이다.
그때는 HTTPS가 비활성화 되면서 헤더에 빗금이 그어질 것이다.
https://www.
바로 이렇게 말이다.
자주 보지 않았는가?
인증서를 처음 만들 때부터 자동으로 업데이트 되도록 설정한다면 번거로움이 덜 하겠지
crontab -e
0 0 3 * * /usr/bin/certbot renew --renew-hook="systemctl restart httpd": 3달 간격으로 자동갱신되도록 contab edit
crontab -l
시간을 뜻하는 Cronos + Tab의 합성어 아니겠는가?
3달에 한번씩 자동으로 갱신이 되도록 설정했다.
그래도 수동으로 갱신하는 경우를 대비하지 않을 수 없겠지.
certbot renew --dry-run
인증서가 만료되기 30일 전 즈음에 시험삼아 갱신해볼 수 있다.
실제로 갱신되는 것은 아니다.
다만 모의 갱신에 실패한다면 여기서 또 문제가 생겼다는 거겠지...
certbot renew이렇게 해야 실제로 갱신이 된다.
힘들었다...
부디 도움이 되셨길 바란다.
구글링 두 번을 한 번으로 끝낼 수 있다면 더욱 좋고!