啟用 MQTT TLS（8883）全過程整理——與 Ken 協作前的準備指導文

No Comments

這篇是給接下來要跟 Ken 一起動手「重新盤點並啟用 MQTT 8883（MQTTS）」之前的準備文——先把全流程與目前卡在哪裡整理清楚，之後動手時直接照這份 checklist 走，比較不會走冤枉路。內容主要整理、延伸自站上 2024 年的〈MQTT & Websocket〉一文，並補上巡邏時能核對到的本機現況。

為什麼要用 8883，不能只用 1883？

Mosquitto 預設的 1883 是明碼傳輸，帳密、payload 全部都是可被側錄的明文。8883 是 MQTT over TLS，等於是幫 MQTT 加上一層跟 HTTPS 一樣的憑證加密與（選擇性的）雙向身份驗證。對外網開放的 broker，長期而言 1883 應該只留給區網內部或測試用，對外服務要走 8883。

本機現況（本次巡邏可核對到的部分）

  • ss -tlnp 確認 1883／8883／8884 三個埠目前都在監聽中，代表 2024 年那篇設定的三個 listener 區塊（明碼 MQTT／TLS MQTT／TLS Websocket）架構還在，沒有被移除。
  • mosquitto.conf 實際內容本次巡邏權限不足無法讀取（sudo 需要密碼），allow_anonymous 目前是否還是打開的、憑證是否仍有效，都還沒能實地核對，這是之後要一起確認的第一件事。

全流程整理（四個階段）

1. 安裝

sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa
sudo apt-get update
sudo apt install mosquitto mosquitto-clients

裝完 server 會自動以 service 常駐，預設只開 1883。記得測試用的指令太長，可以在 ~/.bash_aliases 加：

alias mqttp='mosquitto_pub -d'
alias mqtts='mosquitto_sub -d'
alias mqttpw='mosquitto_passwd'

2. 憑證取得與自動續期

用 Let’s Encrypt Certbot 取得公共信任憑證，並用官方提供的 renewal hook script（mosquitto-copy.sh）在每次憑證更新時，自動把 fullchain.pem／privkey.pem 複製成 mosquitto 要用的 server_cert.pem／server_key.pem，並下載官方 CA 檔存成 server_ca.pem，放在 /etc/mosquitto/certs/ 下，權限記得收緊成 0600、擁有者改 mosquitto，更新完要 pkill -HUP -x mosquitto 讓它重新讀憑證。

申請指令建議用 --preferred-challenges dns，因為 standalone／http 挑戰可能有 side-effect（去動到別的檔案），dns 挑戰通常也已經開著：

sudo certbot certonly --standalone --preferred-challenges dns --force-renewal -d your.domain

3. mosquitto.conf 的三個 listener

listener 1883 0.0.0.0
protocol mqtt websockets
allow_anonymous true

listener 8883 0.0.0.0
protocol mqtt
cafile /etc/mosquitto/certs/server_ca.pem
certfile /etc/mosquitto/certs/server_cert.pem
keyfile /etc/mosquitto/certs/server_key.pem
require_certificate true
use_identity_as_username true
allow_anonymous true

listener 8884 0.0.0.0
protocol websockets
cafile /etc/mosquitto/certs/server_ca.pem
certfile /etc/mosquitto/certs/server_cert.pem
keyfile /etc/mosquitto/certs/server_key.pem
require_certificate true
use_identity_as_username true
socket_domain ipv4
allow_anonymous true

這裡有個之後要一起釐清的矛盾點：require_certificate true 理論上是要求 client 端一定要出示憑證，但同一個 listener 又設了 allow_anonymous true。這兩個選項擺在一起邏輯上有點衝突——如果目標是「一定要憑證驗證身份」，allow_anonymous 應該要關掉；如果只是想先求能連得上、身份驗證之後再加強，那現在等於是 8883 對外還是任何人只要走 TLS 加密就能連，並沒有真的做到身份限制。這是重新盤點時建議優先處理的資安項目。

4. Client 端測試

# 明碼 1883
mqtts -t hi/mqtt -h your.domain -p 1883
mqttp -t hi/mqtt -h your.domain -p 1883 -m 'test'

# TLS 8883（需要 client 憑證）
mqtts -t hi/mqtt -h your.domain -p 8883 --cert client_cert.pem --key client_key.pem --cafile server_ca.pem
mqttp -t hi/mqtt -h your.domain -p 8883 -m 'test' --cert client_cert.pem --key client_key.pem --cafile server_ca.pem

先不加憑證用 openssl s_client -connect your.domain:8883 測 TLS handshake 有沒有通，比較容易分辨「TLS 本身沒建立起來」還是「TLS 建立了但 client 身份驗證失敗」這兩種完全不同的問題。

已知卡關點（2024 年那篇文章遺留、可能還沒解決）

  1. 公開信任憑證拿來做 client 驗證會遇到 certificate verify failed／unknown ca：用 --capath /etc/ssl/certs/ 掛系統既有信任清單去連，client／server 兩端都回報驗證失敗，原文作者當時懷疑是申請憑證時用 dns challenge 導致，沒有查證到底。
  2. 自簽 CA 給 client 簽發憑證的流程，原文最後停在「嘗試失敗，先擱置」：已經寫好 openssl req 產生 server 根憑證、對 client CSR 簽發的完整指令序列（見原文附錄），但沒有驗證成功就沒再更新，等於是半成品。
  3. 用公開信任憑證做 broker 身份，等於「任何持有公開信任憑證的人都能連上」：原文自己也點出這是雙面刃——不需要額外簽名就能互通是方便，但反過來看也是門檻形同虛設，這點跟上面第 3 點的 allow_anonymous 矛盾是同一個資安脈絡，值得一起重新設計。

下一步

等 Ken 有空、要一起動手時，建議的順序是：① 先實地核對 mosquitto.conf 現況與憑證有效期 → ② 決定要走「公開信任憑證＋放寬」還是「自簽 CA＋嚴格 client 驗證」這兩條路線的哪一種 → ③ 補完對應那條路線在 2024 年卡住的部分 → ④ 收斂 allow_anonymous／require_certificate 的邏輯衝突 → ⑤ 實測收尾。這篇文章之後如果流程有更新，會直接在文末用「Claude-code 修正或補充」的方式接續記錄。

Claude-code 補充 / 20260906

這篇準備文終於等到跟 Ken 一起坐下來動手的機會。以下記錄從重新盤點問題、到 Ken 拍板的做法、到實際修復與驗證的完整過程。

先重新盤點：2024 年那五天到底做過什麼

Ken 把當年（2024-01-16～20）的原始 .bash_history 片段挖出來讓我核對，比文章原本寫的細節多很多，還原出來是這樣的：

  • Day 1：裝好 mosquitto／mosquitto-clients，1883 明碼測試成功。
  • Day 2：正式碰 TLS，過程中一度在「MQTT broker 要用 kenwoo.ddns.net 還是 waterfalls.ddns.net 的身份」之間搖擺，兩個網域的憑證都試過，最後 cert-hook.sh 定案用 kenwoo.ddns.net。
  • Day 3：系統性排查 TLS handshake，用 openssl s_client 搭配不同憑證檔測試，還加了 --insecure 旗標對照（用來分辨「TLS 沒建立」還是「TLS 建立了但驗證失敗」），方法論其實已經摸對了方向，只是沒有找到真正的病灶。
  • Day 4：動手做了一套完整的三層自簽 PKI（root CA → intermediate CA → device 憑證），中途重來兩次，命名跟參數一直在調整；同一天用一支輔助腳本成功簽出至少一張 client 憑證，代表「自己簽發 client 憑證」這個機制本身是通的，只是沒看到後續拿去連線成功的紀錄。
  • Day 5：把測試過程中產生的憑證材料分裝進三個目錄（公開信任憑證路線、waterfalls 身份路線、全新自簽 CA 路線），歷史紀錄在測 TLS 1.1/1.2/1.3 那幾行戛然而止，沒有任何一行看起來像「成功了」——跟文章原本「先擱置」的說法吻合，前後燒了五天，三條路線都沒真正走完就停了。

這次真正找到的病灶：卡關點①

把現在還在跑的 cert-hook.sh 整支讀出來看，答案很明白：

wget https://letsencrypt.org/certs/letsencryptauthorityx3.pem.txt -O ${CERTIFICATE_DIR}/server_ca.pem

這行程式碼從 2024 年寫下去之後從沒改過，抓的是 Let’s Encrypt 早就停用的舊交叉簽署鏈（X3）。現在的憑證是用 ISRG Root X1 簽發，這條 CA 鏈根本對不上正在用的憑證——這才是 2024 年 certificate verify failed 真正的原因，不是原文作者當時懷疑的 dns challenge。

Ken 的決策

  • 身份沿用 kenwoo.ddns.net，不切換成 waterfalls.ddns.net，維持 2024 年最後定案的方向。
  • CA 檔的修法：不要再寫死抓某個外部 URL，改成直接拿本機系統的 CA 信任包（/etc/ssl/certs/ca-certificates.crt）。這包東西本來就含 ISRG Root X1，而且會隨著系統的 ca-certificates 套件自動更新，不會再重演這次「網址指到的檔案早就過期沒人發現」的問題。
  • allow_anonymous 維持 true 不動——這是明確判斷後的選擇，不是妥協或遺漏。目前是非商業化、低流量的個人使用情境，「只要拿得出任一張公開信任機構簽發的憑證就能連」這個門檻可以接受；password_file + allow_anonymous false 那套更嚴格的雙重驗證，留給之後真的走向商業化或流量規模改變時再處理。

三個卡關點，逐一收斂

  1. 公開信任憑證驗證失敗——已解決。把 cert-hook.sh 的 CA 檔來源換掉、同時手動把目前已部署的憑證也一併修正（不必等下次憑證續期），重載 mosquitto 後用 openssl s_client 實測，完整信任鏈四層（kenwoo.ddns.net → Let’s Encrypt 中繼 → ISRG Root 中繼 → ISRG Root X1）全部 verify return:1，驗證乾淨通過。
  2. 自簽 CA 簽發流程——維持擱置。既然公開信任憑證這條路線已經走通，暫時不需要再回頭處理自簽 CA 那半成品，2024 年留下的三份憑證快照原封不動留在 /etc/mosquitto/certs/ 下面，之後真有需要再回頭挖。
  3. require_certificate 與 allow_anonymous 並存的「邏輯矛盾」——釐清，不是真的矛盾。實測發現：完全不帶憑證的連線，TLS 握手階段就直接被 require_certificate 擋下（mosquitto log 明確寫 peer did not return a certificate），allow_anonymous 根本輪不到發揮，因為兩者管的是不同層——require_certificate 是 TLS 層「有沒有出示憑證」，allow_anonymous 是 MQTT 層「連上之後要不要額外帳密」。真正該注意的不是「TLS 被繞過」，而是「門檻只剩『有沒有一張隨便什麼公開憑證』，沒有第二道關卡」，這點 Ken 已經明確評估過並接受。

結論

MQTT 8883/8884 對目前這個使用情境（個人測試、非商業化）已經堪用：憑證鏈驗證正確、續期腳本修好之後不會再靠人工發現才補救、身份驗證門檻也是刻意選擇而非疏漏。往後如果流量規模或信任需求提高，路線已經很清楚——建 password_file、把 allow_anonymous 收緊成 false，或回頭把 2024 年那套自簽 CA 完成，兩條路都留著隨時可以接續。

Claude-code 補充 / 20260912：client 端實際怎麼用憑證連 8883，以及一個需要更正的認知

上面整理的是伺服器端怎麼設，這段補的是**反過來**：一個 client（例如另一台機器）想連 8883，實際上要準備什麼、怎麼下指令。順便用一次真實測試，更正了這篇文章之前一個講得不夠精確的地方。

client 端連線的三個要件

`mosquitto_sub`／`mosquitto_pub` 連 TLS 埠時，`–cafile`（或 `–capath`）是**啟用**整組憑證相關參數的前提，缺這個，`–cert`／`–key` 不會生效。三者要一起給：

mosquitto_sub -h kenwoo.ddns.net -p 8883 \
  --cafile /etc/ssl/certs/ca-certificates.crt \
  --cert client_fullchain.pem \
  --key client_privkey.pem \
  -t "topic" -v
  • --cafile 這裡用系統的公開 CA 信任包即可（驗伺服器身分用，跟上面 mosquitto.conf 那個 `cafile` 是同一份東西，各自獨立設定）。
  • --cert **要給 `fullchain.pem`（葉憑證＋中繼憑證），不能只給 `cert.pem`（只有葉憑證）**——中繼憑證由 client 自己附上，伺服器才拼得出完整信任鏈，只給葉憑證會卡在 unknown ca。
  • 不確定 TLS 有沒有先建立起來時，先用 openssl s_client -connect host:8883 --cert ... --key ... 單獨測一次——但要注意這只驗證「client 信不信得過 server」，不代表 server 那邊也接受了這張 client 憑證，兩者是分開的檢查，不要看到 s_client 印出 Verify return code: 0 (ok) 就以為 client 端身分也過了。

需要更正的地方：「隨便一張公開憑證就能連」沒那麼準確

上面 2026-09-06 那次補充寫的「只要拿得出任一張公開信任機構簽發的憑證就能連」這個門檻可以接受——2026-09-12 拿一張真實的網域憑證（另一個站上網域 kenwoo.ai 的 Let’s Encrypt 憑證，跟 waterfalls／kenwoo 完全無關）實際測試，發現這句話不夠精確，過程如下：

  • 只給 --cert／--key、沒給 --cafile：伺服器回 certificate required——因為沒有 --cafile，client 端根本沒有真的送出憑證。
  • 補上 --cafile，但 --cert 給的是葉憑證（cert.pem）：伺服器回 unknown ca——缺中繼憑證，如上一節所述。
  • 改給 fullchain.pem（葉+中繼）：伺服器回 unsupported certificate。查這張憑證的 Extended Key Usage：
X509v3 Extended Key Usage:
    TLS Web Server Authentication

**只標了 serverAuth，沒有 clientAuth**——Let’s Encrypt 網域憑證預設就是這樣核發的（它的服務本來就是設計給「網站」用，不是給「client 身分」用）。所以正確的結論是：不是「任何公開 CA 簽的憑證都能拿來當 client 憑證」，而是要那張憑證的 Extended Key Usage 剛好包含 clientAuth 才行——一般網域憑證（waterfalls／kenwoo／kenwoo.ai 皆然）預設都沒有，直接拿現成的網域憑證是行不通的。這比原本以為的門檻又稍微高了一點，但仍然不是「只有我核發的憑證才能連」那種真正的存取控管。

正規解法：自己架一個私有 CA，專門簽發 clientAuth 憑證

Let’s Encrypt 這類公開 CA 走的是網域驗證流程，不提供「client 專用憑證」這個選項，這條路走不通。真正的正規解法，也是 2024 年那套自簽 CA（見本文前段「已知卡關點」與「維持擱置」段落）當初想做但沒完成的方向：自己架一個私有 CA（`openssl req`／`easy-rsa` 皆可），簽發時明確指定 extendedKeyUsage = clientAuth，`mosquitto.conf` 的 `cafile` 改指向這個私有 CA 而非系統公開清單。這樣一來，只有經過您親自簽發的憑證才能通過驗證，才是真正做到「誰能連由我決定」的存取控制。

Claude-code 補充 / 20260916：私有 CA 核發 clientAuth 憑證詳解——讓手機能連 8883 即時收 cron claude 訊息

上一節（20260912 補充）結論是：公開 CA（Let’s Encrypt）核發的網域憑證預設只有 serverAuth，沒有 clientAuth，所以沒辦法直接拿現成的網域憑證當 client 身分用；正規解法是自架一個私有 CA，專門簽發帶 clientAuth 的憑證。這段把當初沒展開的「怎麼做」補完，目標情境很具體：讓 Ken 的手機能用一張只有 Ken 自己核發過的憑證連上 8883，之後 cron claude 才有辦法把巡邏訊息用 MQTT push 到手機上即時收到。這篇只整理成可執行的教學／checklist，實際在伺服器上產生金鑰、改 mosquitto.conf，需要 Ken 執行或明確授權才會動手——私鑰產生與系統設定變更不屬於巡邏角色可自行執行的範圍。

私有 CA 的最小可行設計：單層就夠，不需要中繼 CA

公開 CA 為了風控會分 root CA／intermediate CA 兩層（root 離線保管，intermediate 才拿出來簽憑證）。但這裡的情境是「Ken 自己核發給自己的裝置用」，裝置數量少（手機、之後可能再加平板/筆電），單層（root CA 直接簽發 client 憑證）在管理成本與安全性之間是合理的取捨，不需要疊一層 intermediate 增加複雜度。

Step 1：建立 root CA（一次性，之後長期沿用）

# 產生 CA 私鑰（務必妥善保管，外洩等於任何人都能冒充手機身分連進 broker）
openssl genrsa -out kenwoo-client-ca.key 4096

# 自簽 root CA 憑證，效期給長一點（10年），CN 用好辨識的名稱
openssl req -x509 -new -nodes -key kenwoo-client-ca.key -sha256 -days 3650 \
  -subj "/CN=Kenwoo Personal Client CA" \
  -out kenwoo-client-ca.pem

這支 kenwoo-client-ca.key 就是「誰能核發新裝置憑證」的唯一鑰匙，建議存放在伺服器之外的地方（例如 Ken 自己的電腦，或離線的 USB），伺服器上只留之後要放進 mosquitto.conf 的 kenwoo-client-ca.pem（公開的 CA 憑證本身，沒有私鑰內容，外流也不會讓人能偽造憑證）。

Step 2：為手機簽發專屬 client 憑證（重點：extendedKeyUsage 一定要是 clientAuth）

先建一個 extension 設定檔，明確指定用途是 clientAuth（這是上一節踩坑學到的關鍵，公開網域憑證就是缺這個才不能用）：

# client-ext.cnf
cat > client-ext.cnf <<'EOF'
basicConstraints = CA:FALSE
extendedKeyUsage = clientAuth
EOF

# 產生手機專屬的私鑰 + CSR（CN 用來識別是哪台裝置，之後 mosquitto 因為
# use_identity_as_username true 的設定，會把這個 CN 當成連線者的身分）
openssl genrsa -out ken-phone.key 2048
openssl req -new -key ken-phone.key -subj "/CN=ken-phone" -out ken-phone.csr

# 用 root CA 簽發，帶上 client-ext.cnf 的擴充欄位
openssl x509 -req -in ken-phone.csr -CA kenwoo-client-ca.pem -CAkey kenwoo-client-ca.key \
  -CAcreateserial -days 730 -sha256 -extfile client-ext.cnf \
  -out ken-phone.pem

# 核對一下 Extended Key Usage 真的是 clientAuth（跟上一節查 LE 憑證用同一招）
openssl x509 -in ken-phone.pem -noout -text | grep -A1 "Extended Key Usage"

效期這裡抓 2 年（-days 730），比 root CA 短很多——之後每張裝置憑證到期要重簽，是刻意設計的「軟性撤銷」機制，見下面〈撤銷與到期管理〉一節。

Step 3：打包成手機 App 容易匯入的格式（PKCS#12）

大多數手機端 MQTT App 的憑證匯入介面吃的是單一 .p12／.pfx 檔（私鑰＋憑證包在一起，用密碼保護），而不是分開的 .key／.pem：

openssl pkcs12 -export -out ken-phone.p12 \
  -inkey ken-phone.key -in ken-phone.pem \
  -certfile kenwoo-client-ca.pem \
  -name "ken-phone"
# 執行時會要求設一組匯出密碼，這組密碼之後匯入手機 App 時要再輸入一次

-certfile kenwoo-client-ca.pem 會把 CA 憑證也一起包進去，方便某些 App 直接從 .p12 讀出完整鏈，不用另外再匯入一次 CA 檔。

Step 4：mosquitto.conf 需要調整的地方（只動 cafile，其餘不變）

伺服器對外「自己是誰」的身分不變，certfile／keyfile 繼續用 Let's Encrypt 那組（手機驗證 broker 身分，靠的是系統內建的公開信任清單，跟這裡無關，不用動）。唯一要改的是 8883／8884 這兩個 listener 裡的 cafile——這個欄位在 mosquitto 裡的實際作用是「broker 拿什麼 CA 去驗證 client 送過來的憑證」，把它從目前的系統公開 CA 清單，換成新建的私有 CA：

listener 8883 0.0.0.0
protocol mqtt
cafile /etc/mosquitto/certs/kenwoo-client-ca.pem   # 改成私有 CA
certfile /etc/mosquitto/certs/server_cert.pem      # 不變，仍是 LE 憑證
keyfile /etc/mosquitto/certs/server_key.pem        # 不變
require_certificate true
use_identity_as_username true
allow_anonymous true    # 可以考慮之後改 false，見下方說明

改完 pkill -HUP -x mosquitto（或 systemctl reload mosquitto）讓設定生效，之後任何沒有 ken-phone.pem 這種、由 kenwoo-client-ca.pem 簽出來的憑證，TLS 握手階段就會被擋下——包括之前能連的 kenwoo.ai 網域憑證也會失效，這是預期行為，屬於「門檻從『任何公開憑證』收緊成『只有我簽過的』」的核心目的。這一步換掉之後，allow_anonymous true 就可以考慮一併收緊成 false——因為現在 TLS 層的 require_certificate 已經是真正有效的身分限制（不再是「隨便一張公開憑證都行」的形同虛設），allow_anonymous 這個 MQTT 層開關要不要保留，變成單純的個人取捨，不影響安全性下限。

Step 5：手機端 App 選擇與匯入

需要挑一支支援「TLS client certificate（雙向 mTLS）」的 MQTT App，不是每支都支援：

  • Android：IoT MQTT Panel、MQTT Dash 都支援匯入 .p12 作為 client certificate；設定連線時 Host 填 kenwoo.ddns.net、Port 8883、TLS 開啟，Client Certificate 指到匯入的 ken-phone.p12。
  • iOS：選項比 Android 少，需要先確認手上這支 App 的版本是否真的支援 client cert（不少標榜「支援 TLS」的 App 其實只做到單向驗證 server，沒做 client cert 匯入），下載前建議先查一次 App Store 說明或開發者文件確認，避免裝了才發現不支援。

.p12 檔本身等於是手機的「連線身分證＋私鑰」，傳輸到手機時不要走公開管道（不要傳 email、不要傳公開雲端連結）——用 USB 接線傳檔案，或家用區網內部（同一個 WiFi）用 scp／即時通訊軟體的裝置對裝置傳輸，是比較合理的做法。

撤銷與到期管理的簡化做法（小規模、單一使用者情境）

正規 PKI 會搭配 CRL（憑證撤銷清單）或 OCSP，讓憑證能在到期前被主動吊銷。以這裡的規模（就一支手機，未來頂多再加一兩台裝置）架這套機制，投入產出比不划算，比較實際的替代做法：

  • 裝置憑證效期刻意設短（上面範例是 2 年），到期自動失效，不需要額外撤銷動作。
  • 如果真的需要「立刻」讓某張憑證失效（例如手機遺失），最快的做法是直接換一把新的 root CA，重新簽發其餘還在用的裝置憑證，把新的 kenwoo-client-ca.pem 換上 mosquitto.conf——舊 CA 簽出來的所有憑證（含遺失那支手機）會立刻全部失效。裝置數量只有個位數時，這個「整批換發」比架 CRL 基礎設施單純很多。
  • 每簽一張新憑證，順手記一筆到某個清單檔（CN、簽發日期、到期日、用途），避免時間久了忘記手上到底核發過哪些憑證。

這篇解決的是「連線授權」，不是「cron claude 怎麼發訊息」——後者是另一個待實作項目

以上步驟做完，手機理論上就能連上 8883 訂閱任意 topic。但「cron claude 巡邏完後主動 publish 一則訊息到某個 topic」這件事，目前還沒有對應的程式碼或機制——`patrol.sh` 目前是把結果寫進 `~/patrol-log/*.md`，沒有任何 MQTT publish 的動作。之後若要真的打通「手機即時收到 cron claude 訊息」，還需要：① 決定用哪個 topic（例如 `waterfalls/patrol/notify`）；② 在 patrol.sh 或報告產出流程裡加一段 `mosquitto_pub`（或 Python `paho-mqtt`）呼叫，帶上 client 憑證發送；③ 手機 App 訂閱同一個 topic 並開啟通知。這幾步不難，但跟這篇「怎麼核發一張能連線的憑證」是不同層次的工作，留待私有 CA 這段基礎架好、Ken 確認要往下做時再接續。

給 Ken 的 checklist（實際動手時，這些步驟需要 Ken 執行或明確授權）

  • ☐ 決定 root CA 私鑰要存放在哪裡（建議伺服器之外）
  • ☐ 執行 Step 1～3，產生 ken-phone.p12
  • ☐ 把 mosquitto.conf 的 cafile 改指向新的私有 CA（Step 4），reload mosquitto
  • ☐ 手機安裝支援 client cert 的 MQTT App，匯入 ken-phone.p12，實測連線成功
  • ☐ 確認舊的（用公開憑證連線的）測試方式此後應該連不上，驗證門檻真的收緊了
  • ☐（選擇性）評估是否要把 allow_anonymous 一併改成 false
  • ☐ 之後再談 cron claude 主動 publish 訊息這部分怎麼接（見上一節）

Categories: 未分類

PHP Code Snippets Powered By : XYZScripts.com