클라우드플레어(Cloudflare)의 범용 인증서와 원본서버 인증서

🗒️ 개요

클라우드플레어(Cloudflare)의 서비스 중 범용 인증서와 원본서버를 처음 보게되면 되게 낯설고 범용 인증서와 원본 서버 인증서가 무엇을 의미하는지 알기 어려울 것으로 예상된다.

Let’s Encrypt를 통한 SSL 인증서 발급과 서버에 적용하는 방법은 한국어 웹 페이지가 많았지만, 클라우드플레어의 범용 인증서와 원본서버 인증서를 사용하는 웹페이지는 상대적으로 적었으며 해당 글들의 내용 또한 상당수 간략화하여 설명하고 있기 때문에 처음 입문하는 과정에서 어려움을 겪게된다.

본 글은 NGINX를 예시로 클라우드 플레어의 원본서버 인증서를 적용하고 클라우드플레어의 범용 SSL 인증서가 어떻게 작동하는지에 대해 간략하게 설명하며, HTTP, HTTPS, SSL, TLS와 같은 실제 통신 과정에 대한 요소들의 자세한 설명은 배제하고, 추후 Docker-compose를 이용하여 WordPress, mariaDB, NGINX를 이용한 블로그에 SSL 인증서를 적용하여 HTTPS 접속을 구현하는 글을 이해하기위한 배경지식이 되는 글임을 미리 알린다.

🧶 범용 인증서와 원본서버 인증서의 이해

⚔️ 클라우드플레어 인증서의 장/단점

클라우드플레어의 DNS는 SSL 인증서를 기본적으로 발급해준다. 물론, 클라우드플레어의 SSL 인증서를 이용하지 않고 Cerbot을 사용해 Let’s Enecrypt에서 SSL 인증서를 발급 받아 HTTPS를 구현할 수 있다. 하지만, Certbot으로 인증서를 발급 받다 실수하거나, 의도치 않은 인증서 다중 발급시 시간제한과 같은 문제가 발생하여 인증서를 발급 받지 못하고 기다리는 상황이 발생하기도 한다.

이와 다르게 클라우드플레어는 SSL 인증서와 원본 서버 인증서를 이용해 인증서 발급에 대한 실수를 해도 크게 문제없이 다시 설정할 수 있다는게 장점을 가지고 있다. 또한, 클라우드플레어의 범용 인증서는 3개월마다 자동으로 갱신되며 원본서버 인증서는 15년이라는 긴 기간동안 사용이 가능하다. Cerbot을 사용하여 인증서 갱신을 굳이 자동화하지 않아도 된다는 뜻이다.

하지만, 물론 장점만 있는것이 아닌 단점도 있다. 클라우드플레어의 DNS 프록시를 무조건 사용해야 SSL 인증서와 원본 인증서를 통한 HTTPS를 구현할 수 있다. 클라우드플레어의 국내 DNS 프록시는 국내의 망 중립성과 국내 통신사(ISP)들의 과도한 비용 발생이라는 이슈가 있는데 이 이야기는 본 글의 주제를 벗어나므로 추후 이야기 하도록 하겠다.

아무튼, 클라우드플레어 DNS 프록시의 단점은 클라우드플레어의 외국에 위치한 DNS 서버를 거쳐 접속해야해서 외국에 위치한 서버는 유리하겠지만 국내 서버는 조금 느린 접속속도를 보여주므로 본인의 서비스를 어느 지역에서 제공할지 고민해봐야 한다.

그래도 이러한 단점을 뒤로하고 클라우드플레어의 SSL 인증서와 원본인증서는 타 서비스의 인증서를 발급받는 스트레스나 비용을 간단하게 해결할 수 있는 정말 좋은 서비스이다. 또한, 클라우드플레어 서비스를 이용한다는건 DDoS Protection과 도메인의 분석 및 로그 등과 같은 서비스도 이용할 수 있기 때문이다.

✨ 범용 인증서와 원본서버 인증서에 대한 이해

우선, 서버의 HTTPS를 구성하기전 클라우드플레어의 SSL 인증서와 원본서버 인증서에 대한 이해가 필요하다.

클라우드 플레어의 범용 인증서는 우리가 웹사이트에 접속할 때, 주소표시줄 좌측에 뜨는 좌물쇠 모양과 같이 일반적인 SSL 인증서와 크게 다를것 없다. 다음 그림을 보자.

위의 그림과 같이 클라우드플레어 DNS를 이용하지 않는 경우 우리는 서버와 웹을 연결할 때, 기존처럼 SSL 인증서를 가지고 처리하면 HTTPS를 이용하여 웹사이트를 접속할 수 있고 클라우드 플레어의 DNS를 이용하여 서버에 접속해도 동일하게 HTTPS가 적용된 것을 볼 수 있다.

여기서 클라우드플레어 DNS를 이용하는 경우 웹과 클라우드플레어 사이가 SSL 인증서로 적용된다는 것은 알겠는데 뭔가 하나 빠진것 같은 느낌을 받을 수 있다.

그렇다. 바로 여러분의 서버 즉, 웹 서비스를 제공할 서버가 그림에서 존재하지 않는다. 당연하게도 클라우드플레어 DNS 프록싱을 이용하면 방문자들은 여러분의 서버에 바로 접속하는 것이 아닌 클라우드플레어를 방문하게 된다.(CDN의 역할을 생각하면 당연한 것이다.) 이 부분에서 일반적인 SSL 인증서를 적용하는 것과 달라 해매게 되는 큰 이유이다.

그래도 이해가 어렵다면 다음 그림을 보자.

클라우드플레어를 통한 인증을 하였을 때, 일반적인 SSL 인증서를 적용하는 과정과 차이점이 확연하게 다름을 알 수 있다.

위의 그림에서 상단의 그림과 같이 인터넷과 서버사이에 SSL 인증서만 관여하던 것과 달리, 하단의 그림처럼 클라우드플레어를 경유하게 되면 인터넷 ↔ 클라우드플레어 사이에서 SSL 인증서를 이용하고, 이후 클라우드플레어 ↔ 서버 사이에서도 원본 서버 인증서를 이용하여 각각의 경로간을 암호화하여 데이터를 주고 받게 된다.

이와 같이 일반적인 SSL 인증서를 적용하는 방법과 다른 이유는 클라우드플레어는 CDN(Contents Delivery Network) 서비스를 제공하기 때문이다.

콘텐츠 전송 네트워크(CDN)란?

콘텐츠 전송 네트워크(CDN)는 최종 사용자와 가까운 곳에 콘텐츠를 캐시하는 지리적으로 분산된 서버 그룹입니다. CDN을 사용하면 HTML 페이지, JavaScript 파일, 스타일시트, 이미지, 동영상 등 인터넷 콘텐츠를 로드하는 데 필요한 자산을 빠르게 전송할 수 있습니다.¹

CDN의 의미를 알았으니 왜 HTTPS 접속을 구현하는데 일반적인 범용 인증서를 적용하는 중간에 클라우드플레어가 개입하여 각 양단을 암호화하는 과정을 거치는지 이해가 되었을 것으로 예상한다.

클라우드플레어에서 원본 서버에서 데이터를 가져와야 하므로(당연히 경로는 암호화되어야한다.) 원본서버와 클라우드플레어 사이를 암호화된 경로를 통해 웹 페이지 데이터를 주고 받아야한다. 그래서 원본 서버 인증서를 적용하여 클라우드플레어 ↔ 원본 서버간 암호화된 경로를 만들어 데이터를 주고 받을 수 있도록 하는 것이다.

또한, 클라우드플레어에서 인터넷에서 접속한 사용자들에게 웹 페이지 데이터를 전송해주어야 하는데, 당연히 암호화된 경로로 데이터를 주고 받아야하므로 SSL 인증서를 통해 인터넷 ↔ 클라우드플레어간 암호화된 경로를 만들어 데이터를 주고 받을 수 있도록 하는 것이다.

💾 에지 인증서와 원본 서버 인증서 적용하기

✨ 용어 정리

자, 그럼 이제부터 범용 SSL 인증서는 에지 인증서로 부르도록 하겠다. 몇몇 사람들은 ‘그래서 클라우드플레어에서 SSL 인증서는 어디 있는데?’ 하는 의문을 가질 수 있을것 같다. 편의상 에지 인증서를 SSL 인증서라고 부른 이유는 SSL 인증서를 에지 인증서로 먼저 부르면 일반적인 SSL 인증서와 에지 인증서를 다른 인증서로 생각 할 수 있기 때문이다. (물론, 다른 시각으로 보면 두 인증서는 다른 용도로 쓰이긴 하지만 실제 웹 페이지에 방문시 동일한 과정을 통해 HTTPS 접속을 구현한다.)

이제부터 에지 인증서 = SSL 인증서로 인지해주길 바라며, 이유는 실제 클라우드플레어와 서버의 NGINX를 통해 HTTPS 통신을 구축하는 것에 대한 용어 정리가 필요함 때문이다.

🧶 적용하기 전

이미 도메인을 클라우드플레어에서 등록하거나 연결했을거라 가정하고 진행하도록 한다.

우선, 클라우드플레어에 로그인하여 대시보드에서 자신이 보유하고 있는 도메인을 선택하고 SSL/TLS 항목으로 이동하자.

해당 페이지로 이동하면 어디선가 보았던 것 그림인것 같은 느낌이 들 것이다. 바로, 위에서 설명했던 그림의 원본이 되는 설정이다. 앞에서 이야기 했던 부분을 이해하지 못하면 이 설정 부분에서 막히게 될 것이다.

클라우드플레어의 SSL/TLS에서 제공하는 위의 옵션들인 [끄기, 가변, 전체, 전체(엄격)]의 4개의 옵션들은 SSL/TLS를 어떻게 적용할 것인지에 대한 설정이기 때문이다.

여기서 클라우드플레어의 에지 인증서를 적용하기 싫고, Cerbot과 같이 다른 SSL 인증서를 발급받아 적용한다면 클라우드플레어의 도메인 프록싱을 끄거나 위의 설정에서 끄기를 선택해야 할 것이다. 가변의 경우 Cerbot으로 SSL 인증서를 받고 적용할 수 있기는 했지만, 생각대로 적용이 안되거나 문제가 생기는 경우가 있기도 해서 추후 정확한 내용 확인 후 설명을 보강하겠다.

⌨️ NGINX 이외의 웹 서버에 적용하는 법

본 글은 NGINX의 설정을 통해 SSL 인증서를 적용하는 글이다보니 이외의 웹 서버(Apache Tomcat, AWS, IIS 등)에서 적용하려는 방법도 필요로 할 것이다. 추후 Tomcat을 통한 인증방법은 내용을 보강하겠지만, 다른 서비스의 경우 클라우드플레어에서 제공한 링크를 통해 적용하는 방법을 참고하길 바란다. (영문)

• Apache httpd
• GoDaddy Hosting
• Microsoft IIS 7
• Microsoft IIS 8 and 8.5
• Microsoft IIS 10
• Apache Tomcat
• Amazon Web Service
• Apache cPanel
• Ubuntu Server with Apache2

출처 : https://developers.cloudflare.com/ssl/origin-configuration/origin-ca

🎫 NGINX 웹 서버에 원본 인증서 적용하기

자, 이제 본격적으로 NGINX 웹 서버에 원본 인증서(Origin-CA)를 적용하는 과정을 보도록 한다. 우선, 클라우드플레어 대시보드에서 자신의 도메인을 선택 후 SSL/TLS로 이동하고 이후 원본 서버를 선택한다. 원본 서버 항목에 이동해보면 아직 발급된 인증서가 없을 것이다.

인증서 생성을 눌러 다음 페이지로 이동한다.

여기서 별다른 설정 없이 바로 생성을 눌러도 되고 본인의 필요에 따라 설정을 변경해도 된다. 특히, 인증서 유효기간의 경우 본인의 편의에 맞추어 생성하면 되며, 도메인 와일드 카드가 필요 유/무에 따라 X 버튼을 눌러 제거하는 등 설정을 맞추면된다. 필자는 별다른 설정을 건들지 않고 생성하는 것을 추천한다.

이후 생성되는 원본 인증서와 개인 키를 서버에 저장한다. 파일 이름의 경우 임의로 지정해도 괜찮지만, 쉽게 구분하기 위해 본 글에서는 원본 인증서는 { origin-ca_key.pem }, 개인 키는 { prvi_key.pem }으로 지정하여 설명한다.

저장 위치는 Docker(또는 Docker-Compose, 쿠버네티스 등)와 같은 컨테이너의 경우 NGINX가 읽을 수 있는 폴더에 넣어야한다. 이외의 경우에도 NGINX가 접근할 수 있는 폴더에 두어야한다.

다음은 NGINX의 설정 파일 예시이다.

nginx.conf

server {
    listen 80;
    listen [::]:80;
    server_name 도메인 주소;
    return 302 https://$server_name$request_uri; ← 도메인 주소를 HTTPS로 넘겨주는 내용이다.만약 HTTP 접속도 필요하다면, 이 부분의 return 내용을 제거하고 아래의 root와 index 내용 부분을 추가하면 될 것이다.
}

server {

    # SSL configuration

    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    ssl_certificate         /인증서 폴더/원본 인증서.pem;
    ssl_certificate_key     /인증서 폴더/개인키 인증서.pem;

    server_name 도메인 주소;

    root /var/www/html;
    index index.php index.html index.htm;
}

보라색으로 표기한 부분은 수정이 필요한 내용을 표기하였으며 본인의 서비스 연결에 따라 내용을 편집해야할 것이다. (물론, 기본 상태로도 진행이 가능할 것이다.)

다음은 적용 예시이다.

server {
    listen 80;
    listen [::]:80;
    server_name test.com www.test.com;
    return 302 https://$server_name$request_uri;
}

server {

    # SSL configuration

    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    ssl_certificate         /cert/origin-ca_key.pem;
    ssl_certificate_key     /cert/priv_key.pem;

    server_name test.com www.test.com;

    root /var/www/html;
    index index.php index.html index.htm;
}

이와 같이 NGINX의 파일을 설정해주고나서, 클라우드플레어 대시보드로 이동 후 SSL/TLS 페이지로 이동하여 다음과 같이 적용하자.

여기서 전체와 전체(엄격)의 차이는 적혀있는 내용과 동일하게 전체(엄격)의 경우 클라우드플레어 ↔ 원본 서버의 인증을 처리할 때, 우리가 상단에서 발급받았던 원본 서버 인증서 또는, 클라우드플레어 원본 서버 페이지에 별도로 발급받은 인증서를 업로드하여 처리해야 HTTPS가 적용되며 전체의 경우 별도로 발급받은 인증서로 클라우드플레어 등록없이 사용할 때 사용하는 옵션이다.

우리는 클라우드플레어에서 원본 인증서를 발급받아 서버에 적용하였으므로, 전체(엄격) 옵션을 선택하면 된다. 이후, 자신이 설정한 HTTPS 도메인으로 접속하여 HTTPS로 접속이 잘 되는지 확인하면 된다.(주소표시줄 옆에 좌물쇠가 뜬다면 제대로 적용된 것이 맞다.)

📒 마치며

지금까지 클라우드플레어의 에지 인증서와 원본 인증서를 알아보았다. NGINX로 설정하는 부분의 경우 NGINX를 처음 사용하거나 처음 입문하는 사용자에게 있어 조금 불충분한 내용이지 않을까 우려스러운 부분이 있어 추후, docker-compose를 이용하여 WordPress, mariaDB, nginx를 이용해 블로그를 구성하면서 SSL 인증서까지 적용하는 방법을 상세하게 적은 내용을 작성할 것을 약속하며 본 글은 해당 글을 위한 배경지식을 간단하게 알아보는 내용임을 다시금 알린다.

1. 콘텐츠 전송 네트워크(CDN)란? | CDN의 작동 방식은?https://www.cloudflare.com/ko-kr/learning/cdn/what-is-a-cdn/ ↩︎