由於大型科技公司企盼打造更安全的網際網路而施加壓力，線上組織採用 SSL/TLS 加密已成為安全性最佳做法並逐漸成為要求。例如，Google Chrome 網頁瀏覽器在 2016 年底開始以可見的方式將未使用 HTTPS 的網站標示為「不安全」。1與此同時，Mozilla 的 FireFox 網頁瀏覽器開始對試圖提交未由 HTTPS 保護之資訊形式的使用者發出更嚴重的警告。2
提交表格，即表示您同意接收關於 Cloudflare 產品、活動和特別優惠的資訊。您可以隨時退訂此類訊息。我們重視您的隱私選擇，絕不會出售您的資料。請參閱我們的隱私權政策以瞭解相關資訊。
Cloudflare SSL for SaaS 使 SaaS 公司的最終客戶可以繼續使用自訂網域，同時透過 SSL 保護其通訊。最終客戶可以享受的益處包括品牌化訪客體驗、增強的信任度、SEO 排名以及使用 HTTP/2 來提高速度的能力。Cloudflare 可以自動完成從購買到部署再到憑證更新的整個 SSL 生命週期，並且可以在幾分鐘之內完成，使 SaaS 公司可以在客戶上線流程中提供這一優勢。
無 SSL 的自訂網域缺少 SSL 的效能與安全資料傳輸優勢，因此內容在傳遞給訪客前易被窺探，且可能被竄改或插入惡意程式碼。
透過 SaaS 提供者啟用 SSL 的網域缺少自訂網域，因此會使得品牌認知度與 SEO 排名下降。
想要加密品牌化自訂網域的 SaaS 提供者可以手動管理 SSL 生命週期 (但這樣會導致部署時間變長且成本過高)，或建置複雜的自動化內部解決方案。
與 Cloudflare 聯繫。
品牌化訪客體驗
為最終客戶提供自有品牌自訂網域方案的 SaaS 提供者可以繼續這樣做，同時享受完全託管的 SSL 憑證的額外好處。自有品牌網域為最終客戶提供了更高的 SEO 排名並提高了訪客的信任度。
有效率地保護客戶資產
最終客戶網域上的 SSL/TLS 憑證可確保敏感客戶資料獲得安全傳輸，防止中間人攻擊和網路監聽。此外，HTTP/2 通訊協定可用於進一步提高速度。
自動化 SSL 生命週期管理
Cloudflare 管理 SaaS 提供者的客戶自訂網域的整個 SSL 生命週期，從私密金鑰建立和保護到網域驗證、簽發、更新和重新發佈，一應俱全。
快速的全球 SSL 部署
在 SSL 簽發程序期間，Cloudflare 在其涵蓋 200 個城市的全球資料中心網路中部署新憑證，使 HTTPS 在數分鐘內上線，並盡可能接近訪客。
要為自訂網域構建內部 SSL 解決方案，可以採取兩種方法，這兩種方法都需要 SaaS 提供者和最終客戶共同努力。下圖中的自動化路徑 (上方部分) 自動執行 SSL 流程，但需要大量的工程設計工作和應對複雜的安全性挑戰。手動路徑 (下方部分) 需要 SaaS 提供者團隊及其最終客戶共同努力，而錯過憑證過期期限和服務中斷的可能性更高。無論這些路徑的選擇，效能都可能會受到影響，除非可以在大規模全球分發網路上部署 SSL 憑證。
僅 HTTP CNAME
首先，SaaS 提供者最終客戶僅在其 CNAME 的自訂網域上傳送和接收 HTTP 流量。
手動上傳憑證
若要啟動將 SSL 新增至 CNAME 自訂網域的過程，需要設定一個過程，客戶可以透過該過程購買憑證並將其傳送到 SaaS 提供者以進行手動上傳。
手動管理憑證生命週期
上傳客戶憑證後，需要手動管理，以處理所述憑證的生命週期。這包括透過網域驗證、簽發、更新和重新簽發進行的私密金鑰簽發/保護。
建置 API 整合 (例如使用 Let’s Encrypt )
隨著使用 SaaS 提供者的服務的網站和客戶總數的規模開始擴大，將需要做出以下決定：為自訂網域自動化 SSL 生命週期過程——這需要進行更高水準的工程設計，或者繼續擴展手動生命週期管理——這需要的工程設計工作量較少，但會給內部團隊和最終客戶帶來負擔。
安全地處理加密金鑰
私密金鑰必須具有安全的儲存、靜態加密，並且永遠不能以明文形式寫入磁碟。加密金鑰很容易，但是要即時解密則很困難，因為這需要人工或大量的工程設計工作。私密金鑰管理最佳做法已在 OWASP.org 上發佈。Cloudflare 是為數百萬個網域產生和保護私密金鑰的專家，提供 Universal SSL、專用憑證和 SSL for SaaS 產品。
全球憑證發佈網路
若要緩解效能損失，需要在全球範圍內系統地分發憑證，使憑證盡可能接近客戶的訪客。最終客戶訪客的請求必須行進的距離越遠，其頁面載入時間就越長。使用 TLS 1.2，初始 TLS 交握需要 2 次往返；如果此交握只能在少數地方結束，效能將受到影響。
持續的維護與持續的支援工作 (自動化路徑)
對於選擇了自動方法來構建內部 SSL 解決方案的 SaaS 公司而言，大部分維護工作將包括保持程式碼基底更新並與憑證授權整合和標準相容。
建置並訓練客戶連絡團隊
SaaS 提供者公司內部的新團隊或現有團隊將需要為最終客戶手動管理憑證生命週期。客戶聯絡團隊將需要聯繫客戶，提供有關憑證到期的最新資訊，並要求更新新憑證。
需客戶配合進行手動更新
客戶需要參與憑證更新流程，他們要更新憑證並將之重新傳送給負責管理上傳過程的團隊。此外，他們必須在現有憑證到期之前執行此更新過程。如果現有憑證到期，則除非採取預防措施，否則客戶的網際網路資產可能會離線。
持續的維護與持續的支援工作 (手動路徑)
對於選擇手動方法來構建內部 SSL 解決方案的 SaaS 公司，大多數維護將包括 SaaS 提供者進行的持續手動工作——這是為了安全地保護私密金鑰、管理憑證生命週期、提醒客戶更新，並重新上傳新憑證；SaaS 提供者最終客戶將必須參與憑證生命週期流程，他們需要定期更新和重新傳送憑證。
輕鬆的 Cloudflare API/UI 整合
CloudFlare 的 SSL for SaaS 解決方案只需要很少的工程設計工作，並消除了 SaaS 提供者和最終客戶管理 SSL 生命週期的負擔。
SSL for SaaS 流程完全由 Cloudflare 處理，並且僅要求 SaaS 提供者傳送單一 API 呼叫 (或在 Cloudflare 儀表板中點按幾下)，作為最終客戶自訂網域上線流程的一部分。之後，SaaS 提供者最終客戶只需要將初始 CNAME 新增至 SaaS 提供者的網域中即可。Cloudflare 完全管理其餘自訂網域的上線流程。
此過程的其餘部分由 Cloudflare 管理，包括：
問：客戶的流量如何傳送到我的原點？這安全嗎？
答：是的，Cloudflare 鼓勵您使用 Full (完整) 或 Strict (嚴格) SSL 模式，以便流量使用 HTTPS 傳送到您的原點。可以在區域的 Crypto 標籤下設定此選項。如果使用 Strict 模式，則必須確保原點上的憑證中包含與客戶的主機名稱相符的主體別名 (SAN)，如support.yourcustomer.site。我們的 Origin CA 產品可用於產生這些憑證以用於 Strict 模式。
問：簽發憑證並使之就緒需要多長時間？
答：憑證通常會在幾分鐘內得到驗證、簽發並推送到我們的邊緣。您可以透過發起 GET 呼叫來監控各種狀態 (初始化、待驗證、待簽發、待部署、作用中) 的進度。
$ curl -sXGET -H "X-Auth-Key: [YOUR KEY]" -H "X-Auth-Email: [YOUR EMAIL]" https://www.cloudflare.com/api/v4/zones/[ZONEID]/custom_hostnames?hostname=support.yourcustomer.site
{ "result": { "id": "cdc2a12a-99b3-48b8-9039-ad1b48c639e5", "hostname": "support.yourcustomer.site", "ssl": { "id": "3463325d-8116-48f3-ab4e-a75fb9727326", "type": "dv", "method": "http", "status": "active" } }, "success": true }
問：更新或重新簽發呢？我或我的客戶需要做什麼事情嗎？
答：不，Cloudflare 會為您處理所有一切。我們頒發的憑證有效期為一年 (365 天)，並且將在到期前至少 30 天自動更新。這些憑證以您客戶的主機名稱頒發，是唯一的內容，因此，只要 CNAME 仍然存在，我們就可以透過展示該主機名稱的「網域驗證控制」來繼續輕鬆更新。如果客戶有其他想法，我們建議您向 Cloudflare 傳送 DELETE (刪除) 請求，以便 Cloudflare 可以從邊緣刪除憑證而不嘗試更新。
問：我的客戶將享受 Cloudflare 的哪些好處？
答：除了保護客戶的 DNS 基礎結構 (除非他們還將 Cloudflare 用於權威名稱服務) 外，最簡潔有力的答案是：所有好處。一旦他們的流量指向您的白標籤主機名稱，Cloudflare 就能夠提供領先業界的 DDoS 保護、CDN、WAF、HTTP/2、負載平衡等。
問：如果我的客戶已經在其自訂主機名稱上使用 HTTPS 怎麼辦？有沒有辦法避免遷移時的停機時間？
答：在某些情況下，您可能已經在內部根據客戶提供的關鍵材料拼湊了一個解決方案。或者您的客戶選擇提供 HTTPS 的競爭對手 (或內部解決方案) 來使用其所需的主機名稱，無法忍受短暫的維護週期。
對於這些情況，我們將專用憑證中可用的兩種替代「預驗證」方法擴展到我們的 SSL for SaaS 產品：電子郵件和 CNAME。只需在上面的 API 呼叫中將 SSL 方法從「http」更改為「email」或「cname」，然後傳送請求即可。有關更多資訊，請參見 API 文件。
CNAME 權杖是另一種替代方法，通常在您控制 DNS 的自訂名稱時使用 (我們的某些 SaaS 客戶，特別是那些提供網站建置和代管服務的客戶，允許將自訂網域註冊為工作流程的一部分)。
最後，您可以在原點上自由提供「http」驗證方法返回的 HTTP 權杖 (而不是讓 Cloudflare 在反向代理期間插入)，一旦就位，我們的自動重試佇列將對其進行偵測。如果您想在其就位後告訴 Cloudflare 並立即重試，則始終可以向端點傳送 PATCH，使用 POST 期間傳送的相同 SSL 正文，我們將立即進行檢查。
1 https://motherboard.vice.com/en_us/article/google-chrome-shaming-http-unencrypted-websites-january
2 https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-non-secure-http/
To provide you with the best possible experience on our website, we may use cookies, as described here.By clicking accept, closing this banner, or continuing to browse our websites, you consent to the use of such cookies.