Kết hợp Let’s Encrypt SSL với Cloudflare Proxy: Mô hình HTTPS an toàn cho website

Khi triển khai website sử dụng Cloudflare, nhiều quản trị viên thường thắc mắc: Có thể vừa sử dụng SSL Let’s Encrypt trên máy chủ, vừa bật Cloudflare Proxy đám mây cam hay không?

Câu trả lời là hoàn toàn có thể. Không những vậy, đây còn là một mô hình triển khai HTTPS khá phổ biến và phù hợp cho các hệ thống website chạy thực tế.

Mô hình tổng thể sẽ như sau:

Trong mô hình này, cả hai đoạn kết nối đều được mã hóa HTTPS.

1. Cloudflare Proxy hoạt động như thế nào?

Khi một tên miền được bật chế độ Proxied trên Cloudflare, hay thường được gọi là bật đám mây màu cam, người dùng sẽ không kết nối trực tiếp tới địa chỉ IP của máy chủ web.

Thay vào đó, luồng truy cập sẽ là:

Người dùng

↓

Cloudflare

↓

Máy chủ Origin

Cloudflare đứng giữa người dùng và máy chủ thật, đóng vai trò reverse proxy.

Điều này mang lại nhiều lợi ích như:

Che địa chỉ IP máy chủ origin.
Hỗ trợ chống tấn công DDoS.
Có thể sử dụng Web Application Firewall.
Hỗ trợ CDN và caching.
Giảm lượng truy cập trực tiếp vào máy chủ.
Quản lý SSL thuận tiện hơn.

Tuy nhiên, Cloudflare đứng giữa không có nghĩa rằng máy chủ phía sau không cần HTTPS.

Đối với một hệ thống production, kết nối từ Cloudflare về máy chủ origin cũng nên được mã hóa.

2. SSL trong mô hình Cloudflare được chia thành hai lớp

Khi sử dụng Cloudflare Proxy, thực tế sẽ tồn tại hai kết nối HTTPS riêng biệt.

Kết nối thứ nhất: Người dùng → Cloudflare

Ví dụ:

Trình duyệt

↓ HTTPS

Cloudflare

Ở kết nối này, trình duyệt sẽ nhìn thấy chứng chỉ SSL do Cloudflare cung cấp.

Đây là lý do khi kiểm tra chứng chỉ trực tiếp trên Chrome, bạn có thể không nhìn thấy chứng chỉ Let’s Encrypt đang cài trên server.

Điều này hoàn toàn bình thường.

Kết nối thứ hai: Cloudflare → Máy chủ

Cloudflare

↓ HTTPS

Server

Kết nối này có thể sử dụng chứng chỉ:

Let’s Encrypt.
Cloudflare Origin Certificate.
Chứng chỉ SSL từ các CA khác.

Nếu máy chủ đã sử dụng Let’s Encrypt thì hoàn toàn có thể tiếp tục sử dụng chứng chỉ đó.

Mô hình lúc này sẽ là:

Browser

│

│ HTTPS - SSL Cloudflare

▼

Cloudflare

│

│ HTTPS - Let's Encrypt

▼

Apache / Nginx

│

▼

Website

Như vậy dữ liệu được mã hóa trên toàn bộ đường truyền.

3. Cấu hình Cloudflare nên sử dụng Full (strict)

Nếu server đang có chứng chỉ Let’s Encrypt hợp lệ, chế độ SSL phù hợp nhất trên Cloudflare là:

SSL/TLS

→ Overview

→ Full (strict)

Ở chế độ này, Cloudflare sẽ kết nối HTTPS tới máy chủ origin và kiểm tra chứng chỉ SSL của máy chủ.

Chứng chỉ cần:

Còn thời hạn.
Đúng tên miền.
Được cấp bởi một CA hợp lệ.

Let’s Encrypt đáp ứng đầy đủ các yêu cầu này.

Không nên sử dụng chế độ:

Flexible

với một hệ thống đã có HTTPS trên origin.

Flexible chỉ mã hóa đoạn:

Người dùng → Cloudflare

nhưng kết nối:

Cloudflare → Server

có thể vẫn là HTTP.

Với hệ thống production, nên ưu tiên:

Full (strict)

4. Vấn đề thường gặp khi gia hạn Let’s Encrypt

Let’s Encrypt thường sử dụng quá trình xác minh quyền sở hữu tên miền trước khi cấp hoặc gia hạn chứng chỉ.

Một trong những phương pháp phổ biến là HTTP-01.

Ví dụ Certbot cần truy cập:

http://domain.com/.well-known/acme-challenge/...

Khi Cloudflare Proxy đang bật, trong một số cấu hình đặc biệt, việc xác minh có thể gặp vấn đề do request đi qua Cloudflare trước khi tới máy chủ.

Một số quản trị viên xử lý bằng cách:

Tạm thời chuyển DNS từ Proxied sang DNS Only.
Gia hạn chứng chỉ.
Bật lại Proxy.

Cách này có thể hoạt động nhưng không thuận tiện nếu cần tự động hóa hoàn toàn.

Một giải pháp tốt hơn là sử dụng DNS-01 Challenge.

5. Sử dụng DNS-01 với Cloudflare

DNS-01 cho phép Let’s Encrypt xác minh domain thông qua bản ghi DNS.

Quá trình hoạt động có thể hình dung như sau:

Certbot

↓

Cloudflare API

↓

Tạo TXT record

↓

Let's Encrypt kiểm tra DNS

↓

Xác minh thành công

↓

Cấp SSL

Certbot có thể sử dụng Cloudflare API để tự động tạo một TXT record dạng:

_acme-challenge.example.com

Sau khi Let's Encrypt xác minh thành công, bản ghi này sẽ được Certbot xóa tự động.

Ưu điểm lớn nhất là:

Không cần tắt Cloudflare Proxy khi gia hạn SSL.

Đám mây cam có thể được giữ nguyên liên tục.

6. Cài Certbot Cloudflare trên Ubuntu

Đối với máy chủ Ubuntu sử dụng Apache hoặc Nginx, có thể cài Certbot và plugin Cloudflare.

Ví dụ:

sudo apt update

sudo apt install certbot python3-certbot-dns-cloudflare

Sau đó tạo Cloudflare API Token.

Trong Cloudflare, tạo API Token với quyền quản lý DNS cho zone cần sử dụng.

Nên giới hạn token chỉ cho domain cần thiết thay vì sử dụng Global API Key.

Ví dụ quyền:

Zone

DNS

Edit

7. Tạo file chứa Cloudflare API Token

Tạo thư mục:

sudo mkdir -p /root/.secrets/certbot

Tạo file:

sudo nano /root/.secrets/certbot/cloudflare.ini

Nội dung:

dns_cloudflare_api_token = API_TOKEN_CUA_BAN

Sau đó giới hạn quyền truy cập:

sudo chmod 600 /root/.secrets/certbot/cloudflare.ini

Bước này rất quan trọng vì file chứa API Token của Cloudflare.

8. Cấp SSL Let’s Encrypt

Giả sử tên miền là:

example.com

www.example.com

Có thể chạy:

sudo certbot certonly \

--dns-cloudflare \

--dns-cloudflare-credentials /root/.secrets/certbot/cloudflare.ini \

-d example.com \

-d www.example.com

Sau khi cấp thành công, chứng chỉ thường nằm tại:

/etc/letsencrypt/live/example.com/

Trong đó có các file:

fullchain.pem

privkey.pem

9. Cấu hình Apache sử dụng Let’s Encrypt

Đối với Apache:

SSLEngine on

SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem

SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

Sau khi chỉnh sửa cấu hình nên kiểm tra:

sudo apache2ctl configtest

Nếu kết quả:

Syntax OK

thì reload Apache:

sudo systemctl reload apache2

10. Cấu hình với Nginx

Nếu sử dụng Nginx:

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Sau đó kiểm tra:

sudo nginx -t

và reload:

sudo systemctl reload nginx

11. Kiểm tra khả năng tự động gia hạn

Sau khi cấu hình xong nên chạy:

sudo certbot renew --dry-run

Nếu quá trình kiểm tra hoàn tất thành công thì Certbot có thể tự động gia hạn SSL sau này.

Đây là một bước rất quan trọng trước khi đưa hệ thống vào production.

12. DNS vẫn giữ Cloudflare Proxy

Sau khi hoàn tất, bản ghi DNS vẫn có thể để:

example.com A IP_SERVER Proxied

www CNAME example.com Proxied

Tức là vẫn bật đám mây cam.

Không cần chuyển sang DNS Only để website hoạt động với Let’s Encrypt.

13. Tại sao trình duyệt không hiển thị chứng chỉ Let’s Encrypt?

Một điểm khiến nhiều quản trị viên nhầm lẫn là:

Sau khi cài Let’s Encrypt trên server nhưng khi kiểm tra SSL trên trình duyệt lại thấy chứng chỉ của Cloudflare.

Đây là hoạt động hoàn toàn bình thường.

Nguyên nhân là trình duyệt đang kết nối tới:

Cloudflare

chứ không kết nối trực tiếp tới:

IP Server

Do đó trình duyệt nhìn thấy SSL ở lớp:

Browser → Cloudflare

Chứng chỉ Let’s Encrypt chỉ được sử dụng cho lớp:

Cloudflare → Origin Server

14. Kiểm tra trực tiếp chứng chỉ trên Origin Server

Nếu muốn kiểm tra server có thực sự đang sử dụng Let’s Encrypt hay không, có thể kết nối trực tiếp tới IP origin.

Ví dụ:

openssl s_client \

-connect 1.2.3.4:443 \

-servername example.com \

/dev/null | \

openssl x509 -noout -issuer -subject -dates

Nếu server đang sử dụng Let’s Encrypt, thông tin issuer sẽ thể hiện CA liên quan tới Let’s Encrypt.

15. Có nên chặn truy cập trực tiếp tới IP Server?

Nếu Cloudflare đã được sử dụng như reverse proxy, một biện pháp bảo mật nâng cao là giới hạn quyền truy cập trực tiếp vào web server.

Mục tiêu là:

Internet

│

│ Không truy cập trực tiếp

▼

Origin Server

Chỉ cho phép:

Cloudflare

↓

Origin Server

Điều này giúp hạn chế kẻ tấn công bỏ qua Cloudflare và truy cập trực tiếp vào IP thật của máy chủ.

Có thể thực hiện thông qua:

UFW.
iptables.
nftables.
Firewall của nhà cung cấp Cloud/VPS.
Security Group.

Tuy nhiên cần cập nhật chính xác dải IP Cloudflare và kiểm tra kỹ trước khi áp dụng để tránh tự khóa truy cập vào hệ thống.

16. Đừng quên cấu hình IP thật của người dùng

Khi Cloudflare Proxy được bật, kết nối tới Apache hoặc Nginx đến từ IP của Cloudflare.

Nếu không cấu hình đúng, log server có thể chỉ ghi:

IP Cloudflare

thay vì IP thực tế của người truy cập.

Cloudflare gửi thông tin IP người dùng qua các header tương ứng.

Do đó với các hệ thống cần:

Theo dõi log.
Rate limit.
Fail2Ban.
Phân tích truy cập.
Giới hạn IP.
Điều tra sự cố bảo mật.

nên cấu hình Apache hoặc Nginx để nhận đúng IP client từ Cloudflare.

17. Mô hình đề xuất cho hệ thống production

Một kiến trúc hoàn chỉnh có thể triển khai như sau:

Các thành phần chính:

Cloudflare Proxy : ON

SSL Mode : Full (strict)

Origin SSL : Let's Encrypt

Let's Encrypt Verify : DNS-01

DNS Automation : Cloudflare API

Certificate Renewal : Certbot

Đây là mô hình đơn giản nhưng mang lại mức độ bảo mật tốt cho nhiều hệ thống website.

18. Ưu điểm của mô hình Cloudflare + Let’s Encrypt

Việc kết hợp Cloudflare Proxy với Let’s Encrypt mang lại nhiều lợi ích.

Mã hóa toàn bộ đường truyền

Cả hai đoạn:

Client → Cloudflare

Cloudflare → Server

đều sử dụng HTTPS.

Không phụ thuộc hoàn toàn vào Cloudflare SSL

Máy chủ origin vẫn sở hữu chứng chỉ SSL hợp lệ riêng.

Nếu cần tạm thời bỏ proxy Cloudflare, website vẫn có thể phục vụ HTTPS trực tiếp.

Gia hạn hoàn toàn tự động

Nếu sử dụng DNS-01 Cloudflare API, Certbot có thể tự gia hạn SSL mà không cần:

Tắt Proxy

→ Gia hạn SSL

→ Bật Proxy

Bảo vệ Origin Server

Cloudflare có thể đứng trước hệ thống và xử lý nhiều lớp bảo vệ trước khi request tới server.

Phù hợp với nhiều nền tảng

Mô hình này có thể sử dụng cho:

WordPress.
WooCommerce.
Canvas LMS.
Moodle.
Laravel.
Node.js.
Website PHP.
Apache.
Nginx.
Reverse Proxy.
Các hệ thống web application khác.

Kết luận

Cloudflare Proxy và Let’s Encrypt không phải hai giải pháp loại trừ lẫn nhau.

Ngược lại, chúng có thể kết hợp rất tốt.

Một cấu hình được khuyến nghị là:

Cloudflare SSL:

Full (strict)

Origin Server:

Let's Encrypt

Xác minh Let's Encrypt:

DNS-01 qua Cloudflare API

Gia hạn:

Certbot tự động

Luồng truy cập cuối cùng:

Với cách triển khai này, website vừa tận dụng được các tính năng proxy, CDN và bảo mật của Cloudflare, vừa duy trì một kết nối HTTPS hợp lệ từ Cloudflare tới máy chủ origin.

Đây là một kiến trúc phù hợp cho nhiều hệ thống web cần vận hành ổn định, bảo mật và dễ tự động hóa trong môi trường production.