최근 브라우저들이 Mixed contents 사용을 강제로 막으면서 WordPress에 SSL 인증서를 적용하는 것이 매우 복잡해졌다. WordPress를 새로 설치할 일이 있었는데 443 만으로 진행했다가 매우 큰 낭패를 보고 며칠간 삽질 했다.. 간단하게 요오오즘 트랜드에 맞는 설정을 적용하기 위한 작업순서도를 정리해본다.
1. 443(SSL)만 열어놓고 설치를 시도하면 발생하는 이슈
- 설치 화면 부터 Mixed contents 경고가 발생함
- 그 화면에서 설치해도 로그인을 할 수 없음 (로그인 시도시 로그인 페이지 다시 돌아옴)
- 여기서 PHP는 어떠한 에러도 남기지 않음…. 대환장 🤦🏻♂️
2. 준비물
- 웹서버 또는 Reverse proxy 접근 권한
- SSL 인증서
- WordPress 설치 경험
강한 인내심…
3. 작업
Step 1. 설치할 서버(또는 reverse proxy)에 인증서 작업을 먼저 하되 80과 443을 둘 다 열어야 한다. 각종 443 redirect 옵션은 주석처리 하고 모든 작업이 끝나면 다시 활성화 한다.
예를 들어 NGINX는 아래와 같다
listen 80; # 이것도 살리고
listen 443; # 이것도 살려야한다
ssl_certificate ...;
ssl_certificate_key ...;
include ...;
ssl_dhparam ...;Apache는 아래와 같이 별도로 virtualhost를 적용한다.
<VirtualHost *:443>
#...
SSLEngine on
SSLProtocol ...
SSLCertificateKeyFile ...
SSLCertificateFile ...
SSLCertificateChainFile ...
SSLCACertificateFile ...
</VirtualHost>
<VirtualHost *:80>
#...
</VirtualHost>Step 2. wordpress를 http로 들어가서 설치한다. 근데 그렇게 들어가도 브라우저는 https로 자동 포워딩을 시도하고 인증서 에러를 띄우나, 예외를 걸고 우선 설치를 진행한다.
Step 3. 설치가 완료되면 Really Simple SSL 일단 플러그인을 먼저 설치하고 활성화 한다. 여기까지도 주소창의 자물쇠는 제대로 인증되지 않은 것으로 나온다.
Step 4. 플러그인 셋팅으로 진입하면 (설정 – SSL) ActiveSSL 이라고 뜬다. 살포시 눌러준다.
Step 5. 새로고침을 하면 재로그인을 시도한다. 당황하지 말고 로그인을 하자.
Step 6 로그인 후 다시 설정 – SSL로 진입해서 아래 항목을 켜주고 Save버튼을 누른다.
Mixed content fixer
Enable WordPress 301 redirect
Enable 301 .htaccess redirect
Fire mixed content fixer with different method
Dismiss all Really Simple SSL notices이렇게 하고 몇 번의 새로고침과 재로그인을 통하면 아래와 같은 초록색 진행바와 SSL is activated on your site. You still have 2 tasks open. 라는 말이 나오고, 주소창의 자물쇠도 잘 잠긴다. 그러면 모두 끝이다. 중간에 .htaccess 를 수정하라는 둥 별 소리가 나오지만 가볍게 무시하고 아래 화면이 나올때까지 묵묵히 새로고침을 하자.
100% 가 아니라고 슬퍼하지 말자 플러그인 유료결제 하라는 이야기다. 이정도는 애교다.. 다른 SSL 플러그인을 깔았더니 너무 노골적인 결제 유도가 스트레스 였다.
Step 7. 이제 웹서버나 reverse proxy에서 80포트를 닫거나 443 redirect 작업을 해주면 완벽하게 끝난다.
4. 설치 시 온전히 SSL만으로 진행 할 수 없는 이유
한마디로 WordPress의 역사가 https가 보편화 되고 표준이 된 역사보다 길기 때문이다.
Let’s encrypt가 있기 전에는 SSL 인증서는 연간 100만원 수준으로 매우 비싸서 개인은 함부로 엄두를 낼 수 없었고, TLS 통신만으로 웹사이트 접속 품질에 큰 영향을 미쳤다. 그 시절엔 뭐든 다 느렸으니까. Reverse proxy 개념도 없던 시절이라 웹서버가 정말 많은 일을 하던 시절엔 SSL 인증서를 기존 인프라에 도입하기는 부담이 컸다. TLS 통신은 어쨌든 오버헤드가 있기 때문에, 지금도 Load balance 또는 Reverse proxy 내부 망에서는 plain http로 통신 하는 것이 일반적이다.
WordPress가 변화에 적응해야 하는 것이 맞는지, SSL 강제 도입 수순에 순순히 따라가는게 맞는 일인지는 모르겠다. 내가 느끼기엔 너무 피곤하고, 비생산적인 삽질이였다.