Engineering Jul 19, 2026 · 2 min read

一張遷移單背後的兩個 SSL

一張一句話的遷移單（申請憑證、把 Kafka 換到 9093 埠），藏著兩個方向相反的 TLS：入口的單向 TLS，以及對 Kafka 的雙向 mTLS。

一個任務就一句話：申請新憑證，把 Kafka 從 9092 埠（明文）換到 9093 埠（加密）。很短，聽起來很例行，但我一直看不懂「點」在哪。服務對外明明就已經有加密的 HTTPS 了，那為什麼還要再申請一張憑證、再把另一個埠加密？

先認識幾個名詞（讀之前先看這個）

TLS／SSL：幫一條網路連線做兩件事的協定，一是加密（中間的人看不到內容），二是驗證身分（你能確認對方是誰）。「SSL」是舊名，「TLS」是它現在的正式名字。
憑證（certificate）：一份證明「我是誰」的數位文件，由一個大家都信任的機構簽發。
PKI（公開金鑰基礎設施）：讓一張憑證「可信」的一整套體系，包含簽發憑證的憑證機構（CA）、憑證本身，以及背後的私鑰。大家口中「那套 TLS」，底下運作的就是這套 PKI。
埠（port）：伺服器上一個編號的連線通道。同一台機器靠不同編號，區分不同服務。
Kafka：一套讓服務之間互傳事件的訊息系統；它的伺服器節點叫 broker。
對外入口（ingress）：服務通常跑在 Kubernetes（一個管理大量小服務的平台）上，最外層有一個統一接住外部流量、再轉給內部服務的入口。

兩個「SSL」指向相反：對外入口在進來時把加密收掉，服務在出去時把加密加上。兩者根本碰不到彼此。

系統裡有兩個不一樣的「SSL」，而且方向相反。入口那個 SSL 保護的是進來的流量，而且一進門就被收掉；Kafka 那個 SSL 保護的是出去的流量，由服務自己加上。兩者根本碰不到彼此，這也正是為什麼這次遷移改了一個、卻可以完全不動另一個。

當一個系統在兩個地方都寫「SSL」，別預設它們是同一個功能。先問每一個各自保護哪個方向。我一半的困惑，只是同一個字在兼兩份差。

1. TLS 保證兩件事，需要三個檔。 TLS 給你加密（一把這次連線專用的共用金鑰）和身分（一張憑證）。身分這半就是三個檔案的來源：一個用來驗證對方、一個是你的公開身分、還有一把私鑰證明這身分是你的、而且絕不離開你的機器。私鑰一漏，整套就沒意義了。→ 深入：TLS 基礎，以及三個憑證檔。

2. 單向還雙向：看誰得出示憑證。 一般 HTTPS 是單向，只有伺服器證明自己是誰。雙向 TLS（mTLS）讓客戶端也得證明自己，於是兩端互相檢查，只要一邊的憑證有問題就拒絕連線。→ 深入：單向 TLS 與雙向 mTLS。

3. Kafka 那步是換埠，不是升級。 一台 Kafka 伺服器，一個埠只講一種協定。9092 是明文、9093 是加密，中間沒有把同一條連線就地升級這回事。→ 深入：Kafka 的兩個埠：9092 與 9093。

4. 客戶端靠「沒設定」來決定走明文。 連 Kafka 的客戶端函式庫需要幾個加密設定，但只有在你叫它用的時候才需要。沒設，它就安靜地維持明文，就是這一個開關，讓正式環境跑加密、我本機的設定卻完全不用動。→ 深入：Kafka 客戶端的 SSL 設定，以及「缺席即明文」。

5. 「另一個 SSL」原來是對外入口。 我一直指著的那個 SSL 是對外入口：單向 TLS，替進來的網頁流量自動處理好加密。它從頭到尾都不在這次 Kafka 工作的範圍內，因為它面向的是反方向。→ 深入：Ingress 憑證終結。

6. 憑證在服務啟動之前就到位了。 那些憑證檔不是服務運行時才去抓的。它們在部署階段就先從一個機密儲存服務裡拉出來、烤進部署內容，再掛成純檔案。→ 深入：把憑證送進 Pod。

那張單子就三個字的術語，而整團霧其實大半來自同一個字：「SSL」在替兩個毫不相干的信任方向兼差。等我把箭頭畫出來（進來的單向 TLS 在入口、出去的雙向 mTLS 對 Kafka），這次遷移就不再神祕，變回它本來的樣子：把客戶端指到新的埠，加上背後一點憑證的搬運。

下次我會更快問自己的幾個問題：

當一個系統在兩個地方都寫「SSL」，先問每一個各自保護哪個方向，別預設它們是同一個功能。

延伸閱讀： 先看三個憑證檔與單向 vs 雙向 TLS；再看為什麼 Kafka 的 9092 與 9093 是一扇門而非升級，以及客戶端如何靠缺席決定走明文；接著是「另一個 SSL」：Ingress 憑證終結，以及憑證怎麼送進 Pod。

Tags #tls #security #kafka