熟悉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安裝及基礎知識

cfssl是CloudFlare開源的一款PKI/TLS工具。CFSSL 包含一個命令行工具和一個用于簽名、驗證并且捆綁TLS證書的HTTP API 服務。使用Go語言編寫。

CFSSL包括：

•   一組用于生成自定義 TLS PKI 的工具
•  cfssl程序，是cfssl的命令行工具
•  multirootca程序是可以使用多個簽名密鑰的證書頒發機構服務器
•  mkbundle程序用于構建證書池
•  cfssljson程序，從cfssl和multirootca程序獲取JSON輸出，并將證書，密鑰，CSR和bundle寫入磁盤

PKI借助數字證書和公鑰加密技術提供可信任的網絡身份。通常，證書就是一個包含如下身份信息的文件：

•  證書所有組織的信息
•  公鑰
•  證書頒發組織的信息
•  證書頒發組織授予的權限，如證書有效期、適用的主機名、用途等
•  使用證書頒發組織私鑰創建的數字簽名

安裝 cfssl

這里我們只用到cfssl工具和cfssljson工具 

# curl -L https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o /usr/local/bin/cfssl  
# curl -L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o /usr/local/bin/cfssljson  
# curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o /usr/local/bin/cfssl-certinfo  
# chmod +x /usr/local/bin/cfssl* 

cfssl 常用子命令介紹 

bundle: 創建包含客戶端證書的證書包  
genkey: 生成一個key(私鑰)和CSR(證書簽名請求)  
scan: 掃描主機問題  
revoke: 吊銷證書  
certinfo: 輸出給定證書的證書信息， 跟cfssl-certinfo 工具作用一樣  
gencrl: 生成新的證書吊銷列表  
selfsign: 生成一個新的自簽名密鑰和 簽名證書  
print-defaults: 打印默認配置，這個默認配置可以用作模板  
serve: 啟動一個HTTP API服務  
gencert: 生成新的key(密鑰)和簽名證書  
 -ca：指明ca的證書  
 -ca-key：指明ca的私鑰文件  
 -config：指明請求證書的json文件  
 -profile：與-config中的profile對應，是指根據config中的profile段來生成證書的相關信息  
ocspdump: 從cert db 中的所有 OCSP 響應中生成一系列連貫的 OCSP 響應，供 ocspserve 使用  
ocspsign: 為給定的CA、Cert和狀態簽署OCSP響應。返回一個base64編碼的OCSP響應  
info: 獲取有關遠程簽名者的信息  
sign: 簽名一個客戶端證書，通過給定的CA和CA密鑰，和主機名  
ocsprefresh: 用所有已知未過期證書的新OCSP響應刷新ocsp_responses表。  
ocspserve: 設置一個HTTP服務器，處理來自文件或直接來自數據庫的OCSP請求（見RFC 5019）。 

常用命令 

$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca ## 初始化ca  
$ cfssl gencert -initca -ca-key key.pem ca-csr.json | cfssljson -bare ca ## 使用現有私鑰, 重新生成  
$ cfssl certinfo -cert ca.pem  
$ cfssl certinfo -csr ca.csr 

使用 CFSSL 創建 CA 認證步驟

創建認證中心(CA)

cfssl 可以創建一個獲取和操作證書的內部認證中心。運行認證中心需要一個 CA 證書和相應的 CA 私鑰。任何知道私鑰的人都可以充當CA來頒發證書。因此，私鑰的保護至關重要，這里我們以 k8s 所需的證書來實踐一下： 

$ cfssl print-defaults config > config.json # 默認證書策略配置模板  
$ cfssl print-defaults csr > csr.json #默認csr請求模板 

結合自身的要求，修改證書請求文件csr.json,證書10年 

{  
  "CN": "kubernetes",  
  "key": {  
    "algo": "rsa",  
    "size": 2048  
  },  
  "names": [  
    {  
      "C": "CN",  
      "ST": "BeiJing",  
      "L": "BeiJing",  
      "O": "k8s",  
      "OU": "System"  
    }  
   ],  
   "ca": {  
    "expiry": "87600h"  
  }  
} 

知識點 ：

•  "CN"：Common Name，kube-apiserver 從證書中提取該字段作為請求的用戶名 (User Name)
•  "O"：Organization，kube-apiserver從證書中提取該字段作為請求用戶所屬的組 (Group)
•  C: Country， 國家
•  L: Locality，地區，城市
•  O: Organization Name，組織名稱，公司名稱
•  OU: Organization Unit Name，組織單位名稱，公司部門
•  ST: State，州，省

證書配置模板文件ca-config.json 

{  
  "signing": {  
      "default": {  
        "expiry": "87600h"  
   },  
  "profiles": {  
    "kubernetes": {  
      "usages": [  
        "signing",  
        "key encipherment",  
        "server auth",  
        "client auth"  
      ],  
      "expiry": "87600h"  
    }  
   }  
  }  
} 

知識點：

•  config.json：可以定義多個 profiles，分別指定不同的過期時間、使用場景等參數；后續在簽名證書時使用某個 profile；此實例只有一個kubernetes模板。
•  signing：表示該證書可用于簽名其它證書；生成的 ca.pem 證書中CA=TRUE
•  server auth：表示client可以用該 CA 對server提供的證書進行驗證；
•  client auth：表示server可以用該CA對client提供的證書進行驗證；
•  注意標點符號，最后一個字段一般是沒有逗號的。

初始化創建CA認證中心，將會生成ca-key.pem（私鑰）和ca.pem（公鑰） 

$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca 

創建 Kubernetes 證書

創建kubernetes-csr.json證書請求文件 

{  
    "CN": "kubernetes",  
    "hosts": [  
        "127.0.0.1",  
        "10.1.20.129",  
        "10.1.20.128",  
        "10.1.20.126",  
        "10.1.20.127",  
        "10.254.0.1",  
        "*.kubernetes.master",  
        "localhost",  
        "kubernetes",  
        "kubernetes.default",  
        "kubernetes.default.svc",  
        "kubernetes.default.svc.cluster",  
        "kubernetes.default.svc.cluster.local" 
    ],  
    "key": {  
        "algo": "rsa",  
        "size": 2048  
    },  
    "names": [  
        {  
            "C": "CN",  
            "ST": "BeiJing",  
            "L": "BeiJing",  
            "O": "k8s",  
            "OU": "System"  
        }  
    ]  
} 

知識點：

•  這個證書目前專屬于 apiserver，加了一個 *.kubernetes.master域名以便內部私有 DNS 解析使用(可刪除)；至于很多人問過 kubernetes 這幾個能不能刪掉，答案是不可以的；因為當集群創建好后，default namespace 下會創建一個叫 kubenretes 的svc，有一些組件會直接連接這個 svc 來跟 api 通信的，證書如果不包含可能會出現無法連接的情況；其他幾個 kubernetes 開頭的域名作用相同
•  hosts包含的是授權范圍，不在此范圍的的節點或者服務使用此證書就會報證書不匹配錯誤。10.254.0.1是指kube-apiserver 指定的 service-cluster-ip-range 網段的第一個IP。

生成 Kubernetes 證書和私鑰 

$ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kubernetes-csr.json | cfssljson -bare kubernetes 

知識點：

•  -config 引用的是模板中的默認配置文件，
•  -profiles是指定特定的使用場景，比如config.json中的kubernetes區域

創建 admin 證書

創建 admin 證書請求文件admin-csr.json 

 {  
    "CN": "admin",  
    "hosts": [],  
    "key": {  
    "algo": "rsa",  
    "size": 2048  
    },  
    "names": [  
    {  
        "C": "CN",  
        "ST": "BeiJing",  
        "L": "BeiJing",  
        "O": "system:masters",  
        "OU": "System"  
    }  
    ]  
} 

生成 admin 證書和私鑰 

$ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes admin-csr.json | cfssljson -bare admin 

知識點: 這個admin 證書，是將來生成管理員用的kubeconfig 配置文件用的，現在我們一般建議使用RBAC 來對kubernetes 進行角色權限控制， kubernetes 將證書中的CN字段作為User， O 字段作為 Group。

同樣，我們也可以按照同樣的方式來創建 Kubernetes 中 etcd 集群的證書

創建 etcd 集群證書

    1.  證書簽署請求文件ca-csr.json 

{  
    "CN": "etcd CA",  
    "key": {  
        "algo": "rsa",  
        "size": 2048  
    },  
    "names": [  
        {  
            "C": "CN",  
            "L": "Beijing",  
            "ST": "Beijing"  
        }  
    ]  
} 

    2.  為節點創建服務證書請求文件，指定授權的主機節點etcd-server-csr.json 

{  
    "CN": "etcd",  
    "hosts": [  
        "10.1.20.129",  
        "10.1.20.126",  
        "10.1.20.128"  
        ],  
    "key": {  
        "algo": "rsa", 
        "size": 2048 
    },  
    "names": [  
        {  
            "C": "CN",  
            "L": "BeiJing",  
            "ST": "BeiJing"  
        }  
    ]  
} 

    3.  證書配置模板文件ca-config.json 

{  
  "signing": {  
    "default": {  
      "expiry": "87600h"  
    },  
    "profiles": {  
      "etcd": {  
         "expiry": "87600h",  
         "usages": [  
            "signing",  
            "key encipherment",  
            "server auth",  
            "client auth"  
        ]  
      }  
    }  
  }  
} 

    4.  生成 etcd 集群所需的證書與私鑰 

$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca -  
$ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=etcd etcd-server-csr.json | cfssljson -bare server 

這樣就完成 etcd 所需證書的申請，同時了解了 cfssl 工具的強大，寫到這里，本次的實驗就結束了。