您需要多少 SSL 證書 - aspnet core + Apache 反向代理？
在 Linux 上部署 aspnet 核心應用程序時，通常通過反向代理來完成。即 Kestrel 託管應用程序，Apache 處理與 Kestrel 通信的公共網際網路流量。
所以 Kestrel 和 Apache 需要用於 https 的 SSL 證書。
該應用程序中還
Identity Server 4使用了需要證書的功能。我以前使用過 Kestrel 和 Identity Server 的自簽名證書。但現在我在想 - 這是正確的方式嗎？
問題 -使用 3 個不同的證書是否更安全，或者我可以只為所有 3 個證書使用一個 CA 證書？
恐怕這個問題沒有簡單的是/否答案。
如果 Kestrel 和 Apache 在同一個機器上執行，那麼您只是在有效地使用證書，因為 Kestrel 需要一個。它不提供安全性，**它更安全嗎？**問題不適用。
如果 Kestrel 和 Apache 在不同的盒子上，那麼它會稍微複雜一些。如果這兩個盒子在一個受信任的網路上，你可以和上面一樣爭論——證書在那裡只是因為 Kestrel 需要一個。
如果網路不受信任，您現在需要一些安全措施。該證書提供發起 TLS 連接所需的機器身份。無論您為此使用自簽名證書還是 CA 簽名證書，都會增加更多選擇。
- 如果 Kestrel 應用程序使用內部 FQDN（例如
app.local）並且 CA 不願意證明這些名稱（例如商業 CA 不會這樣做），那麼您將被迫使用自簽名證書。- 如果 CA 是內部的並且願意認證本地名稱，那麼您可以考慮將 CA 用於 Kestrel 證書。
因此，假設現在您可以為 Kestrel 使用 CA 證書，接下來您需要問自己為什麼需要這樣做：
CA 簽名證書通常在一對多場景中變得有價值。如果您有一台伺服器和許多依賴方（客戶端），那麼 CA 頒發的證書可確保：
- 依賴方只需要信任 CA，每個頒發的證書都是隱式信任的（自簽名證書需要被所有客戶端信任）；
- 依賴方不需要審查他們希望信任的每台伺服器的治理和操作流程，因為他們可以假設如果 CA 已經對其進行了認證，那麼它就是值得信賴的；
- 證書續訂後一切正常（與自簽名相比，自簽名需要在續訂後分發給所有客戶）；
- 吊銷有效（自簽名證書沒有吊銷的概念 - 如果伺服器證書被洩露，您必須從所有客戶端刪除證書）；
但是，如果您處於一對一的場景中（例如在反向代理和應用程序伺服器之間），那麼 CA 帶來的好處就更少（信任決策更容易，更新也很容易，如果伺服器受到威脅，您只需刪除來自一位客戶的證書）。事實上，如果您沒有可用的 CA，僅為應用程序伺服器和反向代理之間的連接而建構和管理 CA 的成本太大，以至於不值得。
對於後者，使用自簽名證書的唯一缺點可能是缺乏中央管理。許多 CA 幫助管理已頒發證書的生命週期，即使它是簡單的自動電子郵件提醒您證書即將到期，或者像自動續訂一樣複雜。自簽名證書由您管理。為了幫助緩解這種情況，一些組織使用證書生命週期管理工具來管理他們的證書，如果該工具也可以監控自簽名證書，那麼就可以解決這個問題。
因此，總而言之，如果您的 CA 提供額外的生命週期管理服務來幫助您管理證書，那麼它可能值得考慮；但除此之外，在應用程序伺服器和反向代理之間等一對一場景中，使用自簽名證書還是 CA 簽名證書並沒有真正的區別。
如果您確實遵循 CA 為應用程序伺服器頒發的證書的路線，您有更多的決定：
- 如果應用程序和反向代理在同一個盒子上，您可以安全地考慮在它們之間使用一個證書 - 您不太可能處於一種服務受到損害而另一種服務仍然受信任的情況。你會（應該）假設一個盒子上的所有證書都被洩露了，所以單獨的證書通常沒有真正的好處。
- 如果應用程序位於不同的盒子上，那麼您可能會遇到一個被入侵而另一個沒有被入侵的情況。在為此類情況做準備時，您應該在每個盒子上貼上不同的證書。
請注意，雖然上面討論了應用程序伺服器和反向代理之間的通信，但您可以嘗試使用Identity Server 4進行相同的推理（無論是什麼）。