指南

作者： Matt Connor 2026-08-16

nginx mTLS：用戶端憑證設定與拒絕未授權連線

Q: 為什麼瀏覽器從未要求我選擇憑證？

nginx 會在握手期間傳送可接受簽發者的清單，該清單由 ssl_client_certificate 中的檔案建立。瀏覽器只會提供簽發者出現在該清單中的憑證。因此，未出現提示表示瀏覽器沒有您的 CA 所簽發的憑證：憑證可能匯入了其他瀏覽器設定檔，或是由不同於伺服器所安裝 CA 的 CA 簽發。執行 openssl s_client -connect admin.example.com:443，查看輸出中的可接受用戶端憑證 CA 名稱，即可確認伺服器實際要求哪個 CA。

Q: 可以只在一個 URL 上要求用戶端憑證嗎？

不能在 location 中使用 ssl_verify_client on。憑證會在 nginx 知道請求路徑之前，於握手期間交換；而可用來繞過此限制的重新協商機制已從 TLS 1.3 移除，且在 HTTP/2 中被禁止。請在 server block 中設定 ssl_verify_client optional;，然後在每個受保護的 location 中檢查 $ssl_client_verify；若其不是 SUCCESS，則回傳 403。

Q: 如何撤銷某一人的存取權？

使用 openssl ca -revoke 撤銷該憑證，以 openssl ca -gencrl 重新產生清單，將清單複製到伺服器，然後重新載入 nginx，讓它讀取新檔案。其他人不會受到影響；但這只有在每個人持有自己的憑證，而不是共用憑證時才成立。請注意 CRL 的 nextUpdate 日期，因為 CRL 過期後，所有用戶端的驗證都會失敗，而不只是已撤銷憑證的用戶端。

使用 openssl 建立私有 CA、簽發用戶端憑證，並在 nginx 加入 3 個指示詞，讓沒有有效憑證的請求在 TLS 交握時直接遭拒。

mTLS 的作用

雙向 TLS（通常寫作 mTLS）會讓 nginx 要求每個用戶端提供憑證。如果憑證缺少，或不是由您管理的憑證授權單位（CA）核發，nginx 就會拒絕請求。這項檢查會在 TLS（傳輸層安全性）交握期間進行，因此沒有有效用戶端憑證的呼叫端，根本無法抵達應用程式。這就是 mTLS 的優點：管理介面或 metrics endpoint 可以直接放在公用網際網路上，不需要登入頁面，也沒有可供機器人猜測的內容。

建置所需的元件不多。使用 openssl 建立 1 個私有 CA、為每個人建立 1 張憑證，再在 nginx server block 中加入 3 個指示詞。能否維持運作 1 年，關鍵在於作業管理。因此，本指南大多說明憑證有效期限、撤銷、每人 1 張憑證，以及用戶端遭拒而無人能判斷原因時的處理方式。

兩條憑證鏈，而不是一條

mTLS 設定中有兩條憑證鏈，彼此完全無關。把兩者混在一起，是幾乎所有人都會犯的第一個錯誤。

第一條是伺服器的憑證鏈。您的 VPS 會提供一張由 Let’s Encrypt 等公開 CA 核發、適用於 admin.example.com 的憑證，而瀏覽器會使用作業系統隨附的根憑證存放區進行驗證。mTLS 不會改變這一部分。如果 certbot 今天替您核發這張憑證，請完全維持原狀：請參閱使用 certbot 為 nginx 核發 Let’s Encrypt 憑證。

第二條是用戶端的憑證鏈。您自行建立一個小型 CA，為每位需要存取的人員各簽署一張憑證，並告訴 nginx 在驗證用戶端時只信任該 CA。公開根憑證存放區不會知道您的 CA，也不需要知道。唯一必須信任它的元件是 nginx，透過 ssl_client_certificate 檔案完成。

因此，ssl_client_certificate 不會影響 nginx 提供的憑證，而 Let’s Encrypt 憑證鏈也不會影響哪些用戶端可以存取。將 ssl_client_certificate 指向 fullchain.pem，並不會產生表面上看似的效果：該指示詞指定的是用戶端憑證可以由哪些核發者簽署，也就是連線的另一端。讓伺服器本身在對外連線時信任您的 CA，是另一項工作，請參閱將您自己的 CA 加入 Ubuntu 信任存放區；nginx 驗證用戶端時讀取的不是系統信任存放區。

使用 openssl 建立自己的用戶端 CA

請在 Web 伺服器以外的位置建立 CA。nginx 只需要 CA 的公開憑證。CA 私密金鑰會用來簽署新的用戶端憑證，因此若將它留在面向網際網路的主機上，一旦主機遭到入侵，攻擊者就能隨意簽發有效的用戶端憑證給自己使用。

mkdir -p ~/client-ca/certs ~/client-ca/newcerts ~/client-ca/private ~/client-ca/csr
cd ~/client-ca
chmod 700 private
touch index.txt
echo 1000 > serial
echo 1000 > crlnumber

index.txt、serial 和 crlnumber 是 CA 資料庫。openssl ca 若缺少這些檔案就無法執行。這些檔案也讓日後可以撤銷憑證，因為撤銷清單會列出序號，CA 必須記錄每個序號簽發給誰。

建立 ~/client-ca/openssl.cnf。將 dir 設為該目錄的實際路徑，因為 openssl ca 不會展開 ~。

[ ca ]
default_ca = client_ca

[ client_ca ]
dir               = /home/you/client-ca
database          = $dir/index.txt
new_certs_dir     = $dir/newcerts
certificate       = $dir/ca.crt
private_key       = $dir/private/ca.key
serial            = $dir/serial
crlnumber         = $dir/crlnumber
default_md        = sha256
default_days      = 365
default_crl_days  = 30
policy            = policy_loose
rand_serial       = no
unique_subject    = no
email_in_dn       = no

[ policy_loose ]
commonName              = supplied
countryName             = optional
stateOrProvinceName     = optional
organizationName        = optional
organizationalUnitName  = optional
emailAddress            = optional

[ client_ext ]
basicConstraints        = CA:FALSE
keyUsage                = critical, digitalSignature, keyEncipherment
extendedKeyUsage        = clientAuth
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid,issuer

接著建立 CA 金鑰及其自簽憑證：

openssl genrsa -aes256 -out private/ca.key 4096
chmod 600 private/ca.key
openssl req -x509 -new -key private/ca.key -sha256 -days 3650 \
  -subj "/O=Example Ops/CN=Example Ops Client CA" \
  -addext "basicConstraints=critical,CA:TRUE,pathlen:0" \
  -addext "keyUsage=critical,keyCertSign,cRLSign" \
  -out ca.crt

-aes256 會為 CA 金鑰設定 passphrase，因此每次執行簽署時都會要求輸入。這正是設定它的目的。檢查建立的內容：

openssl x509 -in ca.crt -noout -subject -dates -ext basicConstraints

主體應該是你的 CA，有效期限應為 10 年。extension 行應顯示 CA:TRUE, pathlen:0。pathlen:0 表示此 CA 可以簽署終端憑證，但不能簽署其他 CA。如此可讓憑證鏈維持恰好一層，並讓你不必修改 ssl_verify_depth。

每人簽發一張用戶端憑證

每人一張憑證。絕對不要讓團隊共用一張憑證，因為共用憑證無法撤銷而不影響所有人存取，也無法判斷是誰發出的請求。

openssl genrsa -out private/alice.key 2048
openssl req -new -key private/alice.key -out csr/alice.csr \
  -subj "/O=Example Ops/CN=alice"
openssl ca -config openssl.cnf -extensions client_ext \
  -days 365 -notext -in csr/alice.csr -out certs/alice.crt

openssl ca 會列印即將簽署的憑證，要求輸入 CA 密碼，要求確認兩次，然後將一行內容附加至 index.txt。建立腳本時，請加入 -batch。client_ext 區段很重要，因為其中有一行：extendedKeyUsage = clientAuth。如果憑證的 extended key usage 只列出 serverAuth，就會被拒絕，因為不適用於用戶端驗證。因此請明確指定用途，不要依賴預設行為。

交付前，先對照 CA 驗證這組憑證與金鑰：

openssl verify -CAfile ca.crt certs/alice.crt

這會輸出 certs/alice.crt: OK。任何其他輸出都表示憑證與 CA 不相符，任何 nginx 設定都無法補救。

將金鑰與憑證打包成瀏覽器可匯入的單一檔案：

openssl pkcs12 -export -inkey private/alice.key -in certs/alice.crt \
  -name "alice at example ops" -out alice.p12

匯出時會要求設定密碼，用來保護傳輸中的檔案。請透過不同管道傳送檔案與密碼，並提供 .p12，不要只提供裸露的 .key。你可以加入 -certfile ca.crt，將 CA 一併放入套件，但 nginx 不需要這麼做：nginx 已經持有 ca.crt，因此由該 CA 直接簽署的憑證可自行完成驗證。

Ubuntu 24.04 隨附的 OpenSSL 3 會使用目前的加密方式寫入 PKCS#12 檔案；截至 August 2026，常用的瀏覽器與作業系統都能讀取這些檔案。如果舊版匯入工具拒絕該檔案，請加入 -legacy 重新匯出，這會退回該匯入工具所需的舊版演算法。使用該旗標前，先閱讀匯入工具提供的訊息。

使用 ssl_client_certificate 和 ssl_verify_client 設定 nginx

將 CA 憑證，而且只能是 CA 憑證，複製到伺服器。

scp ca.crt user@admin.example.com:/tmp/client-ca.crt
ssh user@admin.example.com \
  'sudo install -o root -g root -m 644 /tmp/client-ca.crt /etc/nginx/client-ca.crt'

此處使用 Mode 644 正確。CA 憑證屬於公開資訊。CA 金鑰應留在工作站上。

接著，在已處理 TLS termination 的 server block 中加入 3 個指令：

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

    ssl_certificate     /etc/letsencrypt/live/admin.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/admin.example.com/privkey.pem;

    ssl_client_certificate /etc/nginx/client-ca.crt;
    ssl_verify_client      on;
    ssl_verify_depth       1;

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

ssl_verify_depth 1 是 nginx 的預設值，表示用戶端憑證必須直接由該檔案中的 CA 簽署。只有在加入 intermediate 時，才需要提高此值。nginx 也會在 handshake 期間將 ssl_client_certificate 中的 subject name 傳送給用戶端，瀏覽器才能知道應提供哪些憑證。這也是應使用 ssl_client_certificate 而非 ssl_trusted_certificate 的原因；兩者的驗證方式相同，但後者不會傳送清單。

Ubuntu 24.04 隨附 nginx 1.24，因此 HTTP/2 會以 listen 443 ssl http2; 的形式放在 listen 行上。在 nginx 1.25.1 及更新版本中，此寫法已 deprecated，HTTP/2 會改用獨立指令 http2 on;。兩種寫法都不會改變憑證檢查。

重新載入並查看結果：

sudo nginx -t && sudo systemctl reload nginx
curl -i https://admin.example.com/

nginx -t 會輸出 syntax is ok 和 test is successful。curl 呼叫未攜帶憑證，因此應回傳 400 Bad Request，內容為 No required SSL certificate was sent。這表示 nginx 在自身的閘門拒絕了請求，也表示設定已生效，應用程式根本未收到請求。現在以正確方式測試：

curl --cert certs/alice.crt --key private/alice.key https://admin.example.com/

此時應回傳應用程式提供的內容。

為何閘門應放在 server block

憑證會在 TLS handshake 期間交換，早於 nginx 讀取請求列。因此，此時 nginx 不知道請求將進入哪個 location。將 ssl_verify_client on; 放在 location 內，會要求用戶端在連線中途重新協商。TLS 1.3 已移除重新協商功能，而 HTTP/2 也禁止此功能，因此在目前的堆疊中，這種寫法會直接失敗，不會顯示提示。

請自行處理範圍。先在 server 層級要求憑證，再針對各個 location 做決定：

ssl_verify_client optional;

location /metrics {
    if ($ssl_client_verify != SUCCESS) { return 403; }
    proxy_pass http://127.0.0.1:9090;
}

location /healthz {
    proxy_pass http://127.0.0.1:8080;
}

$ssl_client_verify 會包含 SUCCESS；若用戶端未傳送憑證，則包含 NONE；若發生錯誤，則包含 FAILED: 及原因。使用 optional 時，nginx 會要求憑證，只有在收到憑證時才驗證。這讓上方公開的 /healthz 路徑可以運作，同時讓 /metrics 維持關閉。用戶端若傳送了憑證但驗證失敗，nginx 仍會在此處拒絕該請求。若要自行檢查驗證失敗的憑證，則應使用 optional_no_ca；此時，自行撰寫的測試必須將所有不是 SUCCESS 的值視為拒絕。

nginx 為此使用非標準狀態碼，error_page 可以攔截這些狀態碼，讓遭拒的訪客取得說明，而不是只收到空白的 400：

error_page 495 496 = @needcert;

location @needcert {
    default_type text/plain;
    return 200 "This host requires a client certificate. Ask ops for one.\n";
}

495 表示用戶端憑證驗證失敗。496 表示用戶端未提供憑證。請將該頁面維持為純文字，因為閱讀此頁面的人沒有 session，也沒有帳戶。

如何在瀏覽器中安裝用戶端憑證？

Firefox 使用自己的憑證存放區：依序開啟 Settings、Privacy and Security、View Certificates、Your Certificates 分頁及 Import，然後選取 .p12 並輸入其密碼。

Chrome 和 Edge 在 Windows 與 macOS 上使用作業系統的憑證存放區，因此開啟 .p12 檔案後，會啟動系統匯入精靈。在 Linux 上，Chrome 會讀取家目錄中的個別 NSS（network security services）資料庫。使用命令列工具是可靠的作法：

sudo apt install -y libnss3-tools
pk12util -d sql:$HOME/.pki/nssdb -i alice.p12

之後載入網站，瀏覽器會詢問要傳送哪張憑證。Chrome 會在本次瀏覽器工作階段中記住這項選擇。若要再次顯示詢問畫面，請重新啟動瀏覽器。憑證只存在於單一機器上的單一瀏覽器設定檔中。因此，匯入 Firefox 的憑證在 Chrome 中不可見，兩者也都無法在手機上使用。

使用 curl --cert 進行測試

使用 curl 進行除錯，因為它會回報實際執行的內容。

curl -v --cert certs/alice.crt --key private/alice.key https://admin.example.com/

您可以將憑證與金鑰串接成單一 PEM 檔案，並將其作為 --cert alice.pem 傳入。如果金鑰有密碼，curl 會提示您輸入。curl 也接受 --cert alice.pem:passphrase，但密碼會留在 shell 歷程記錄中，因此請使用提示輸入的方式。

在判定問題出在 nginx 之前，建議先執行以下兩項檢查。首先，憑證與金鑰必須是配對的：

openssl x509 -noout -pubkey -in certs/alice.crt | openssl sha256
openssl pkey -pubout -in private/alice.key | openssl sha256

兩個相同的雜湊值表示檔案彼此相符。兩個不同的雜湊值表示您混用了不同使用者的檔案，任何用戶端都不會替您指出這項原因。

其次，伺服器應要求您的 CA：

openssl s_client -connect admin.example.com:443 -servername admin.example.com </dev/null

請在輸出中尋找 Acceptable client certificate CA names 區塊，以及其中是否包含您 CA 的 subject。如果完全沒有這個區塊，表示 nginx 並未在回應請求的 server block 上要求憑證，因此您的指令套用到了其他 server block，通常是 default server。

將用戶端 CN 傳給應用程式

憑證會指出呼叫者身分，但反向代理後方的應用程式看不到 TLS 層，因此 nginx 必須將名稱傳遞過去。

map $ssl_client_s_dn $client_cn {
    default              "";
    "~,?CN=(?<cn>[^,]+)" $cn;
}

$ssl_client_s_dn 會以 RFC 2253 格式保存主體辨識名稱，其格式類似 CN=alice,O=Example Ops。此 map 會將 CN 欄位取出並放入 $client_cn。CN 應維持為單純的使用者名稱，因為該格式會跳脫 CN 內的逗號，而上方的簡單正規表示式無法處理這種跳脫。

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host                 $host;
    proxy_set_header X-Forwarded-For      $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto    $scheme;
    proxy_set_header X-Client-Cert-CN     $client_cn;
    proxy_set_header X-Client-Cert-Serial $ssl_client_serial;
}

proxy_set_header 會取代呼叫者自行傳送的同名標頭，因此無法透過此 location 偽造 X-Client-Cert-CN。要維持這項保護，必須符合兩個條件。只有在內層層級未定義任何自身設定時，nginx 才會從外層繼承 proxy_set_header；因此，若另一個 location 含有一行 proxy_set_header，就會無聲無息地遺失上層設定的所有標頭，包括這一個。其次，應用程式不得透過 nginx 以外的方式連線，這表示應將它繫結至 127.0.0.1，而不是 0.0.0.0；如果應用程式監聽公開埠，便會直接讀取來自網際網路的偽造標頭。代理端的設定詳見逐行說明的 nginx 反向代理設定。如果應用程式需要完整憑證，而不只是名稱，$ssl_client_escaped_cert 會以 URL 編碼形式傳遞，並可安全地放在標頭中。

如何撤銷單一用戶端憑證？

有人離職，或筆電遺失時，只要撤銷該憑證，其他人仍可繼續使用。這正是每人簽發一張憑證的原因。

cd ~/client-ca
openssl ca -config openssl.cnf -revoke certs/alice.crt
openssl ca -config openssl.cnf -gencrl -out crl.pem

第一個命令會將 index.txt 中該序號的狀態，從 V 改為 R。第二個命令會寫出憑證撤銷清單（CRL），這是一個經簽署的檔案，其中列出已撤銷的序號。將該檔案部署到伺服器，並在其他指示詞旁使用 ssl_crl /etc/nginx/client-ca.crl; 指向它。

scp crl.pem user@admin.example.com:/tmp/client-ca.crl
ssh user@admin.example.com 'sudo install -m 644 /tmp/client-ca.crl /etc/nginx/client-ca.crl && sudo nginx -t && sudo systemctl reload nginx'

以下是會讓所有人都無法通過驗證的陷阱。CRL 會包含由 default_crl_days 設定的 nextUpdate 日期；上述設定中的值為 30。日期一旦到期，OpenSSL 就會將清單視為過期，並以 CRL has expired 使所有用戶端憑證的驗證失敗，而不只是撤銷的憑證。nginx 會在載入設定時讀取該檔案，因此磁碟上的新 CRL 不會生效，直到重新載入設定為止。請在期限內預留充足時間，依排程重新產生 CRL 並重新載入設定；例如每週執行一次，而有效期限為 30 天。複製檔案前，請先檢查日期：

openssl crl -in crl.pem -noout -lastupdate -nextupdate

如果只有少數使用者，還有更簡單的選項。CA 由你管理，因此 nginx 可以直接拒絕指定序號，略過 CRL 機制：

map $ssl_client_serial $revoked {
    default 0;
    "1002"  1;
}

在 location 中搭配 if ($revoked) { return 403; } 使用。這種方式沒有需要記得的到期日，也不會隨憑證清單傳遞，因此任何其他信任你 CA 的系統都不會知道這項設定。若只有一個 nginx 位於單一應用程式前方，這是簡單且直接的做法。當入口不只一個時，再改用 CRL。

用戶端憑證應該有效多久？

用戶端憑證的有效期設為 1 年；如果能承受重新簽發的工作量，也可以縮短。到期是這裡最不易察覺的故障，因為系統不會事先通知持有人。某天早上，對方開啟管理面板時，nginx 拒絕連線，而瀏覽器會用自己的措辭說明拒絕原因，通常不會明確寫出已到期。CA 的有效期可設為 10 年，並將到期日記在你確實會查看的位置。CA 憑證一旦到期，其簽發的所有憑證都會在同一天停止驗證。

以下兩個命令可協助你及早掌握狀況：

openssl x509 -in certs/alice.crt -noout -subject -serial -enddate
awk -F'\t' '{print $1, $2, $4}' ~/client-ca/index.txt

index.txt 的第一欄是狀態：V 代表有效、R 代表已撤銷、E 代表已到期。第二欄是 YYMMDDHHMMSSZ 格式的到期時間，第四欄是序號。這個檔案是唯一記錄憑證持有者與憑證對應關係的資料，因此應與 CA key 一起備份，並將兩者視為 secret。

續期代表簽發新憑證，不是延長原憑證的有效期。請產生新的 key 與 CSR（certificate signing request），完成簽署後交付給持有人；待對方確認新憑證可正常使用，再撤銷舊憑證。

mTLS 能防範什麼，以及不能防範什麼

它移除的是未經驗證的存取。掃描器找到您的主機名稱後，會在 handshake 階段遭到拒絕，因此不會送出 HTTP request、不會看到登入表單，也無法拿遭竊的密碼嘗試登入。Credential stuffing 無從進行。沒有憑證的使用者無法觸及應用程式登入流程中的漏洞。它也能移除人們貼在聊天室中的共用 secret，因為 private key 是不容易意外複製的檔案。

它完全無法處理遭入侵的 client。筆記型電腦上的 malware 會取得 key 檔案，而使用者輸入 passphrase 的當下，malware 也會取得 passphrase。對伺服器而言，該攻擊者看起來與合法使用者完全相同，因為憑證只能證明持有檔案，不能證明使用者本人在場。.p12 password 與 full disk encryption 仍然很重要。

它也不是 authorization。除非檢查 $client_cn 並根據其值採取措施，否則每張有效憑證都能存取該 server block 提供的所有內容。依預設，兩名憑證持有者具有完全相同的存取權限。

此外，它只保護通往 nginx 的路徑。如果應用程式也監聽公開埠，前方的 mTLS 就只是裝飾：將應用程式綁定至 127.0.0.1，並在其埠上維持防火牆封鎖。同一台主機的另一個入口是 SSH，也需要同樣重視；請參閱強化 VPS 的 SSH 存取安全。

最後還有一項限制，而且會在啟用它的當天造成影響。任何無法提供憑證的元件都會停止運作，例如 uptime monitor、付款服務提供者送出的 webhook、RSS reader，或沒有可供您存取之 certificate store 的 mobile app。設定 ssl_verify_client on 前，先決定如何處理這些元件，因為失敗會是全面性的，而且對方通常不會提供任何訊息。

用戶端遭拒時，請閱讀用戶端回報的內容

遭拒用戶端顯示的訊息取決於瀏覽器、curl 版本及底層 TLS 程式庫。因此，請直接查看您自己的用戶端輸出，不要拿它與其他地方記錄的訊息比對。實用的詳細資訊在伺服器上。

sudo tail -n 50 /var/log/nginx/error.log

遭拒的憑證會產生一行包含 client SSL certificate verify error 的訊息，後面接著 OpenSSL 提供的原因。這個原因就是需要處理的依據。通常只有幾種可能。憑證的 CA 與 ssl_client_certificate 所指定檔案中的 CA 不同。憑證已超出有效日期。伺服器上的 CRL 已超過其 nextUpdate，因此現在會拒絕所有用戶端，而不只是其中一個。

如果瀏覽器完全沒有提供憑證，問題發生在驗證之前。nginx 會在交握期間傳送可接受的簽發者名稱，而瀏覽器在其憑證存放區中找不到相符項目，因此沒有憑證可提供給您。請將 .p12 重新匯入您實際用來瀏覽的設定檔。

還有一種情況值得說明。如果您使用單獨的自簽憑證進行測試，而不是使用由您的 CA 簽署的憑證，驗證就不會成功，因為 nginx 會根據 CA 檔案檢查簽章，而自簽憑證不在該檔案中。建立憑證的方式與在 Ubuntu 上產生自簽憑證相同。mTLS 只需再加入由您的 CA 簽署憑證的步驟。

FAQ

如果使用 mTLS，是否仍需要 Let's Encrypt 憑證？

需要。這兩張憑證彼此無關。伺服器會提供自己的憑證，讓瀏覽器信任該主機名稱；這張憑證仍必須由瀏覽器已知的 CA 簽發。您的用戶端 CA 是另一條獨立的私有憑證鏈，僅用於確認連線者身分。設定 ssl_client_certificate 不會改變 nginx 提供的憑證，也不可將它指向您的 Let's Encrypt 憑證鏈。

為什麼瀏覽器從未要求我選擇憑證？

nginx 會在握手期間傳送可接受簽發者的清單，該清單由 ssl_client_certificate 中的檔案建立。瀏覽器只會提供簽發者出現在該清單中的憑證。因此，未出現提示表示瀏覽器沒有您的 CA 所簽發的憑證：憑證可能匯入了其他瀏覽器設定檔，或是由不同於伺服器所安裝 CA 的 CA 簽發。執行 openssl s_client -connect admin.example.com:443，查看輸出中的可接受用戶端憑證 CA 名稱，即可確認伺服器實際要求哪個 CA。

可以只在一個 URL 上要求用戶端憑證嗎？

不能在 location 中使用 ssl_verify_client on。憑證會在 nginx 知道請求路徑之前，於握手期間交換；而可用來繞過此限制的重新協商機制已從 TLS 1.3 移除，且在 HTTP/2 中被禁止。請在 server block 中設定 ssl_verify_client optional;，然後在每個受保護的 location 中檢查 $ssl_client_verify；若其不是 SUCCESS，則回傳 403。

如何撤銷某一人的存取權？

使用 openssl ca -revoke 撤銷該憑證，以 openssl ca -gencrl 重新產生清單，將清單複製到伺服器，然後重新載入 nginx，讓它讀取新檔案。其他人不會受到影響；但這只有在每個人持有自己的憑證，而不是共用憑證時才成立。請注意 CRL 的 nextUpdate 日期，因為 CRL 過期後，所有用戶端的驗證都會失敗，而不只是已撤銷憑證的用戶端。

mTLS 會取代登入頁面嗎？

就存取範圍而言，會：沒有憑證時，請求完全無法到達應用程式，因此沒有可供攻擊的表單，也沒有可供猜測的密碼。就應用程式內的身分識別而言，不會。憑證只能證明呼叫端持有金鑰檔案，因此遭竊的筆記型電腦仍可作為有效使用者。請將 CN 傳送給上游服務，保留應用程式現有的帳號與權限，並將憑證視為它們前方的存取閘門。

#tls#mtls#nginx #openssl#access-control