22.加密與安全相關,證書申請CA（gpg，openssl)

安全機制

• 信息安全防禦的目標
  保密性 Confidentiality
  完整性 Integrity
  可用性 Usability
  可控制性 Controlability
  不能否認性 Non-repudiation
• 安全防禦環節
  物理安全：各類設備/主機、機房環境
  系統安全：主機或設備的操做系統
  應用安全：各類網絡服務、應用程序
  網絡安全：對網絡訪問的控制、防火牆規則
  數據安全：信息的備份與恢復、加密解密
  管理安全：各類保障性的規範、流程、方法

安全***： STRIDE

Spoofing 假冒
Tampering 篡改
Repudiation 否定
Information Disclosure 信息泄漏
Denial of Service 拒絕服務
Elevation of Privilege 提高權限

• 其中拒絕服務是比較難以防止的，對方可使用高流量致使網絡癱瘓，以及IP更換等手段防止被禁。

安全設計基本原則

使用成熟的安全系統
以小人之心度輸入數據
外部系統是不安全的
最小受權
減小外部接口
缺省使用安全模式
安全不是似是而非
從STRIDE思考
在入口處檢查
從管理上保護好你的系統

安全算法

• 經常使用安全技術
  認證：密碼，生物指紋，虹膜等
  受權
  審計
  安全通訊
• 加密算法和協議
  對稱加密
  公鑰加密
  單向加密
  認證協議

對稱加密算法

• 對稱加密：加密和解密使用同一個密鑰
  DES：Data Encryption Standard，56bits
  3DES：
  AES：Advanced (128, 192, 256bits)
  Blowfish，Twofish
  IDEA，RC6，CAST5
• 特性：
  一、加密、解密使用同一個密鑰，效率高
  二、將原始數據分割成固定大小的塊，逐個進行加密
• 缺陷：
  一、密鑰過多
  二、密鑰分發：密鑰在雙方的傳輸過程當中容易被偷取
  三、數據來源沒法確認：沒法確認數據是不是真正的發送方發送

非對稱加密算法

• 公鑰加密：密鑰是成對出現
  公鑰：公開給全部人；public key
  私鑰：本身留存，必須保證其私密性；secret key
• 特色：用公鑰加密數據，只能使用與之配對的私鑰解密；反之亦然
• 功能：
  數字簽名：主要在於讓接收方確認發送方身份（利用發送方的私鑰加密部分數據，好比加密）
  對稱密鑰交換：發送方用對方的公鑰加密一個對稱密鑰後發送給對方
  數據加密：適合加密較小數據
• 缺點：密鑰長，加密解密效率低下
• 算法：
  RSA（既能夠加密，也可數字簽名）
  DSA（只能數字簽名）
  ELGamal

非對稱加密

• 基於一對公鑰/密鑰對
  用密鑰對中的一個加密，另外一個解密

• 實現加密：
  接收者
  生成公鑰/密鑰對：P和S
  公開公鑰P，保密密鑰S
  發送者
  使用接收者的公鑰來加密消息M
  將P(M)發送給接收者
  接收者
  使用密鑰S來解密：M=S(P(M))

• 實現數字簽名：
  發送者
  生成公鑰/密鑰對：P和S
  公開公鑰P，保密密鑰S
  使用密鑰S來加密消息M
  發送給接收者S(M)
  接收者
  使用發送者的公鑰來解密M=P(S(M))

單向散列（哈希算法）

• 將任意數據縮小成固定大小的「指紋」
  任意長度輸入
  固定長度輸出
  若修改數據，指紋也會改變（「不會產生衝突」）
  若數據同樣，則指紋也相同
  沒法從指紋中從新生成數據（「單向不可逆」）
• 功能：數據完整性，能夠把結果和與原數據看作是相互一一對應的映射
• 常見算法
  md5: 128bits、 sha1: 160bits、 sha22四、 sha25六、 sha38四、 sha512
• 經常使用工具和命令：
  md5sum | sha1sum [ --check ] file ：還有sha512sum等等
  openssl、 gpg
  rpm -V

數字簽名：將hash計算以後的結果摘要利用私鑰加密以後便被稱爲數字簽名。

• 利用對稱加密、非對稱加密，以及hash算法，分別取它們的優勢長處，則能夠實現最好的加密傳輸方式：

  1. 即解決了傳輸過程當中的數據來源確認：利用非對稱加密中的私鑰加密原數據hash以後的摘要（也就是作成數字簽名），對方收到可用公鑰解密（此數字簽名）來判斷來源。
  2. 同時又解決了加密解密的時間長短問題：主要利用對稱加密來加密原數據以及數字簽名組合成的數據，而後傳輸它，減小解密時間。
  3. 而且又解決了密鑰的交換問題：由於要利用對稱加密解決時間問題，所以對稱加密的密鑰須要雙方交換，則交換的時候爲了安全利用了非對稱加密的公鑰來加密此密鑰，並隨着2中加密後的數據一塊兒傳輸過去，只有對方纔能解密此密鑰，所以便保證了此密鑰的安全。
• 好比a發送給b,則b最終收到了：key(data+Sa[hash(data)])+Pb(key)
  其中key爲對稱加密的密鑰，S爲非對稱加密私鑰，P爲費對稱加密公鑰。a,b表明屬於a仍是b。
  1. 用接收方的非對稱加密公鑰加密後的對稱加密密鑰
  2. 用對稱加密密鑰加密的原數據和數字簽名的組合數據
     （數字簽名能夠利用發送方的非對稱加密公鑰解密獲得原數據的hash值，而後與原數據進行比較可知原數據是否被串改）
• https協議的服務就是用這種方式來實現數據加密的

示例應用程序：RPM

• 文件完整性的兩種實施方式
• 被安裝的文件
  MD5單向散列
  rpm --verify package_name (or -V)
• 發行的軟件包文件
  GPG公鑰簽名
  rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat* ：這個就是redhat公司包的公鑰，redhat公司的rpm包的hash值都被它提早進行了私鑰加密（數字簽名）並存於rpm包的數據庫中。而利用這公鑰（導入本機系統以後）即可以對包的數字簽名進行解密得出包的hash值，而後再與包自己計算得出的hash值進行比對來判斷此包是否被篡改。yum也是同理。
  rpm --checksig pakage_file_name (or -K)

密鑰交換：主要利用公鑰加密密鑰並進行交換，密鑰的生成可用DH算法；

密鑰交換：IKE（ Internet Key Exchange ）主要有如下兩種方式：

1. 公鑰加密密鑰，而後私鑰解密密鑰，達到傳輸的效果（參考上面的過程）
2. DH算法雙方計算出密鑰：
   DH (Deffie-Hellman)算法：生成會話密鑰，由惠特菲爾德·迪菲（BaileyWhitfield Diffie）和馬丁·赫爾曼（Martin Edward Hellman）在1976年發表
   參看：https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
   DH算法：
   A: g,p 協商生成公開的整數g, 大素數p
   B: g,p
   A:生成隱私數據 :a (a< p )，計算得出 g^a%p，並將計算結果發送給B
   B:生成隱私數據 :b,計算得出 g^b%p，並將計算結果發送給A
   A:計算得出 [(g^b%p)^a] %p = g^ab%p，生成爲密鑰
   B:計算得出 [(g^a%p)^b] %p = g^ab%p，生成爲密鑰

使用gpg實現對稱加密

• 對稱加密file文件
  gpg -c file ：注意須要輸入口令（密鑰）
  ls file.gpg
• 在另外一臺主機上解密file
  gpg -o file -d file.gpg ：解密要輸入和加密相同的口令（密鑰）

gpg實現非對稱加密

• 在hostB主機上用公鑰加密，在hostA主機上解密
  1. 在hostA主機上生成公鑰/私鑰對
     gpg --gen-key
  2. 在hostA主機上查看公鑰
     gpg --list-keys
  3. 在hostA主機上導出公鑰到zhanga.pubkey
     gpg -a --export -o zhanga.pubkey
  4. 從hostA主機上覆制公鑰文件到需加密的B主機上
     scp zhanga.pubkey hostB:
  5. 在需加密數據的hostB主機上生成公鑰/私鑰對
     gpg --list-keys
     gpg --gen-key
  6. 在hostB主機上導入公鑰
     gpg --import zhanga.pubkey
     gpg --list-keys
  7. 在hostB上用導入的hostA的公鑰，加密hostB主機的文件file,生成file.gpg：注意加密的時候不要寫錯所用的公鑰了
     gpg -e -r zhanga file
     file file.gpg
  8. 複製加密文件到hostA主機
     scp fstab.gpg hostA:
  9. 在hostA主機解密文件
     gpg -d file.gpg
     gpg -o file -d file.gpg
  10. 刪除公鑰和私鑰(寫上對應的名字)
      gpg --delete-keys zhanga
      gpg --delete-secret-keys zhanga

注意點1：

1. gen-key的時候要輸入
   • 加密算法
   • 過時時間
   • 用戶姓名（至少5個字符）
   • 郵箱
   • 是否確認的信息

同時，輸入確認以後會提醒輸入口令對私鑰進行再次加密（防止被竊取，保證私鑰安全，也能夠不輸入口令）注意遠程鏈接SSH時要unset DISPLAY命令才能顯示出來輸入密碼的界面，否則會報錯，詳情查看幫助說明
最後它會利用鼠標的隨機移動，硬件，鍵盤輸入的字符等來生成密鑰，有時會很慢（centos6中，7中不存在這個問題），能夠在本機的圖形界面進行生成加快速度。

2. 生成的公私鑰文件就在用戶的家目錄中的隱藏文件夾.gnupg中，公鑰爲punring.gpg ,私鑰爲 secring.gpg .
3. 注意公鑰導入的時候兩臺機器的時間必須同步，否則會顯示沒有自簽名等錯誤。
4. 想要刪除本機的公鑰必須先刪除本機對應的私鑰，固然刪除導入的公鑰的話沒有這個要求。
   刪除了公鑰以後若是反悔會有一個備份文件以波浪符結尾的公鑰文件可供備份。

中間人***：公鑰來源確認（公鑰交換）形成

• 注意前面的這種key(data+Sa[hash(data)])+Pb(key) 方式也沒有解決公鑰交換的問題，沒法確認公鑰是否真的是對方的公鑰。所以還須要用到下面證書的方法來進一步增長安全性。

CA和證書

• PKI：Public Key Infrastructure
  簽證機構：CA（Certificate Authority）
  註冊機構：RA
  證書吊銷列表：CRL
  證書存取庫：
• X.509：定義了證書的結構以及認證協議標準
  版本號
  序列號
  簽名算法
  頒發者
  有效期限
  主體名稱
  主體公鑰
  CRL分發點
  擴展信息
  發行者簽名

證書獲取

• 證書類型：
  證書受權機構的證書
  服務器
  用戶證書
• 獲取證書兩種方法：
  1. 使用證書受權機構
     生成證書請求（csr文件）
     將證書請求csr文件發送給CA
     CA簽名頒發證書
  2. 自簽名的證書
     自已簽發本身的公鑰

注意點2：

1. 證書申請方向證書頒發受權機構發送本身的信息以及公鑰，申請證書。證書頒發受權機構CA 利用本身的私鑰對證書申請方的各類信息進行加密並按照必定格式（參考上面所寫）頒發證書，包含着此證書頒發機構的簽名等。

   • 而後證書申請人拿到證書以後即可以將它發送給須要交流通信的其餘目標方，這些目標方根據此證書的頒發機構的公鑰來解密此證書，即可以獲得證書申請人的各類信息包括它的公鑰信息
   • 同理這些目標方也可申請證書併發送給他人，這樣雙方就實現了本身的信息以及公鑰的交換，保證了公鑰交換過程的安全性。
   • 經過這種第三方頒發證書的方式來解決了最後一個的公鑰交換的安全和來源確認問題。

2. 而證書頒發機構不必定是一個。多個不一樣的證書頒發機構的證書申請方之間的相互通信過程是這樣的：

   • 好比說A由證書頒發機構CA1頒發證書，B由證書頒發機構CA2頒發證書。其中還有一個最上級的頂級證書頒發根機構CAroot
   • 在1中咱們假設了申請者都是在一個證書頒發機構內，都已擁有這個證書頒發機構的公鑰。而目前的實際狀況中證書的申請者擁有的是根頒發機構CAroot的公鑰，而並非直屬的頒發機構的公鑰。
   • 這些直屬的頒發機構也會向根頒發機構申請證書（至關於申請頒發證書的權限），而根頒發機構也會像1中所寫對每個下級證書頒發機構進行證書的頒發，裏面就包含了這些證書頒發機構的公鑰信息
   • 由於全部的申請者都有根頒發機構CAroot的公鑰，則他們就能夠根據本身直屬的頒發機構的被根頒發機構頒發的證書來解密獲得本身直屬的頒發機構的公鑰信息，也就至關於多了一級解密過程。
   • 根據這種方式，這些申請者也就能獲得不是本身直屬的頒發機構的其餘頒發機構（須要通信的對方的頒發機構）的證書，經過它來解出對方頒發機構的公鑰（此時至關於擁有了多個頒發機構的公鑰），而後再根據通信對方的證書（這個證書是由對方頒發機構辦法的，不是由根頒發證書頒發的，別搞混了頒發機構的證書和通信方的證書，一個是由根頒發機構頒發，一個是由通信方直屬頒發機構頒發）利用這個公鑰解出來通信對方的公鑰。
   • 經過這種方式，即便通信雙方交換了不一樣頒發機構頒發的證書（同時也必須相互交換了這些不一樣頒發機構從根CAroot中所得到的證書），但也可獲得對方頒發機構的公鑰（就是利用頒發機構的證書和所有通信方都已知的根CAroot的公鑰解出),而後即可以將不一樣頒發機構的申請者之間的證書進行解密，從而獲得了最終通信方對方的公鑰。
   • 這樣也就完成了通信雙方公鑰的相互交換，而後即可進一步實行下一步的數據通訊了。
3. 注意2中的過程其實隱含了一個證書，就是根頒發機構CAroot本身給本身自簽名頒發的證書（由於它就是頂級頒發機構，只能本身給本身頒發證書）。
4. 根CAroot的公鑰則是全部的申請者在新裝機的時候內置的，至關於天生就知道這個公鑰。不過要注意根CAroot不止一個，有不少個，這些根CA的公鑰所有都會內置。
   • 根CAroot的子CA的證書是由根CA頒發的，而用戶的證書則是由這些子CA頒發的（也能夠子CA再分子子CA，就是上面的2過程當中每一個通信方再多拿一層頒發機構的證書而已，實際原理仍是那些）

安全協議

• SSL：Secure Socket Layer，TLS: Transport Layer Security（相同的算法，不一樣時期的名字）
  1995：SSL 2.0 Netscape
  1996：SSL 3.0
  1999：TLS 1.0
  2006：TLS 1.1 IETF(Internet工程任務組) RFC 4346
  2008：TLS 1.2 當前使用
  2015：TLS 1.3
  功能：機密性，認證，完整性，重放保護（是否被二次發送）
• 兩階段協議，分爲握手階段和應用階段
  握手階段(協商階段):客戶端和服務器端認證對方身份（依賴於PKI體系，利用數字證書進行身份認證），並協商通訊中使用的安全參數、密碼套件以及主密鑰。後續通訊使用的全部密鑰都是經過MasterSecret生成
  應用階段:在握手階段完成後進入，在應用階段通訊雙方使用握手階段協商好的密鑰進行安全通訊
• 注意SSL/TLS協議放在應用層報頭外面，對應用層的用戶數據進行加密以後再由傳輸層進行傳輸。這樣應用層的數據就沒法被其餘人看到了（即便被其餘人獲取也沒法看到裏面的內容）。

• Handshake協議：包括協商安全參數和密碼套件、服務器身份認證（客戶端身份認證可選）、密鑰交換
• ChangeCipherSpec 協議：一條消息代表握手協議已經完成
• Alert 協議：對握手協議中一些異常的錯誤提醒，分爲fatal和warning兩個級別，fatal類型錯誤會直接中斷SSL連接，而warning級別的錯誤SSL連接仍可繼續，只是會給出錯誤警告
• Record 協議：包括對消息的分段、壓縮、消息認證和完整性保護、加密等
• HTTPS 協議：就是「HTTP 協議」和「SSL/TLS 協議」的組合。 HTTP overSSL」 或「HTTP over TLS」，對http協議的文本數據進行加密處理後，成爲二進制形式傳輸

HTPTPS工做過程：

過程：

1. 當用戶訪問服務器的時候（服務器已經提早申請好了證書),服務器便會把本身的證書發送給客戶端。
2. 客戶端利用這個證書以及可信任的這個第三方頒發證書的機構的公鑰（參考上面所寫的過程），解密出服務器的公鑰以及服務器的相關信息來進行驗證（好比證書有效期，證書的所屬的名字是否和服務器一致等等）
3. 若是有效期等信息正確，而後客戶端會生成一個隨機數並利用解密出來的服務器的公鑰進行加密返回傳給服務器端。
4. 服務器收到這個加密信息以後用本身的私鑰進行解密，解密獲得這個隨機數，而這個隨機數便會當作雙方相互傳輸數據的密鑰（對稱加密）來進行數據傳輸。而且每隔一段時間更換一次此密鑰，這樣便實現了雙方的加密和認證通信。

OpenSSL

• OpenSSL：開源項目，用於實現SSL協議的軟件之一
  三個組件：
  openssl：多用途的命令行工具，包openssl
  libcrypto：加密算法庫，包openssl-libs
  libssl：加密模塊應用庫，實現了ssl及tls，包nss
• openssl命令：
  兩種運行模式：交互模式和批處理模式
  openssl version：程序版本號
  標準命令、消息摘要命令、加密命令
  標準命令：enc, ca, req, ...

openssl命令1

• 對稱加密：
  工具：openssl enc, gpg
  算法：3des, aes, blowfish, twofish

• enc命令：
  幫助：man enc
  加密（須要輸入口令（對稱密鑰））：
  openssl enc -e -des3 -a -salt -in testfile -out testfile.cipher
  解密：
  openssl enc -d -des3 -a -salt –in testfile.cipher -out testfile
  openssl ?

• 其中的：
  -a 表明基於base64方式進行加密
  -salt 會把加密結果進行打亂，即使相同的原數據只要鹽不一樣，加密後的結果也不一樣
  -e 表明加密
  -d 表明解密
  -in -out分別表明輸入輸出文件，-out也能夠用輸出重定向
  -des3 表明3DES的加密算法，其餘更多查看幫助

base64解釋：

1. base64只是一種編碼機制，相似ascii，它不是加密算法。 它是把常見的字符轉換爲64個對應字符。
2. 它的目的就是把加密的結果（包含不少不可見字符等等，會是亂碼的格式）轉爲這64個可見的字符的形式來保存下來，這樣利於管理和查看保存。（固然不只僅可用於加密，還能夠用於其餘）
3. base64是把原始數據按照3個字節（24bit) 轉換爲4個字符（每一個字符6bit，恰好是2^6=64個字符）的方式。
   • 原始的數據是按照ascii的方式，每一個字符佔8bit，包括許多不可打印字符等等，會亂碼
   • 轉換後的數據按照每一個字符佔6bit進行轉換爲64個可打印字符
   • 若是原始的數據最後的部分不足以湊成3個字節（24bit)，則將會以0來補位，而每個補位的6bit的0在base64中將會以=來表示，它表明這些0並非原始數據中的，而是補位補出來的。
4. linux中用base64命令便可進行轉換，base64 -d能夠進行反解碼，例如：

15:59[root@centos7 /data]# echo ab | base64
YWIK
15:59[root@centos7 /data]# echo -n ab | base64
YWI=
15:59[root@centos7 /data]# echo -n A | base64
QQ==
分析1：
ab : 01100001 01100010
補0並分紅6個bit一位： 011000 010110 001000 000000 ：即爲YWI=
分析2，由於含有\n這個符號，ascii中爲00001010
ab\n: 01100001 01100010 00001010
不用補0，直接分紅4個6bit字符：011000 010110 001000 001010 ：即爲YWIK

反解碼：
ab16:33[root@centos7 /boot/grub2]# echo -n YWI= |base64 -d
ab16:34[root@centos7 /boot/grub2]# echo -n YWIK |base64 -d
ab
16:34[root@centos7 /boot/grub2]#

openssl命令2

單向加密：

工具：md5sum, sha1sum, sha224sum,sha256sum…

16:09[root@centos7 /data]# sha512sum 11.t > 11.t.sha512
16:09[root@centos7 /data]# sha512sum -c 11.t.sha512
11.t: OK

openssl dgst（hash運算，需指定運算算法）

• dgst命令：
  幫助：man dgst
  openssl dgst -md5 [-hex默認] /PATH/SOMEFILE
  openssl dgst -md5 testfile
  md5sum /PATH/TO/SOMEFILE
  以上兩個命令結果相同，格式略有不一樣
• MAC: Message Authentication Code，單向加密的一種延伸應用，用於實現網絡通訊中保證所傳輸數據的完整性機制
• CBC-MAC
• HMAC：使用md5或sha1算法，已過期

生成用戶密碼：

passwd命令:
幫助：man sslpasswd
openssl passwd -1 -salt SALT(最多8位)
openssl passwd -1 –salt centos

• 其中-1表明md5 -salt後面可指定鹽，當鹽同樣的時候，輸入的密碼若是同樣則加密後的結果也會同樣（鹽不同則密碼同樣加密後的結果也不同）。

生成隨機數：

幫助：man sslrand
openssl rand -base64|-hex NUM
NUM: 表示字節數，使用-hex，每一個字符爲十六進制，至關於4位二進制，出現的字符數爲NUM*2
例子： openssl rand -base64 9 (只要是3的倍數就不會帶=號。可當作口令用)

注意點3：

1. centos6中可用grub-crypt 來生成$6的加密密碼用於其餘地方，centos7中沒有能夠直接生成密碼的命令了，只能grub2-setpasswd並把它放到文件裏去了。
2. 利用openssl rand -base64 3的倍數的方式生成隨機數當作密碼，而後再對其進行加密便可。

openssl生成公私鑰等命令

• 公鑰加密：
  算法：RSA, ELGamal
  工具：gpg, openssl rsautl（man rsautl）
• 數字簽名：
  算法：RSA, DSA, ELGamal
• 密鑰交換：
  算法：dh
  DSA：Digital Signature Algorithm
  DSS：Digital Signature Standard
  RSA：

生成

• 生成密鑰對兒：man genrsa
• 生成私鑰
  openssl genrsa -out /PATH/TO/PRIVATEKEY.FILE NUM_BITS
  例子：(umask 077; openssl genrsa –out test.key –des3 2048)
  其中小括號是在子進程中設置umask不影響當前shell,將生成的私鑰修改權限。
  openssl rsa -in test.key –out test2.key 將加密的key解密
• 從私鑰中提取出公鑰
  openssl rsa -in PRIVATEKEYFILE –pubout –out PUBLICKEYFILE
  例子：openssl rsa –in test.key –pubout –out test.key.pub

注意點4：

1. 能夠生成私鑰以後再修改權限，或者用小括號生成的時候直接修改也可
2. 生成私鑰的時候 -out表明生成的文件 ，-des3 表明對私鑰文件再次進行一次加密並利用des3算法（也可其餘算法，查看幫助） ，後面的數字表明私鑰的長度，默認512，注意這個必須是放在最後一個參數（1024,2048,4096）
   2.2 若是建立的時候沒有加密，則能夠再用openssl enc對其再次進行加密以保證私鑰的安全。
3. 公鑰是在私鑰生成以後從私鑰中計算（提取）出來的，固然不能反過來提取。

隨機數生成器：僞隨機數字

鍵盤和鼠標，塊設備中斷
/dev/random：僅從熵池返回隨機數；隨機數用盡，阻塞（表現爲卡住，速度慢，可動動鼠標等繼續生成）
/dev/urandom：從熵池返回隨機數；隨機數用盡，會利用軟件生成僞隨機數,非阻塞

OpenSSL生成和頒發證書

• PKI：Public Key Infrastructure
  CA
  RA
  CRL
  證書存取庫
• 創建私有CA:
  OpenCA
  openssl
• 證書申請及簽署步驟：
  一、生成申請請求
  二、 RA覈驗
  三、 CA簽署
  四、獲取證書

建立CA和申請證書

建立私有CA：
openssl的配置文件：/etc/pki/tls/openssl.cnf
三種策略：match匹配、 optional可選、 supplied提供
match：要求申請填寫的信息跟CA設置信息必須一致
optional：無關緊要，跟CA設置信息可不一致
supplied：必須填寫這項申請信息

1. 建立所須要的文件
   touch /etc/pki/CA/index.txt 生成證書索引數據庫文件
   echo 01 > /etc/pki/CA/serial 指定第一個頒發證書的序列號
2. CA自簽證書
   生成私鑰
   cd /etc/pki/CA/
   (umask 066; openssl genrsa -out private/cakey.pem 2048)
   生成自簽名證書
   openssl req -new -x509 -key /etc/pki/CA/private/cakey.pem -days 3650 -out /etc/pki/CA/cacert.pem
   選項說明：
   -new：生成新證書籤署請求
   -x509：專用於CA生成自簽證書
   -key：生成請求時用到的私鑰文件
   -days n：證書的有效期限
   -out /PATH/TO/SOMECERTFILE: 證書的保存路徑
   • 附加：查看證書中的信息：
     openssl x509 -in /PATH/FROM/CERT_FILE -noout -text|issuer|subject|serial|dates
     openssl ca -status SERIAL 查看指定編號的證書狀態
3. 頒發證書：在須要使用證書的主機生成證書請求
   • 給web服務器生成私鑰：
     (umask 066; openssl genrsa –out /data/test.key 2048)
     注意上一步生成的密鑰通常存放在須要證書的服務或者軟件目錄下（/data/app/)
   • 生成證書申請文件：
     openssl req -new -key /data/test.key -out /data/test.csr
   • 將證書請求文件傳輸給CA（scp到/tmp/test.csr）
   • CA審覈簽署證書，並將證書頒發給請求者（必需要存在第一步所寫的兩個文件，同時serial文件中還得有編號）
     openssl ca -in /tmp/test.csr –out /etc/pki/CA/certs/test.crt -days 100
   • 注意：默認要求 國家，省，公司名稱三項必須和CA一致,這三項分別爲第一、二、4項在申請證書的須要填寫的信息（也可更改默認policy所有不須要匹配）
4. 吊銷證書
   • 在客戶端獲取要吊銷的證書的serial
     openssl x509 -in /PATH/FROM/CERT_FILE -noout -serial -subject
   • 在CA上，根據客戶提交的serial與subject信息，對比檢驗是否與index.txt文件中的信息一致，
     而後吊銷證書：
     openssl ca -revoke /etc/pki/CA/newcerts/SERIAL.pem
   • 指定第一個吊銷證書的編號,注意：第一次更新證書吊銷列表前，才須要執行
     echo 01 > /etc/pki/CA/crlnumber
   • 更新證書吊銷列表
     openssl ca -gencrl -out /etc/pki/CA/crl.pem
   • 查看crl文件：
     openssl crl -in /etc/pki/CA/crl.pem -noout -text

注意點5：

1. 第一步中的兩個文件必需要存在，且序列號必需要指定纔可以審覈頒發證書
2. policy默認要匹配頒發證書時的第1/2/4項目，而第3567項沒要求。
3. 注意要嚴格按照下面的名稱和位置目錄來生成和頒發證書。
   • 當頒發一個新的證書的時候，index.txt文件中就會生成一個對應的表項來進行記錄，可用cat查看
   • 同時，頒發一個新證書的時候，newcerts中會與certs中有相同的證書文件，只不過newcerts中是自動生成的證書文件，certs中是命令指定生成在此目錄下的證書。而且newcets中的證書文件是按照證書的序列號來命名的。
4. 證書申請完畢以後即可以將證書拷貝給用戶以供服務和程序使用（之後再細說）
5. 若是對一個證書申請文件csr再次頒發第二個證書，默認不容許會失敗（由於兩個證書申請文件的subject也就是申請時填寫的信息徹底一致，會被認爲有問題），不過若是修改了/etc/pki/CA/index.txt.attr文件中的unique_subject = yes 改成no的話，這就能夠對同一個證書申請文件屢次頒發證書了。
6. 在CA上吊銷一個證書要利用的文件目錄是newcerts，而並不是是生成的時候命令中所寫的certs目錄中。
   • 同時吊銷了一個證書必需要放在吊銷列表中發佈公告，所以吊銷以前要生成這個吊銷列表的編號文件（相似生成證書的列表，須要注意的是，吊銷列表的編號和生成列表的證書的編號不須要對應關係。生成的證書的serial會在吊銷列表的每一項中的數據信息中，而不是在吊銷列表的serial編號中，因此它倆並沒有關聯）。注意只有第一次更新吊銷列表以前才須要執行
   • 生成了吊銷列表的編號文件，並吊銷了證書以後即可以更新吊銷列表了（它相似生成證書的數據庫文件index.txt和cert目錄中的證書文件的合體文件）,此時更新便不會報錯（若是沒有生成編號文件會報錯），而後即可以查看它了。具體參考上面的命令

參考下面的目錄和信息來建立CA和頒佈證書等：

[ ca ]
default_ca      = CA_default            # The default ca section

[ CA_default ]

dir             = /etc/pki/CA           # Where everything is kept
certs           = $dir/certs            # Where the issued certs are kept ：證書的文件存放位置
crl_dir         = $dir/crl              # Where the issued crl are kept :證書吊銷列表存放目錄
database        = $dir/index.txt        # database index file.  ：證書頒發的用戶（包括用戶名，有效期，狀態等）的列表數據庫
#unique_subject = no                    # Set to 'no' to allow creation of
                                        # several ctificates with same subject.
new_certs_dir   = $dir/newcerts         # default place for new certs. ：默認頒發的新的證書的位置

certificate     = $dir/cacert.pem       # The CA certificate ：CA本身的證書
serial          = $dir/serial           # The current serial number ：證書的編號，它表示下一個要頒發給用戶的證書的編號
crlnumber       = $dir/crlnumber        # the current crl number ：證書吊銷列表的編號
                                        # must be commented out to leave a V1 CRL
crl             = $dir/crl.pem          # The current CRL  ：證書吊銷列表生成的文件
private_key     = $dir/private/cakey.pem# The private key ：CA的私鑰
RANDFILE        = $dir/private/.rand    # private random number file ：隨機數文件

x509_extensions = usr_cert              # The extentions to add to the cert ：證書標準格式

default_days    = 365                   # how long to certify for ：默認證書有效期
default_crl_days= 30                    # how long before next CRL ：默認證書吊銷列表有效期
default_md      = sha256                # use SHA-256 by default ：默認加密算法
preserve        = no                    # keep passed DN ordering

policy          = policy_match 
：它定義了用戶申請證書的時候，所要填寫的信息中，哪些與CA自身的證書的項目必須一致，纔會給此申請者頒發證書。不然不頒發（有點相似生活中不一樣地區的戶籍管理必須找當地的政府派出所等，不能去其它地方的管理部門）
：下面的每項均可本身定義更改，同時上面的policy也可在不一樣狀況下分別更換不一樣的policy。
# For the CA policy
[ policy_match ]
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ policy_anything ]
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional