1.
Let's Encrypt 와일드카드 인증서 적용이 쉬울지 기대를 많이 했었습니다. 그런데 와일드카드 인증서 생성/갱신 시마다 DNS서버에서 키값을 매번 만들어서 인증해야 한다는 소식을 접했습니다. 개인 입장에서 이 과정이 무척 번거롭게 느껴지더군요. 그래서 포기.
2.
우분투에서 Let's Encrypt 인증서 설치는 (공식적으로) Certbot을 추천합니다.
( https://letsencrypt.org/getting-started/ => 에서 With Shell Access 항목 참고.)
Certbot이 세팅을 자동 처리해주는 것은 좋은데 엔진엑스 설정 어디를 어떻게 바꾸는지 알려주지 않는 게 불안해서(꼬이면 복구하기 힘듬), 번거롭더라도 (Certbot 없이) 수동으로 Let's Encrypt 인증서를 적용하기로 결정했습니다.
제가 처리했던 과정을 적는 거라, 튜토리얼처럼 완벽하지는 않을 겁니다. 감안하고 봐주세요.
이번에도 https://blog.lael.be/post/5107 라엘님의 글이 큰 도움이 됐습니다.
1. Let's Encrypt 패키지 설치
▲ 패키지들을 업그래이드해 줍니다.
sudo apt-get update
sudo apt-get upgrade
▲ (이것은 옵션)
apt-cache search 명령어로 Let's Encrypt 관련 패키지들을 찾아봅니다.
우분투 18.04에서 letsencrypt가 과도기 더미 패키지라고 나오는 게 찜찜해서 apt-cache show 명령어로 정보를 좀 더 봤습니다. letsencrypt 패키지는 certbot 패키지로 이름을 바꿔주는 역할을 한다네요. 걱정하지 말고 letsencrypt든 certbot이든 설치하면 되겠습니다.
▼ 참고로 우분투 16.04의 패키지저장소 검색시 나오는 목록들은 이렇습니다.
▼ letsencrypt 패키지를 설치합니다.
▲ sudo apt-get install letsencrypt
의존성 패키지로 certbot도 엮여서 설치되네요.
▲ 참고로 우분투 16.04의 letsencrypt 의존성 패키지들인데, 구성이 조금 다르지요?
▼ (선택사항) 설치하는 김에 certbot PPA도 추가해줍니다.
▲ sudo add-apt-repository ppa:certbot/certbot
이후 sudo apt-get update && sudo apt-get dist-upgrade -y 라고 쳐서 최신 패키지로 갱신해주세요.
(참고로 PPA 삭제는 sudo add-apt-repository --remove ppa:certbot/certbot 처럼 입력해서 하면 되는데, PPA로 추가한 패키지들은 그대로 남아있습니다. 패키지들까지 한꺼번에 제거하고 싶다면 ppa-purge 패키지를 설치하고(sudo apt-get install ppa-purge), sudo ppa-purge ppa:certbot/certbot 처럼 입력하면 된다고 합니다.)
※ 우분투 16.04 LTS는 (letsencrypt에서 certbot으로 대체하고 싶다면) 아래 링크를 참고하여 CertBot을 설치하도록 합니다.
https://certbot.eff.org/lets-encrypt/ubuntuxenial-apache
2. Let's Encrypt 인증서 수동 발급
각설하고,
①
Let's Encrypt 인증서 생성을 위한 통신은 HTTP(기본값 80포트)를 통해서 이루어지는 점을 알아두세요.
만약 과거에 HTTPS를 세팅한 적이 있어서 80포트로 접속했을 때 443포트로 강제 Redirection되도록 설정되어 있거나, HSTS 설정을 해서 HTTPS 접속이 강제되는 상황이라면... 웹서버 프로그램(엔진엑스) 서비스를 중지시켜서 443포트 강제접속을 막고 HTTP로 기본 접근되게끔 해두셔야 합니다(sudo systemctl stop nginx.service).
②
도메인 구입 사이트에서 연결 세팅 정도는 기본적으로 하셨어야겠죠?
이제 엔진엑스 서버블록 설정(아파치는 <VirtualHost> 설정)이 담긴 파일을 열어보세요. 확인할 게 있거든요.
(/etc/nginx/sites-enabled/ 경로를 확인하면 되고, Nginx 설정을 변경한 적이 없다면 /etc/nginx/sites-enabled/default 파일을 열면 됩니다.)
▲ 웹문서 root 경로를 확인하세요. index.html 파일이 있는 곳이에요.
server_name 에 할당된 도메인을 확인하세요. 아파치에는 ServerAlias라는 개념도 있는데, Nginx는 server_name 에 다수의 도메인을 한 칸씩 띄우고 적는 것으로 Alias(별칭도메인)를 구현한다고 합니다.
(도메인은 실제로 연결되어 있어야 함. 호스트파일 수정으로 속인 도매인은 안 됨.)
Nginx 서비스가 돌아가고 있는 상태에서 인증서 생성을 시도해봤습니다.
터미널 창에서 아래 형식처럼 지켜서 입력!
(★ 지금부터 소개하는 모든 letsencrypt 명령어는 certbot 으로 대체해도 똑같이 작동합니다. ★)
sudo letsencrypt certonly --webroot -w /var/www/html/jimnongtest1/ -d www.jimnongtest1.top
( 'sudo letsencrypt certonly --webroot -w 웹문서 루트 경로 -d 주소1 -d 주소2 -d 주소3' 형식입니다. Alias(별칭도메인)로 웹루트에 다수의 도메인을 매핑시켰었다면 '-d 주소' 를 여러번 써주면 됩니다.)
( letsencrypt 명령어 대신 certbot 명령어 쓰셔도 됩니다. )
webroot는 웹인증 방식으로 진행하겠다는 옵션인데, 내 컴퓨터의 letsencrypt 프로그램이 -w 경로에 임시로 파일을 생성하고 letsencrypt 사이트 측의 인증프로그램이 이 파일에 접근할 수 있으면 -d 옵션의 도메인들을 인증해주는 식으로 진행된다고 합니다.
※ 참고로 https://certbot.eff.org/docs/using.html#webroot 의 설명에 따르면
명령어 한 줄에 다수의 웹문서 루트 경로+주소들을 적을 수 있다고 합니다. 하나의 인증서에 정보를 담겠다는 건데...
( letsencrypt certonly --webroot -w 경로1 -d 주소1 -d 주소2 -w 경로2 -d 주소1 -d 주소2 )
저는 하나의 웹문서 경로에 지정된 도메인들만 하나의 인증서로 묶는 것이 보기 좋다고 생각합니다(라엘님 글의 취지에 공감). 그래서 웹문서 경로의 수만큼 인증서를 만드는 것을 추천합니다.
------------------------------------------------
※ Rate Limits(횟수 제한?) 정책이 있습니다. 정해진 기간 내에 인증 횟수를 다 쓰면 리밋 걸려서 초기화 될 때까지 인증을 못 받아요.
https://letsencrypt.org/docs/rate-limits/
만약 첫번째 시도에서 에러 뜨면서 진행이 막히면 다시 도전해서 리밋 횟수 까먹기보다는
--dry-run 옵션을 붙여서 통과될 때까지 "테스트"한 다음 테스트 통과하면 --dry-run 옵션 빼고 정식으로 진행하는 것을 추천합니다.
▲ --dry-run 옵션은 certonly와 renew 명령에만 붙일 수 있는 옵션입니다.
▲ --dry-run 을 붙여서 테스트 해봤는데요, 인증서 발급을 위해서는 email 주소 입력을 필수적으로 요구하더군요. 이메일 주소 없이 Let's Encrypt 인증서만 생성하려면 --register-unsafely-without-email 옵션을 뒤에 붙이라고 하네요. 하지만 저는 이 옵션을 추천하지 않습니다.
(참고로 이메일 주소 정보는 /etc/letsencrypt/accounts 디렉토리 내의 acme-블라블라~ 디렉토리에 저장되는 것 같습니다. 이 디렉토리를 지워봤더니, 인증서 새로 발급받을 때 이메일 주소를 다시 물어보더군요.).
https://certbot.eff.org/docs/using.html
위 링크에 다양한 옵션 값들에 대한 설명이 있는데요,
▼ 터미널 창에서도 도움말을 어느 정도 볼 수 있습니다.
각설하고,
▼ /etc/letsencrypt/accounts 디렉토리 내에 acme-블라블라~ 디렉토리가 없으면 --dry-run 옵션으로 인증서 생성 테스트를 했을 때 아래 스샷처럼 진행된 뒤 dry run 성공 메세지가 뜰 것이고,
▼ /etc/letsencrypt/accounts/acme-블라블라~ 디렉토리가 있으면 인증서 생성 테스트시 아래 스샷처럼 묻는 것 없이 dry run 성공 메세지가 뜰 겁니다.
dry run 실패 메세지가 떴다면 명령어를 점검해서 dry run 성공 메세지 뜰 때까지 테스트를 반복하고,
이후 --dry-run 옵션을 빼고 정식으로 인증서 생성을 시도합니다.
▼ 인증서 정식 생성. 참고로 -w 옵션과 --webroot-path 옵션은 기능이 같아요.
▲ 갱신 소식을 전해줄 이메일 주소, 동의(a), 아니(n) 을 차례로 입력했더니(--dry-run 테스트 할 때 입력했던 사항들은 안 나옵니다.) /etc/letsencrypt/live/jimnongtest1.top/ 경로에 인증서들이 저장됐다고 나오더군요.
인증서 경로를 적어두거나 기억해둡니다!
▲ 경로를 조회해봤더니 인증서가 정상적으로 생성된 것이 확인됩니다!
▲ 파일관리자 프로그램을 루트 권한으로 띄운 다음 cert.pem 파일을 더블클릭 해보니
입력했던 도메인 정보들이 보이네요. 성공한 듯.
인증서 수동 발급 절차가 끝났습니다. 발급받은 인증서는 SSL(TSL) 인증서를 요구하는 다른 프로그램에도 쓸 수 있습니다. FTPES, 메일서버 등등...
3. Let's Encrypt SSL 인증서 적용 테스트(to Nginx)
https 연결(443포트)을 구성하고 여기에 Let's Encrypt 인증서를 연결했을 때 접속이 되는지 테스트를 해볼 겁니다.
테스트 성공하면 (다른 분들이 서버블록 사례를 올려주신 것처럼) 구성을 보강하는 식으로 진행하려고요.
공유기를 쓰고 있다면 공유기의 포트포워딩 기능으로 443포트를 개방합니다.
우분투에 방화벽을 세팅한 적이 있다면 역시 우분투 방화벽에서 443포트를 개방합니다.
(이 부분은 따로 설명하지 않습니다. 잘 모르시면 검색해서 해결하세요.)
▲ 참고로 우분투 18.04 데스크톱 버전 설치 직후에는 방화벽이 비활성 상태입니다(기본값).
그래서 기본 상태에서는 공유기 방화벽만 신경쓰면 됩니다.
참고로 ufw를 gui로 제어하고 싶다면 gufw 라는 패키지를 설치하시면 될 겁니다.
gufw 사용법은 https://blog.naver.com/35mwlee/221143838817 이 글이 잘 설명한 듯합니다.
UFW에 대해 참고할만한 링크는 아래와 같습니다.
https://help.ubuntu.com/community/UFW
https://extrememanual.net/12019
본론으로 돌아와서.
(실수로 tcp6에 밑줄을 쳤는데, 이건 ipv6를 가리키는 거니까 tcp를 체크하세요. 우리는 아직 ipv4 환경이니까요.)
※ 이제부터는 아래 첨부파일을 받아서 텍스트에디터로 열고 복붙하는 식으로 따라오면 수월하실 겁니다.
guide.txt/etc/nginx/sites-enabled/ 경로에 있는 본인의 서버블록 설정 파일을 에디터로 엽니다.
(sudo gedit /etc/nginx/sites-enabled/블라블라~)
▲ 그리고 제일 아래에 443포트(https연결) 서버블록을 위 스샷처럼 추가합니다. 붉게 밑줄 친 부분을 본인 환경에 맞게 바꾸세요. 제가 인증서 생성 마쳤을 때 인증서 경로를 적어두거나 기억해두라고 적었었죠? 그게 서버블록 설정할 때 쓰입니다.
▲ 만약 저의 Nginx 다수 도메인 연결 방법 설명글 마지막에 나온 팁을 보고 IP주소 입력으로 접근하는 것을 차단한 적이 있다면 차단용 서버블록 설정 파일에도 인증서 경로를 적어줍니다.
저장하고 빠져나와서 Nginx 서비스 재시작.
(sudo systemctl restart nginx.service)
그리고 웹브라우저에서 https://도메인 형식으로 주소창에 입력해보세요.
▲ 자물쇠 모양 뜨면서 잘 연결되면 테스트 성공입니다. 자물쇠 클릭해보면 연결 잘 됐다고 안내문이 나오고, 여기서 "인증서" 항목을 클릭하면 인증서 정보를 볼 수 있습니다.
SSL Labs 사이트의 Server Test 카테고리( https://www.ssllabs.com/ssltest/ )에서 https 전환에 따른 보안등급을 측정해볼 수 있는데, 현재 상태에서 측정해봤습니다.
▲ A등급이 나오긴 하는군요. 그래도 다른 분들처럼 A+가 나오도록 조치하겠습니다.
4. 테스트 서버블록 제거 & 서버블록 재구성(강화)
위에서 구성했던 테스트 server { } 블록에서 핵심 부분만 골라 기존 80포트+도메인 조합의 server { } 블록에 옮겨줍니다.
▲ 443포트를 listen하라는 구문과 SSL 인증서 경로가 핵심 요소겠죠? 이렇게 하면 80포트(http)뿐만 아니라 443포트(https)에서 들어오는 요청도 받아서 도메인에 연결해주겠죠?
그리고 껍데기만 남은 테스트 server { } 블록은 과감하게 지웁니다.
아파치에서는 <VirtualHost *:80> </VirtualHost>형태로 가상호스트를 구성하는데, 포트번호가 VirtualHost 옆에 붙기 때문에 443포트에서 신호를 받는 <VirtualHost *:443> </VirtualHost> 가상호스트 블럭을 추가로 만든 다음 <VirtualHost *:80>의 내용을 전부 <VirtualHost *:443>에 복붙해야 했었죠. 물론 https 연결만 되게끔 설정한 다음 <VirtualHost *:80> 설정을 지우면 깔끔해지긴 하는데, https 연결을 강제하기 전까지는 설정이 아주 복잡해지는 단점이 있었습니다.
반면 Nginx에서는 listen 명령어가 server { } 블록 안쪽에 있기 때문에 위 스샷처럼 443포트에 관한 설정을 추가하는 것만으로도 https 연결이 가능합니다. https 연결이 강제되게끔 세팅한 다음에도 (원한다면) listen 80; 부분만 지워주면 되니까 굉장히 효율적이죠.
물론 아파치처럼 서버블록을 별도로 생성해서 443포트 관련 설정을 구성하는 것도 가능합니다(다만 아파치처럼 코드가 복잡해지겠죠.).
http 주소로 접근했을 때 https 주소로 Redirect(return) 해주는 서버블록을 추가해주면 좋겠죠?
[우분투 18.04 데스크톱] LEMP : 엔진엑스(Nginx) 설정 - www 없는 도메인을 www 붙은 주소로 redirect 하기
만약 기존에 위의 글을 참고해서 www↔non www 전환 Redirect를 구현한 적이 있다면 해당 서버블록을 수정하는 식으로 대처하면 됩니다.
▲ 저는 www가 안 붙은(non-www) 주소를 www가 붙은 주소로 return 시켰었는데,
▲ 이런 식으로 구성을 바꿔서 http로 들어오는 non-www/www 주소를 모두 https://로 향하도록 조치했습니다. 기존에 www↔non www 전환 Redirect를 구성하지 않았던 분들도 이 스크린샷을 따라하시면 되겠습니다.
이제 SSL 연결 과정상의 보안성을 끌올리기 위해 server { } 블록에 디피-헬만 파라미터를 추가할 겁니다.
▲ sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096
우선, 터미널 창에 위의 명령어를 입력해서 디피-헬만 키를 생성합니다.
(경고 뜬 것처럼 시간 오래 걸립니다!)
4096비트(512바이트)로 생성하는 것은 시간이 더 오래 걸리는 점을 감안하세요. 2048비트(256바이트)로 생성하려면 위의 명령에서 4096을 2048로 바꾸면 됩니다.
https://rsec.kr/?p=242 의 내용 중에 ”1024bit 까지는 NSA에서 풀어낼 수 있을 것이라 추정하고 있다.”는 부분이 보이니까 Diffie-hellman 키값을 반드시 최소 2048bit 이상으로 정합시다.
▲ 키 생성이 끝났으면 서버블록(/etc/nginx/sites-enabled/블라블라~)의 인증서 경로 밑에
ssl_dhparam /etc/ssl/certs/dhparam.pem;
라고 적습니다.
HTTP/2를 활성화합니다. https:// 연결이 전제되어야 적용할 수 있는 http/2. http/2로 접속하면 속도가 http/1.1보다 빠르다나? 왜 좋은지는 검색해보세요. 자세하게 나옵니다.
▲ listen 443 ssl 뒤에 붉게 밑줄친 부분을 추가하면 됩니다.
OCSP Stapling(Online Certificate Status Protocol Stapling) 설정도 추가할 겁니다. OCSP는 인증서의 만료 여부를 실시간으로 체크하는 프로토콜이라고 하는데, 실시간 처리의 특성상 부하가 심하게 걸리면 홈페이지가 느려지고 Secure Connection을 보장할 수 없는 상황이 오기도 한다고 해요(https://rsec.kr/?p=386 참고). 그래서 OCSP Stapling이라는 기술로 OCSP를 보강한다고 하는데, 위에서 SSL Labs 테스트했던 것을 보면 OCSP Must Staple 항목이 No로 되어있더라고요.
▲ 위 스크린 샷처럼 세 줄을 추가하면 OCSP Stapling이 설정됩니다. resolver로 구글이 제공하는 네임서버로 인증서 발급업체와 통신하도록 정했고요(Nginx 문서를 보니 OCSP 응답자 호스트 이름의 해석을 위해서는 resolver 지시어도 지정해야 한다고 하네요.).
OCSP Stapling은 옵션 정도로 생각하세요. 나중에 https://www.ssllabs.com/ssltest/ 에서 테스트했을 때 OCSP Must Staple 항목이 Yes로 잘 안 바뀌면 과감히 OCSP Stapling 설정을 지워버리는 게 정신건강에 좋을 수 있습니다.
▲ SSL Labs에서 테스트 결과를 보다 보니까 WEAK 값이 은근히 많아서 거슬리더군요. WEAK 값을 줄이기 위한 설정을 해봤습니다.
▲ 붉게 네모친 부분처럼 적어봤어요.
ssl_session_cache에 대한 개념은 Nginx 문서에 잘 나와 있는데요, 1MB당 4000세션을 저장할 수 있다고 합니다. 블로그 수준에서는 1m로 정해도 별 문제 없을 것 같은데, 국내 포스팅들 중에서 20m(8000세션)+timeout 180분으로 지정하신 사례가 있긴 하네요. 상황 봐가면서 적당히 증감하세요.
ssl_session_ticket에 대해서는 이 글이 정리가 잘 되어 있었습니다.
ssl_ciphers에 대한 설명도 Nginx 문서에 나와 있긴 한데 이해가 잘 안 되더군요(openssl ciphers 명령어는 유용할 것 같습니다.). ssl_ciphers 설정값은 국내외 상관없이 너무 다양해서 어떻게 정해야 할지 혼란스러웠습니다. 터미널 창에 openssl ciphers라고 입력해서 cipher 종류를 파악한 다음 암호화 스위트(Cipher Suite)의 구조에 대해 설명한 국내 글을 바탕으로 구글링해서 본인만의 값을 추려보세요.
https://blog.lael.be/post/5107
https://swiftcoding.org/nginx-routing-conf
https://blog.hakase.io/nginx-ssl-set
https://www.mynotes.kr/optimizing-https-on-nginx/
https://twpower.github.io/44-set-free-https-by-using-letsencrypt
▲ 다양한 Let's Encrypt 설정 관련 글들을 참고했었는데,
https://gist.github.com/plentz/6737338
https://gist.github.com/cecilemuller/a26737699a7e70a7093d4dc115915de8
https://mozilla.github.io/server-side-tls/ssl-config-generator/
▲ 위의 세 링크에서 ssl_ciphers 값에 대해 도움을 가장 많이 받았습니다. 스크린 샷의 사이퍼 값은 모질라 제너레이터에서 가져온 것이고요. 사이퍼 값은 시간이 지나면서 수정·보완될 확률이 높으니까... 웹브라우저 쪽에서 기술을 적극적으로 수용하는 모질라 재단의 가이드를 수시로 체크하고 따르기에는 모질라 제너레이터를 쓰는 게 적격이라고 생각했습니다.
▲ 이런 식으로 옵션을 적당히 고르고 Nginx 버전과 OpenSSL 버전을 적으면 코드가 생성되는데,
▲ 버전 체크는 터미널 창에서 nginx -v | openssl version 이런 식으로 입력해서 봤네요.
마지막으로 HSTS(HTTP Strict Transport Security) 설정과 (의미를 정확하게 모르는) 이런저런 설정을 적었습니다.
▲ 붉게 네모친 부분처럼 적어봤어요.
Content-Security-Policy 에서 'self'값을 적은 요소들은 출처가 본인의 홈페이지일 때에만 실행된다고 합니다(구글 : 콘텐츠 보안 정책). 저는 이미지를 외부에서 끌어오는 경우가 많은지라 문제가 생길 것 같아서 add_header Content-Security-Policy 줄을 전부 지웠습니다.
▲ Let's Encrypt 적용을 위한 서버블록 재구성 작업이 완료되었습니다. 저장하고 빠져나와서 Nginx 서비스를 재시작해 주세요. 그리고 https://www.ssllabs.com/ssltest 에서 사이트를 테스트해봅니다.
▲ A+ 뜨네요.
만약 오른쪽의 모든 항목을 100으로 올리고 싶다면 구글에서 nginx Cipher Strength 100 이라고 친 다음 "이미지"탭을 보세요. 문서들이 제법 나올 겁니다(적용 이후 사이트 호환성이 떨어질 수 있음.).
▲ Cipher Suites에서도 WEAK 뜨던 게 사라졌습니다. 잘 구성된 것 같아요.
홈페이지 이용 중에 HSTS 적용 중단이 필요한 때가 있는 것 같은데, 그때는 구글링 해보세요. 친절한 한글 설명이 많을 겁니다.
5. 발급받은 인증서의 갱신(기간 도래시)과 갱신 자동화
Let's Encrypt SSL 인증서 재발급은 리밋 한도 내에서 (발급 절차와 동일한 방법으로) 언제든지 가능하니까 언급하지 않겠습니다.
기간이 도래하는 인증서는 갱신 절차를 밟으면 되는데,
▲ /etc/letsencrypt/renewal/ 디렉토리에 갱신 설정파일이 있는 사이트들만 갱신이 되는 것 같습니다.
설정 파일을 열어보니까 만료 30일 이전부터 갱신이 가능한 것 같고요.
▲ 터미널 창에서 sudo certbot certificates 라고 치면 인증서들의 유효기간이 나옵니다.
▲ sudo letsencrypt renew --dry-run 이라고 쳐서 테스트했더니 통과는 하더군요.
▲ --dry-run 옵션 빼고 실제로 진행해보니 아직 때가 아니라고;;; (Cert not yet due for renewal)
그래서 이번 글은 일단 공개하고, 인증서 만료 기간이 되면 아래에 보충하겠습니다!
※ 시간을 따로 내기가 어려울 것 같아 https://jimnong.tistory.com/742 에서 복붙합니다.
터미널 창을 띄우고(Ctrl+Alt+T), sudo crontab -e 라고 입력합니다.
(root 권한의 crontab에 등록하려고 sudo를 앞에 붙인 겁니다. sudo gedit /var/spool/cron/crontabs/root 처럼 입력해도 됩니다. /var/spool/cron/crontabs/ 경로에 우분투 계정 이름으로 계정별 crontab 파일이 있거든요.)
Select an editor. To change later, run 'select-editor'.
1. /bin/nano <---- easiest
2. /usr/bin/vim.tiny
3. /bin/ed
▲ 참고로 기본 에디터는 nono일 거고, select-editor 명령어를 통해 바꿀 수 있습니다.
▲ 저는 제일 아랫줄에 붉은 네모로 표시한 것처럼 입력하고 Ctrl+X 를 눌러 저장+빠져나왔는데요,
10 4 */15 * * /usr/bin/letsencrypt renew >> /var/log/letsencrypt/letsencrypt-renew.log
15 4 */15 * * /usr/sbin/service apache2 restart
크론탭은
* * * * * 수행할 명령어
이런 형식으로 구성하면 되는데, * * * * * 의 각 자릿값은 "분(0~59) / 시(0~23) / 일(1~31) / 월(1~12) / 요일(0~6) (0:일요일, 1:월요일, 2:화요일, …, 6:토요일)" 을 뜻합니다.
입력한 명령어들을 해석해보면
15일에 한번씩(*/15 - 31일인 달은 1일, 16일, 31일 / 30일인 달은 1일, 16일) 새벽 4시 10분에 letsencrypt renew 명령을 실행하고, letsencrypt-renew.log 기록을 /var/log/letsencrypt/ 경로에 남겨라.
15일에 한번씩(*/15) 새벽 4시 15분에 아파치 서비스를 재시작하라.
이렇습니다. 갱신한 인증서는 아파치를 재시작해야 반영되거든요.
(31일과 다음 달 1일 간의 차이가 너무 짧아서 한 달에 두 번(1일, 16일)으로 날짜를 정해서 실행하고 싶다면 " 10 4 1,16 * * " 이런 식으로 구성하면 됩니다.)
▲ 갱신 로그 파일을 확인해봤는데, 정상적으로 처리된 것 같고,
▲ 인증서 유효기간을 확인해봤는데... 잘 된 것 같죠?
자동 갱신 관련 설명은 이것으로 끝입니다.
리눅스에 익숙치 않아서 Crontab 구성이 어렵게 느껴지면 https://crontab.guru/ 사이트에서 GUI로 극복해보시고요,
터미널 창에서 sudo crontab -l 이라고 입력하면 루트 계정의 크론탭 작업목록을 확인할 수 있고, "sudo crontab -l -u 계정명" 처럼 입력하면 우분투 계정별 크론탭 작업목록을 확인할 수 있습니다. 참고하세요.
----------------------------------------------------
※ Let's Encrypt 인증서 폐기 방법, 다양한 조건에서의 인증서 발급/재발급 실험들이 궁금하시면 https://jimnong.tistory.com/742 에서 Ctrl+F 누르고 '절취선'이라고 입력해보세요.
긴 글 읽어주셔서 감사합니다.
▲ [티비플] 아카펠라로 느낄수 있는 최고의 소름. 이어폰/헤드폰으로 들어보세요.
Austin Jones. 사고만 안 쳤어도...
▲ 영상 잘릴 경우를 대비 : Pentatonix – Joy To The World
'도움이 되는 Tip > 리눅스&워드프레스' 카테고리의 다른 글
| [우분투 18.04 데스크톱] LEMP : 엔진엑스(Nginx)로 파일을 공유해보자(WebDAV 추가) (0) | 2019.02.06 |
|---|---|
| [우분투 18.04 데스크톱] LEMP : 엔진엑스(Nginx) 설정 - 브라우저 캐시(for 워드프레스) (0) | 2019.01.27 |
| [우분투 18.04 데스크톱] LEMP : 엔진엑스(Nginx) 설정 - gzip 압축(for 워드프레스) (0) | 2019.01.26 |