一、HTTP、HTTPS、SSL、TLS
HTTP 是一個網絡協議，是專門用來傳輸 Web 內容，大部分網站都是通過 HTTP 協議來傳輸 Web 頁面、以及 Web 頁面上包含的各種東東（圖片、CSS 樣式、JS 腳本）。
SSL 是“Secure Sockets Layer”的縮寫，中文叫做“安全套接層”。它是在上世紀90年代中期，由網景公司設計的。（順便插一句，網景公司不光發明了 SSL，還發明了很多 Web 的基礎設施——比如“CSS 樣式表”和“JS 腳本”），為啥要發明 SSL 這個協議捏？因為原先互聯網上使用的 HTTP 協議是明文的，存在很多缺點——比如傳輸內容會被偷窺（嗅探）和篡改。發明 SSL 協議，就是為了解決這些問題。
TLS是 SSL的 標准化，SSL標准化之后的名稱改為 TLS（是“Transport Layer Security”的縮寫），中文叫做“傳輸層安全協議”。很多相關的文章都把這兩者並列稱呼（SSL/TLS），因為這兩者可以視作同一個東西的不同階段。
HTTPS 協議，說白了就是“HTTP 協議”和“SSL/TLS 協議”的組合。你可以把 HTTPS 大致理解為——“HTTP over SSL”或“HTTP over TLS”。
二、CA認證的原理
通過下面介紹信的描述介紹CA的原理。
◇ 普通的介紹信
想必大伙兒都聽說過介紹信的例子吧？假設 A 公司的張三先生要到 B 公司去拜訪，但是 B 公司的所有人都不認識他，他咋辦捏？常用的辦法是帶公司開的一張介紹信，在信中說：茲有張三先生前往貴公司辦理業務，請給予接洽......
雲雲。然后在信上敲上A公司的公章。
張三先生到了 B 公司后，把介紹信遞給 B 公司的前台李四小姐。李小姐一看介紹信上有 A 公司的公章，而且 A 公司是經常和 B 公司有業務往來的，這位李小姐就相信張先生不是歹人了。
這里，A公司就是CA證書
◇ 引入中介機構的介紹信
好，回到剛才的話題。如果和 B 公司有業務往來的公司很多，每個公司的公章都不同，那前台就要懂得分辨各種公章，非常滴麻煩。所以，有某個中介公司 C，發現了這個商機。C公司專門開設了一項“代理公章”的業務。
今后，A 公司的業務員去 B 公司，需要帶2個介紹信：
介紹信1
含有 C 公司的公章及 A 公司的公章。並且特地注明：C 公司信任 A 公司。
介紹信2
僅含有 A 公司的公章，然后寫上：茲有張三先生前往貴公司辦理業務，請給予接洽......
雲雲。
某些不開竅的同學會問了，這樣不是增加麻煩了嗎？有啥好處捏？
主要的好處在於，對於接待公司的前台，就不需要記住各個公司的公章分別是啥樣子的；他/她只要記住中介公司 C 的公章即可。當他/她拿到兩份介紹信之后，先對介紹信1的 C 公章，驗明正身；確認無誤之后，再比對介紹信1和介紹信2的兩個 A 公章是否一致。如果是一樣的，那就可以證明介紹信2是可以信任的了。
三、公鑰基礎設施(PKI)
CA(Certification Authority)證書，指的是權威機構給我們頒發的證書。
密鑰就是用來加解密用的文件或者字符串。密鑰在非對稱加密的領域里，指的是私鑰和公鑰，他們總是成對出現，其主要作用是加密和解密。常用的加密強度是2048bit。
RSA即非對稱加密算法。非對稱加密有兩個不一樣的密碼，一個叫私鑰，另一個叫公鑰，用其中一個加密的數據只能用另一個密碼解開，用自己的都解不了，也就是說用公鑰加密的數據只能由私鑰解開。
證書的編碼格式
PEM(Privacy Enhanced Mail)，通常用於數字證書認證機構（Certificate Authorities，CA），擴展名為.pem, .crt, .cer, 和 .key。內容為Base64編碼的ASCII碼文件，有類似"-----BEGIN CERTIFICATE-----" 和 "-----END CERTIFICATE-----"的頭尾標記。服務器認證證書，中級認證證書和私鑰都可以儲存為PEM格式（認證證書其實就是公鑰）。Apache和nginx等類似的服務器使用PEM格式證書。
DER(Distinguished Encoding Rules)，與PEM不同之處在於其使用二進制而不是Base64編碼的ASCII。擴展名為.der，但也經常使用.cer用作擴展名，所有類型的認證證書和私鑰都可以存儲為DER格式。Java使其典型使用平台。
證書簽名請求CSR
CSR(Certificate Signing Request)，它是向CA機構申請數字×××書時使用的請求文件。在生成請求文件前，我們需要准備一對對稱密鑰。私鑰信息自己保存，請求中會附上公鑰信息以及國家，城市，域名，Email等信息，CSR中還會附上簽名信息。當我們准備好CSR文件后就可以提交給CA機構，等待他們給我們簽名，簽好名后我們會收到crt文件，即證書。
注意：CSR並不是證書。而是向權威證書頒發機構獲得簽名證書的申請。
把CSR交給權威證書頒發機構,權威證書頒發機構對此進行簽名,完成。保留好CSR,當權威證書頒發機構頒發的證書過期的時候,你還可以用同樣的CSR來申請新的證書,key保持不變.
數字簽名
數字簽名就是"非對稱加密+摘要算法"，其目的不是為了加密，而是用來防止他人篡改數據。
其核心思想是：比如A要給B發送數據，A先用摘要算法得到數據的指紋，然后用A的私鑰加密指紋，加密后的指紋就是A的簽名，B收到數據和A的簽名后，也用同樣的摘要算法計算指紋，然后用A公開的公鑰解密簽名，比較兩個指紋，如果相同，說明數據沒有被篡改，確實是A發過來的數據。假設C想改A發給B的數據來欺騙B，因為篡改數據后指紋會變，要想跟A的簽名里面的指紋一致，就得改簽名，但由於沒有A的私鑰，所以改不了，如果C用自己的私鑰生成一個新的簽名，B收到數據后用A的公鑰根本就解不開。
常用的摘要算法有MD5、SHA1、SHA256。
使用私鑰對需要傳輸的文本的摘要進行加密，得到的密文即被稱為該次傳輸過程的簽名。
數字證書和公鑰
數字證書則是由證書認證機構（CA）對證書申請者真實身份驗證之后，用CA的根證書對申請人的一些基本信息以及申請人的公鑰進行簽名（相當於加蓋發證書機 構的公章）后形成的一個數字文件。實際上，數字證書就是經過CA認證過的公鑰，除了公鑰，還有其他的信息，比如Email，國家，城市，域名
四、CFSSL安裝及基礎知識
項目地址： https://github.com/cloudflare/cfssl
下載地址： https://pkg.cfssl.org/
CFSSL是CloudFlare開源的一款PKI/TLS工具。 CFSSL 包含一個命令行工具 和一個用於 簽名，驗證並且捆綁TLS證書的 HTTP API 服務。 使用Go語言編寫。
CFSSL包括：
-
一組用於生成自定義 TLS PKI 的工具
-
cfssl程序，是CFSSL的命令行工具 -
multirootca程序是可以使用多個簽名密鑰的證書頒發機構服務器 -
mkbundle程序用於構建證書池 -
cfssljson程序，從cfssl和multirootca程序獲取JSON輸出，並將證書，密鑰，CSR和bundle寫入磁盤
PKI借助數字證書和公鑰加密技術提供可信任的網絡身份。通常，證書就是一個包含如下身份信息的文件：
-
證書所有組織的信息
-
公鑰
-
證書頒發組織的信息
-
證書頒發組織授予的權限，如證書有效期、適用的主機名、用途等
-
使用證書頒發組織私鑰創建的數字簽名
1、安裝 cfssl 工具集
sudo mkdir -p /opt/k8s/cert && cd /opt/k8s wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 mv cfssl_linux-amd64 /opt/k8s/bin/cfssl wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 mv cfssljson_linux-amd64 /opt/k8s/bin/cfssljson wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 mv cfssl-certinfo_linux-amd64 /opt/k8s/bin/cfssl-certinfo chmod +x /opt/k8s/bin/* export PATH=/opt/k8s/bin:$PATH
二、創建配置文件
CA 配置文件用於配置根證書的使用場景 (profile) 和具體參數 (usage，過期時間、服務端認證、客戶端認證、加密等)，后續在簽名其它證書時需要指定特定場景。
cd /opt/k8s/work cat > ca-config.json <<EOF { "signing": { "default": { "expiry": "87600h" }, "profiles": { "kubernetes": { "usages": [ "signing", "key encipherment", "server auth", "client auth" ], "expiry": "87600h" } } } } EOF
知識點：
ca-config.json：可以定義多個 profiles，分別指定不同的過期時間、使用場景等參數；后續在簽名證書時使用某個 profile；此實例只有一個kubernetes模板。
signing：表示該證書可用於簽名其它證書；生成的 ca.pem 證書中 CA=TRUE；
server auth：表示client可以用該 CA 對server提供的證書進行驗證；
client auth：表示server可以用該CA對client提供的證書進行驗證；
注意標點符號，最后一個字段一般是沒有都好的。
三、創建證書簽名請求文件
cd /opt/k8s/work cat > ca-csr.json <<EOF { "CN": "kubernetes", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "BeiJing", "L": "BeiJing", "O": "k8s", "OU": "4Paradigm" } ], "ca": { "expiry": "876000h" } } EOF
+ CN：Common Name ，kube-apiserver 從證書中提取該字段作為請求的用戶名(User Name)，瀏覽器使用該字段驗證網站是否合法；
+ O： Organization ，kube-apiserver 從證書中提取該字段作為請求用戶所屬的組(Group)；
+ kube-apiserver 將提取的 User、Group 作為 RBAC 授權的用戶標識；
四、生成 CA 證書和私鑰
cd /opt/k8s/work cfssl gencert -initca ca-csr.json | cfssljson -bare ca ls ca*
將會生成 ca-key.pem（私鑰） ca.pem（公鑰）