No4. Cloudflare Full (strict) 設定：Origin CA、Nginx 與 Apache2

Cloudflare DNS 開啟 Proxy 後，瀏覽器建立 HTTPS 連線時，實際連到的是 Cloudflare Edge。瀏覽器驗證的也是 Cloudflare 提供的 Edge Certificate，而不是 GCP VM 上的憑證。

Cloudflare 連往 Origin 是另一條獨立連線。若這一段只使用 Full mode，資料雖然會經過 TLS 加密，Cloudflare 卻不會嚴格驗證 Origin Certificate 的簽發者、有效期與 hostname。Full (strict) 則會完成這些驗證。

Browser
  │ TLS #1：驗證 Cloudflare Edge Certificate
  ▼
Cloudflare
  │ TLS #2：驗證 Origin Certificate
  ▼
GCP VM
  └── Nginx 或 Apache2

本文使用一台 Ubuntu 24.04 GCP VM，依序完成 Cloudflare DNS Proxy、Origin CA Certificate、Nginx／Apache2 HTTPS、Origin 本機驗證與 Full (strict)。Nginx 與 Apache2 是兩個獨立範例，實際環境選擇目前使用的 Web Server 即可。

實作環境與驗收條件

本文使用以下範例值：

前置條件如下：

• Cloudflare zone 已經 Active，名稱伺服器設定正常。
• GCP VM 使用固定外部 IP。
• GCP Firewall 已允許 Cloudflare IPv4 CIDR 連入 Origin 443；若 VM 另有 External IPv6，必須使用獨立 IPv6 rule 同步限制。
• VM 上已有可正常回應網站的 Nginx 或 Apache2。
• 既有 Trusted Proxy 與 Access Log 設定可以直接保留。

預期完成狀態：

DNS：          www.example.com → Cloudflare Anycast IP
Proxy status： Proxied
Origin HTTPS： certificate chain 與 hostname 驗證通過
SSL/TLS mode： Full (strict)
正常流量：     Browser → Cloudflare → Origin 全程 HTTPS
Origin 來源：  仍只允許 Cloudflare，不因 TLS 設定而放寬

在 VM 確認目前的 listener 與網站設定：

sudo ss --listening --numeric --tcp --process

# Nginx
sudo nginx -T

# Apache2
sudo apache2ctl -S

www.example.com 必須對應到預期的 server block 或 VirtualHost。多個 HTTPS 網站共用同一個 IP 時，這項確認尤其重要，因為 TLS SNI 會決定 Web Server 提供哪一張憑證。

Cloudflare DNS Proxy 設定

進入 Cloudflare Dashboard 的 DNS 設定：

1. 選擇目標 zone。
2. 進入 DNS → Records。
3. 建立或編輯 www.example.com 的 A record。
4. IPv4 address 填入 GCP VM 的固定外部 IP。
5. Proxy status 設為 Proxied，也就是橘色雲朵。
6. 儲存設定。

A record 的 Content 應該是自己的 Origin IP，不是任一 Cloudflare IP。Proxied record 對外查詢時，Cloudflare 會回覆 Anycast IP，並將 HTTP／HTTPS 流量代理到 record 內保存的 Origin。Cloudflare：Proxy status

從外部網路查詢：

dig +short A www.example.com @1.1.1.1

預期看到 Cloudflare IP，而不是 203.0.113.10。Cloudflare 回覆的 IP 不需要和文章範例相同，也不應寫死在監控程式。

確認 Edge HTTPS：

curl --noproxy '*' \
  --silent \
  --show-error \
  --dump-header - \
  --output /dev/null \
  'https://www.example.com/'

Response Header 通常可以看到 CF-Ray。若 HTTPS certificate 尚未生效，先到 SSL/TLS → Edge Certificates 確認 Edge Certificate 狀態；Origin CA Certificate 不能取代這一張 Edge Certificate。

Proxied DNS 定義一般訪客的正常路徑，但不會刪除 DNS history，也不會強制 GCP VM 拒絕直連。既有 GCP Firewall 或 Web Server 來源限制仍然需要保留。

Cloudflare Origin CA 憑證

Cloudflare Origin CA Certificate 專門用於 Cloudflare 到 Origin 的連線。Cloudflare 會信任它，但一般瀏覽器的 public trust store 不會。因此，它適合已限制只接受 Cloudflare 流量的 Origin；需要讓瀏覽器或其他一般 client 直接連入 Origin 時，應改用 public CA certificate。Cloudflare：Origin CA

建立 Origin Certificate

進入 Cloudflare Dashboard：

1. 選擇目標 zone。
2. 進入 SSL/TLS → Origin Server。
3. 在 Origin Certificates 選擇 Create Certificate。
4. 選擇由 Cloudflare 產生 private key 與 CSR。
5. Private key type 選擇 RSA。
6. Hostname 明確加入 www.example.com。
7. Certificate Validity 依實際憑證管理週期選擇。
8. Key Format 選擇 PEM。
9. 建立後分別複製 Origin Certificate 與 Private Key。

Private Key 只會在建立畫面顯示一次。不要將它放進 Git repository、文章截圖、即時通訊、工單或 shell command argument。若離開畫面前沒有安全保存，只能重新簽發新的 certificate。

Wildcard *.example.com 只涵蓋一層 subdomain，例如 www.example.com，不涵蓋 zone apex example.com，也不涵蓋 api.internal.example.com。實際會提供服務的 hostname 應逐一確認 SAN；Origin CA 也不能用 IP address 當 SAN。Cloudflare：Origin CA hostname coverage

安裝 Certificate 與 Private Key

在 Origin VM 建立專用目錄：

sudo install -d \
  --owner=root \
  --group=root \
  --mode=0755 \
  /etc/ssl/cloudflare

將 Dashboard 顯示的 Origin Certificate 貼入：

sudo nano /etc/ssl/cloudflare/www.example.com.pem

檔案格式如下，正文與版本控制中不得放入實際內容：

-----BEGIN CERTIFICATE-----
REPLACE_WITH_ORIGIN_CERTIFICATE
-----END CERTIFICATE-----

將 Private Key 貼入另一個檔案：

sudo nano /etc/ssl/cloudflare/www.example.com.key

-----BEGIN PRIVATE KEY-----
REPLACE_WITH_PRIVATE_KEY
-----END PRIVATE KEY-----

設定 owner 與檔案權限：

sudo chown root:root \
  /etc/ssl/cloudflare/www.example.com.pem \
  /etc/ssl/cloudflare/www.example.com.key

sudo chmod 0644 /etc/ssl/cloudflare/www.example.com.pem
sudo chmod 0600 /etc/ssl/cloudflare/www.example.com.key

目錄與 certificate 可以被讀取，Private Key 本身仍只有 root 可以讀取。Nginx master process 或 Apache2 parent process 會先以必要權限載入 Private Key，再建立低權限 worker。

本文選擇 RSA，因此另外下載 Cloudflare 官方 RSA Origin CA root certificate，供 VM 本機驗證簽發鏈：

sudo curl \
  --fail \
  --silent \
  --show-error \
  --location \
  --output /etc/ssl/cloudflare/cloudflare-origin-ca-rsa.pem \
  'https://developers.cloudflare.com/ssl/static/origin_ca_rsa_root.pem'

sudo chown root:root \
  /etc/ssl/cloudflare/cloudflare-origin-ca-rsa.pem
sudo chmod 0644 \
  /etc/ssl/cloudflare/cloudflare-origin-ca-rsa.pem

若建立時選擇 ECC，應改用 Cloudflare Origin ECC PEM，不能沿用這個 RSA root file。官方下載位置可由 Cloudflare Origin CA root certificate 取得。

驗證 Certificate

先查看 certificate 內容：

sudo openssl x509 \
  -in /etc/ssl/cloudflare/www.example.com.pem \
  -noout \
  -subject \
  -issuer \
  -serial \
  -dates \
  -ext subjectAltName

檢查重點：

• notBefore 已生效，notAfter 尚未到期。
• subjectAltName 包含 DNS:www.example.com 或可正確涵蓋它的 wildcard。
• issuer 是 Cloudflare Origin CA。

驗證簽發鏈與 hostname：

sudo openssl verify \
  -CAfile /etc/ssl/cloudflare/cloudflare-origin-ca-rsa.pem \
  -verify_hostname www.example.com \
  /etc/ssl/cloudflare/www.example.com.pem

預期結果：

/etc/ssl/cloudflare/www.example.com.pem: OK

再比較 certificate 與 private key 的 public key SHA-256：

sudo openssl x509 \
  -in /etc/ssl/cloudflare/www.example.com.pem \
  -pubkey \
  -noout \
  | openssl pkey -pubin -outform DER \
  | sha256sum

sudo openssl pkey \
  -in /etc/ssl/cloudflare/www.example.com.key \
  -pubout \
  -outform DER \
  | sha256sum

兩個 SHA-256 必須完全相同。不同代表 certificate 與 private key 不是同一組，Nginx／Apache2 即使讀得到檔案，也無法正常載入這組 TLS identity。

Nginx／Apache2 HTTPS 設定

以下兩個分支擇一套用。既有網站若已包含 Application、PHP-FPM、WSGI 或 reverse proxy 設定，應保留原本的 location、ProxyPass、DocumentRoot 等內容，只替換 certificate path 並確認 HTTPS listener。

Nginx

確認 Nginx 編譯資訊與既有 site：

sudo nginx -V
sudo nginx -T

建立或修改 /etc/nginx/sites-available/www.example.com：

server {
    listen 443 ssl;
    server_name www.example.com;

    ssl_certificate     /etc/ssl/cloudflare/www.example.com.pem;
    ssl_certificate_key /etc/ssl/cloudflare/www.example.com.key;
    ssl_protocols TLSv1.2 TLSv1.3;

    root /var/www/html;
    index index.html;

    access_log /var/log/nginx/www.example.com.access.log combined;
    error_log  /var/log/nginx/www.example.com.error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

若 Nginx 是 reverse proxy，將上述 root、index 與 try_files 換回實際 Application 設定，例如：

location / {
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://127.0.0.1:8000;
}

若已建立 cloudflare_realip log format，可以把 combined 改成 cloudflare_realip，繼續同時記錄 Visitor IP 與 Cloudflare peer。

尚未啟用 site 時建立 symlink：

sudo ln --symbolic \
  /etc/nginx/sites-available/www.example.com \
  /etc/nginx/sites-enabled/www.example.com

若 symlink 已存在，不需要重複建立。檢查並套用：

sudo nginx -t
sudo systemctl reload nginx
sudo ss --listening --numeric --tcp --process | grep ':443'

預期 nginx -t 顯示 syntax 與 configuration test successful，並且 Nginx 正在監聽 443。

Nginx 設定結果：

Apache2

啟用 mod_ssl 並確認 module：

sudo a2enmod ssl
sudo apache2ctl -M | grep ssl

建立或修改 /etc/apache2/sites-available/www.example.com.conf：

<VirtualHost *:443>
    ServerName www.example.com

    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /etc/ssl/cloudflare/www.example.com.pem
    SSLCertificateKeyFile /etc/ssl/cloudflare/www.example.com.key
    SSLProtocol -all +TLSv1.2 +TLSv1.3

    <Directory /var/www/html>
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/www.example.com.error.log
    CustomLog ${APACHE_LOG_DIR}/www.example.com.access.log combined
</VirtualHost>

既有網站若使用 ProxyPass、PHP-FPM、mod_wsgi 或其他 Application handler，保留原本設定，不要為了套用 certificate 改回 /var/www/html。若已定義 cloudflare_realip，可以將 CustomLog 最後的 combined 改成 cloudflare_realip。

啟用 site，檢查並套用：

sudo a2ensite www.example.com.conf
sudo apache2ctl configtest
sudo apache2ctl -S
sudo systemctl reload apache2
sudo ss --listening --numeric --tcp --process | grep ':443'

configtest 必須顯示 Syntax OK；apache2ctl -S 必須確認 www.example.com 的 *:443 指向剛才修改的 VirtualHost。

Apache2 設定結果：

HTTP 轉址方式

Full (strict) 負責 Cloudflare 與 Origin 的 HTTPS certificate validation，不會自行將訪客的 HTTP request 轉成 HTTPS。Cloudflare 建議在 Edge 啟用 Always Use HTTPS，讓 redirect 在 request 抵達 Origin 前完成：Cloudflare：Always Use HTTPS

設定位置：

SSL/TLS
└── Edge Certificates
    └── Always Use HTTPS：On

採用 Edge redirect 後，Origin 主線只需要開放 443。若因特定路徑或既有架構必須由 Origin redirect，GCP Firewall 也要允許 Cloudflare CIDR 連入 80，並在 Web Server 增加以下設定。

Nginx：

server {
    listen 80;
    server_name www.example.com;

    return 301 https://$host$request_uri;
}

Apache2：

<VirtualHost *:80>
    ServerName www.example.com

    Redirect permanent / https://www.example.com/
</VirtualHost>

同一個 HTTP request 不需要在 Cloudflare、Web Server 與 Application 建立三層 redirect。選定一個主要控制點，並確認 redirect 只發生一次。

Origin TLS 驗證與 Full (strict) 設定

先在 Origin VM 驗證 certificate，再切換 Cloudflare mode。這個順序可以把 Web Server 問題與 Cloudflare-to-Origin 問題分開處理。

curl 驗證

在 VM 執行：

curl --noproxy '*' \
  --verbose \
  --resolve 'www.example.com:443:127.0.0.1' \
  --cacert /etc/ssl/cloudflare/cloudflare-origin-ca-rsa.pem \
  'https://www.example.com/'

這個指令同時指定四項資料：

--resolve 只改寫這次 curl 的連線目的地，不會修改 DNS 或 /etc/hosts。--cacert 則明確信任 Cloudflare Origin CA root。成功結果應包含 certificate verify ok，並取得預期 HTTP response。

不要使用 --insecure 或 -k 作為驗收結果。它們會略過 CA chain 與 hostname validation，剛好避開 Full (strict) 要檢查的重點。

來源限制若設在 Nginx 或 Apache2，而且規則不允許 loopback，curl 可能在 TLS 驗證成功後收到 HTTP 403。這不代表 certificate 驗證失敗，也不應為了本機測試把 127.0.0.1 永久加入 Cloudflare allowlist；Application response 應再經由外部 Cloudflare 路徑驗證。

若 Web Server 只綁定 VM 的內部 IP，將 127.0.0.1 換成該 listener address；URL hostname、SNI 與 HTTP Host 仍保留 www.example.com。

OpenSSL 驗證

openssl s_client \
  -connect 127.0.0.1:443 \
  -servername www.example.com \
  -verify_hostname www.example.com \
  -verify_return_error \
  -CAfile /etc/ssl/cloudflare/cloudflare-origin-ca-rsa.pem \
  </dev/null

預期最後出現：

Verify return code: 0 (ok)

若這裡顯示 hostname mismatch、unable to get local issuer certificate 或 certificate has expired，先處理 certificate 與 VirtualHost，不要直接切換 Full (strict)。

Cloudflare Full (strict)

Origin 本機驗證通過後，進入 Cloudflare Dashboard：

1. 選擇目標 zone。
2. 進入 SSL/TLS → Overview。
3. 將 SSL/TLS encryption mode 設為 Full (strict)。

Full (strict) 要求 Origin Certificate 尚未過期、由 public CA 或 Cloudflare Origin CA 簽發，且 CN／SAN 能匹配 request hostname。Cloudflare：Full (strict)

如果同一個 zone 有多個 Origin，而其中只有 www.example.com 完成 certificate 設定，不應直接讓尚未準備好的 hostname 一起套用。可以在 Rules → Configuration Rules 依 hostname 設定 SSL mode，待其他 Origin 完成後再統一。Cloudflare：Configuration Rules

End-to-End 驗證

從一般外部網路建立唯一測試 ID，呼叫明確不經 cache 的 endpoint：

FULL_STRICT_TEST_ID="full-strict-$(date -u +%Y%m%dT%H%M%SZ)-${RANDOM}"

curl --noproxy '*' \
  --silent \
  --show-error \
  --dump-header - \
  --output /dev/null \
  "https://www.example.com/healthz?full_strict_test=${FULL_STRICT_TEST_ID}"

printf 'Origin Access Log 應出現：%s\n' "$FULL_STRICT_TEST_ID"

在 Origin VM 檢查同一筆 request：

# Nginx
sudo grep --fixed-strings 'full-strict-REPLACE_WITH_ACTUAL_ID' \
  /var/log/nginx/www.example.com.access.log

# Apache2
sudo grep --fixed-strings 'full-strict-REPLACE_WITH_ACTUAL_ID' \
  /var/log/apache2/www.example.com.access.log

驗收條件：

• 外部 HTTPS request 成功，response 可看到 Cloudflare 的 CF-Ray。
• Origin Access Log 找得到相同測試 ID，證明不是只取得 Edge cache。
• Access Log 已保留 connection peer 時，該 IP 位於 Cloudflare CIDR，並能與 Visitor IP 分開判讀。
• Cloudflare Dashboard 顯示 Full (strict)。
• GCP Firewall 仍只允許 Cloudflare CIDR 連入 443。

從外部執行一般 curl https://www.example.com/，只會驗證 Browser-to-Cloudflare 的 Edge Certificate。必須結合 Origin 本機的 curl --cacert、OpenSSL 與 Origin Access Log，才能分別確認兩段 TLS 與實際回源。

525、526 與連線問題

Cloudflare 的 52x 錯誤應依網路、TLS handshake、certificate validation、HTTP 與 Application 的順序排查，不要看到 HTTPS 錯誤就先更換 certificate。

525 代表 TLS handshake 本身沒有完成；526 則表示 Cloudflare 已取得 certificate，但無法按 Full (strict) 的條件驗證。兩者的處理方向不同。Cloudflare：Error 525／Cloudflare：Error 526

VM 檢查指令

sudo ss --listening --numeric --tcp --process | grep ':443'

# Nginx
sudo nginx -t
sudo journalctl --unit=nginx --lines=100 --no-pager
sudo tail --lines=100 /var/log/nginx/www.example.com.error.log

# Apache2
sudo apache2ctl configtest
sudo apache2ctl -S
sudo journalctl --unit=apache2 --lines=100 --no-pager
sudo tail --lines=100 /var/log/apache2/www.example.com.error.log

再重跑 Origin 本機測試：

curl --noproxy '*' \
  --verbose \
  --resolve 'www.example.com:443:127.0.0.1' \
  --cacert /etc/ssl/cloudflare/cloudflare-origin-ca-rsa.pem \
  'https://www.example.com/'

常見結果：

• Connection refused：443 沒有 listener，或 service 沒有啟動。
• Connection timeout：address、routing 或 Firewall 不通。
• no alternative certificate subject name matches：SAN 不包含 request hostname。
• unable to get local issuer certificate：CA file 錯誤或 chain 不完整。
• certificate has expired：Origin Certificate 已過期。
• HTTP 403：TLS 已成功，問題位於來源限制或 Application authorization，不是 certificate。

Cloudflare 對 Origin 的 DNS target、Firewall、certificate 與 Web Server log 應使用同一個時間點交叉檢查。只看 browser 的 Cloudflare error page，通常不足以定位是哪一層失敗。

Full (strict) 的驗證範圍

Full (strict) 的驗證對象是 Cloudflare-to-Origin TLS connection，需要和 Browser-to-Cloudflare TLS、來源限制及 Trusted Proxy 分開判讀。

兩段 TLS

Browser
  │
  │ TLS #1
  │ Client：Browser
  │ Server：Cloudflare Edge
  │ Certificate：Edge Certificate
  ▼
Cloudflare
  │
  │ TLS #2
  │ Client：Cloudflare
  │ Server：Origin VM
  │ Certificate：Origin Certificate
  ▼
Nginx／Apache2

兩條 TLS connection 各自 handshake、各自選擇 protocol 與 cipher，也各自驗證 server identity。瀏覽器看到有效鎖頭，只代表第一段 certificate 驗證成功，不能據此判斷第二段是不是 Full、Full (strict) 或甚至 Flexible。

Flexible、Full 與 Full (strict)

Full (strict) 是 Full mode 加上 Origin Certificate validation，並不等於自動強制所有訪客改用 HTTPS。若要讓 HTTP request 在 Cloudflare Edge 直接轉為 HTTPS，仍要另外啟用 Always Use HTTPS。Cloudflare 的 Encryption modes 將兩條 connection 與各 mode 的行為分開定義。

Enterprise zone 另有 Strict (SSL-Only Origin Pull)，可以不論訪客 scheme 都以 HTTPS 連往 Origin；它和本文的 Full (strict) 不是同一個 mode。

Origin CA 與 Public CA

Origin CA 不受一般 Browser 信任是信任範圍的設計，不是 certificate 損壞。若把 record 改成 DNS only、Pause Cloudflare，或直接讓 Browser 連入 Origin，Browser 可能顯示 NET::ERR_CERT_AUTHORITY_INVALID。

Full (strict) 不是來源限制

一般 Full (strict) 使用的是標準 server-authenticated TLS：Cloudflare 驗證 Origin，Origin 不會因為這個 mode 要求連入 client 證明自己是 Cloudflare。

Full (strict)
Cloudflare ──驗證──▶ Origin Certificate

不是：
Origin ──驗證──▶ Cloudflare Client Identity

因此 Full (strict) 不能取代：

• GCP Firewall 或 Web Server Cloudflare source allowlist。
• Nginx／Apache2 Trusted Proxy List。
• Application authentication 與 authorization。
• 需要 client certificate 時使用的 Authenticated Origin Pulls。

若需要在 TLS 層確認 client 是 Cloudflare，Authenticated Origin Pulls 會使用 mTLS，要求 Cloudflare 在連入 Origin 時提供 client certificate。即使 Full (strict) 已啟用，AOP 仍是另一個獨立控制。Cloudflare：Authenticated Origin Pulls

四項控制的責任如下：

憑證效期與驗收清單

Cloudflare 目前不會主動寄送 Origin CA Certificate 到期通知；使用長效 certificate 也必須建立自己的 inventory 與監控。Cloudflare：Origin CA certificate expiration

用 OpenSSL 檢查 certificate 是否會在 30 日內到期：

sudo openssl x509 \
  -checkend 2592000 \
  -noout \
  -in /etc/ssl/cloudflare/www.example.com.pem

2592000 是 30 日的秒數。Exit code 0 表示 30 日後仍有效；exit code 1 表示將在 30 日內到期或已過期。應將這項檢查接到現有監控系統，而不是只靠人工登入 VM 查看。

Certificate inventory 至少記錄：

• Hostname 與 SAN。
• Issuer。
• Certificate serial number。
• 生效時間與到期時間。
• Private key owner 與儲存位置。
• 負責更新的人員或系統。
• 預定更新日期與監控門檻。

更新 certificate 時，先在 Cloudflare 建立新 certificate，安裝並通過 openssl verify、Web Server config test、Origin 本機 curl 與外部回源驗證，再撤銷不再使用的舊 certificate。Private Key 外洩時則應簽發新 certificate、更新服務並撤銷舊 certificate。

最終驗收：

•  www.example.com 的 DNS record 是 Proxied。
•  Edge Certificate 是 Active，外部 HTTPS 驗證成功。
•  Origin Certificate 尚未過期，SAN 包含正確 hostname。
•  Certificate 與 Private Key 的 public key SHA-256 相同。
•  Nginx nginx -t 或 Apache2 configtest 成功。
•  Origin 443 正在監聽。
•  VM 本機 curl --resolve --cacert 成功，沒有使用 -k。
•  openssl s_client 顯示 Verify return code: 0 (ok)。
•  Cloudflare SSL/TLS mode 是 Full (strict)。
•  外部測試 request 能在 Origin Access Log 找到相同 ID。
•  Always Use HTTPS 已依需求啟用，HTTP redirect 沒有 loop。
•  GCP Firewall 或 Web Server 仍限制只有 Cloudflare 可以連入 Origin。
•  Origin Certificate 已納入期限監控。

系列文章

參考資料

• Cloudflare：Proxy status
• Cloudflare：Origin CA
• Cloudflare：SSL/TLS encryption modes
• Cloudflare：Full (strict)
• Cloudflare：Always Use HTTPS
• Cloudflare：Error 521
• Cloudflare：Error 522
• Cloudflare：Error 525
• Cloudflare：Error 526
• Cloudflare：Authenticated Origin Pulls
• NGINX：Configuring HTTPS servers
• Apache HTTP Server：SSL/TLS Strong Encryption How-To