安全機制
- 信息安全防護的目標
保密性 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 - 特性:
1、加密、解密使用同一個密鑰,效率高
2、將原始數據分割成固定大小的塊,逐個進行加密 - 缺陷:
1、密鑰過多
2、密鑰分發:密鑰在雙方的傳輸過程中容易被偷取
3、數據來源無法確認:無法確認數據是否是真正的發送方發送
非對稱加密算法
- 公鑰加密:密鑰是成對出現
公鑰:公開給所有人;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、 sha224、 sha256、 sha384、 sha512 - 常用工具和命令:
md5sum | sha1sum [ --check ] file :還有sha512sum等等
openssl、 gpg
rpm -V
數字簽名:將hash計算之後的結果摘要利用私鑰加密之後便被稱爲數字簽名。
-
利用對稱加密、非對稱加密,以及hash算法,分別取它們的優點長處,則可以實現最好的加密傳輸方式:
- 即解決了傳輸過程中的數據來源確認:利用非對稱加密中的私鑰加密原數據hash之後的摘要(也就是做成數字簽名),對方收到可用公鑰解密(此數字簽名)來判斷來源。
- 同時又解決了加密解密的時間長短問題:主要利用對稱加密來加密原數據以及數字簽名組合成的數據,然後傳輸它,減少解密時間。
- 並且又解決了密鑰的交換問題:因爲要利用對稱加密解決時間問題,因此對稱加密的密鑰需要雙方交換,則交換的時候爲了安全利用了非對稱加密的公鑰來加密此密鑰,並隨着2中加密後的數據一起傳輸過去,只有對方纔能解密此密鑰,因此便保證了此密鑰的安全。
- 比如a發送給b,則b最終收到了:key(data+Sa[hash(data)])+Pb(key)
其中key爲對稱加密的密鑰,S爲非對稱加密私鑰,P爲費對稱加密公鑰。a,b代表屬於a還是b。- 用接收方的非對稱加密公鑰加密後的對稱加密密鑰
- 用對稱加密密鑰加密的原數據和數字簽名的組合數據
(數字簽名可以利用發送方的非對稱加密公鑰解密得到原數據的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 )主要有以下兩種方式:
- 公鑰加密密鑰,然後私鑰解密密鑰,達到傳輸的效果(參考上面的過程)
- 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主機上解密
- 在hostA主機上生成公鑰/私鑰對
gpg --gen-key - 在hostA主機上查看公鑰
gpg --list-keys - 在hostA主機上導出公鑰到zhanga.pubkey
gpg -a --export -o zhanga.pubkey - 從hostA主機上覆制公鑰文件到需加密的B主機上
scp zhanga.pubkey hostB: - 在需加密數據的hostB主機上生成公鑰/私鑰對
gpg --list-keys
gpg --gen-key - 在hostB主機上導入公鑰
gpg --import zhanga.pubkey
gpg --list-keys - 在hostB上用導入的hostA的公鑰,加密hostB主機的文件file,生成file.gpg:注意加密的時候不要寫錯所用的公鑰了
gpg -e -r zhanga file
file file.gpg - 複製加密文件到hostA主機
scp fstab.gpg hostA: - 在hostA主機解密文件
gpg -d file.gpg
gpg -o file -d file.gpg - 刪除公鑰和私鑰(寫上對應的名字)
gpg --delete-keys zhanga
gpg --delete-secret-keys zhanga
- 在hostA主機上生成公鑰/私鑰對
注意點1:
- gen-key的時候要輸入
- 加密算法
- 過期時間
- 用戶姓名(至少5個字符)
- 郵箱
- 是否確認的信息
同時,輸入確認之後會提醒輸入口令對私鑰進行再次加密(防止被竊取,保證私鑰安全,也可以不輸入口令)注意遠程連接SSH時要unset DISPLAY命令才能顯示出來輸入密碼的界面,不然會報錯,詳情查看幫助說明
最後它會利用鼠標的隨機移動,硬件,鍵盤輸入的字符等來生成密鑰,有時會很慢(centos6中,7中不存在這個問題),可以在本機的圖形界面進行生成加快速度。
- 生成的公私鑰文件就在用戶的家目錄中的隱藏文件夾.gnupg中,公鑰爲punring.gpg ,私鑰爲 secring.gpg .
- 注意公鑰導入的時候兩臺機器的時間必須同步,不然會顯示沒有自簽名等錯誤。
- 想要刪除本機的公鑰必須先刪除本機對應的私鑰,當然刪除導入的公鑰的話沒有這個要求。
刪除了公鑰之後如果反悔會有一個備份文件以波浪符結尾的公鑰文件可供備份。
中間人***:公鑰來源確認(公鑰交換)造成
- 注意前面的這種key(data+Sa[hash(data)])+Pb(key) 方式也沒有解決公鑰交換的問題,無法確認公鑰是否真的是對方的公鑰。因此還需要用到下面證書的方法來進一步增加安全性。
CA和證書
- PKI:Public Key Infrastructure
簽證機構:CA(Certificate Authority)
註冊機構:RA
證書吊銷列表:CRL
證書存取庫: - X.509:定義了證書的結構以及認證協議標準
版本號
序列號
簽名算法
頒發者
有效期限
主體名稱
主體公鑰
CRL分發點
擴展信息
發行者簽名
證書獲取
- 證書類型:
證書授權機構的證書
服務器
用戶證書 - 獲取證書兩種方法:
- 使用證書授權機構
生成證書請求(csr文件)
將證書請求csr文件發送給CA
CA簽名頒發證書 - 自簽名的證書
自已簽發自己的公鑰
- 使用證書授權機構
注意點2:
-
證書申請方向證書頒發授權機構發送自己的信息以及公鑰,申請證書。證書頒發授權機構CA 利用自己的私鑰對證書申請方的各種信息進行加密並按照一定格式(參考上面所寫)頒發證書,包含着此證書頒發機構的簽名等。
- 然後證書申請人拿到證書之後便可以將它發送給需要交流通訊的其他目標方,這些目標方根據此證書的頒發機構的公鑰來解密此證書,便可以得到證書申請人的各種信息包括它的公鑰信息
- 同理這些目標方也可申請證書併發送給他人,這樣雙方就實現了自己的信息以及公鑰的交換,保證了公鑰交換過程的安全性。
- 通過這種第三方頒發證書的方式來解決了最後一個的公鑰交換的安全和來源確認問題。
-
而證書頒發機構不一定是一個。多個不同的證書頒發機構的證書申請方之間的相互通訊過程是這樣的:
- 比如說A由證書頒發機構CA1頒發證書,B由證書頒發機構CA2頒發證書。其中還有一個最上級的頂級證書頒發根機構CAroot
- 在1中我們假設了申請者都是在一個證書頒發機構內,都已擁有這個證書頒發機構的公鑰。而目前的實際情況中證書的申請者擁有的是根頒發機構CAroot的公鑰,而並不是直屬的頒發機構的公鑰。
- 這些直屬的頒發機構也會向根頒發機構申請證書(相當於申請頒發證書的權限),而根頒發機構也會像1中所寫對每一個下級證書頒發機構進行證書的頒發,裏面就包含了這些證書頒發機構的公鑰信息
- 因爲所有的申請者都有根頒發機構CAroot的公鑰,則他們就可以根據自己直屬的頒發機構的被根頒發機構頒發的證書來解密得到自己直屬的頒發機構的公鑰信息,也就相當於多了一級解密過程。
- 根據這種方式,這些申請者也就能得到不是自己直屬的頒發機構的其他頒發機構(需要通訊的對方的頒發機構)的證書,通過它來解出對方頒發機構的公鑰(此時相當於擁有了多個頒發機構的公鑰),然後再根據通訊對方的證書(這個證書是由對方頒發機構辦法的,不是由根頒發證書頒發的,別搞混了頒發機構的證書和通訊方的證書,一個是由根頒發機構頒發,一個是由通訊方直屬頒發機構頒發)利用這個公鑰解出來通訊對方的公鑰。
- 通過這種方式,即使通訊雙方交換了不同頒發機構頒發的證書(同時也必須相互交換了這些不同頒發機構從根CAroot中所獲得的證書),但也可得到對方頒發機構的公鑰(就是利用頒發機構的證書和全部通訊方都已知的根CAroot的公鑰解出),然後便可以將不同頒發機構的申請者之間的證書進行解密,從而得到了最終通訊方對方的公鑰。
- 這樣也就完成了通訊雙方公鑰的相互交換,然後便可進一步實行下一步的數據通信了。
- 注意2中的過程其實隱含了一個證書,就是根頒發機構CAroot自己給自己自簽名頒發的證書(因爲它就是頂級頒發機構,只能自己給自己頒發證書)。
- 根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工作過程:
過程:
- 當用戶訪問服務器的時候(服務器已經提前申請好了證書),服務器便會把自己的證書發送給客戶端。
- 客戶端利用這個證書以及可信任的這個第三方頒發證書的機構的公鑰(參考上面所寫的過程),解密出服務器的公鑰以及服務器的相關信息來進行驗證(比如證書有效期,證書的所屬的名字是否和服務器一致等等)
- 如果有效期等信息正確,然後客戶端會生成一個隨機數並利用解密出來的服務器的公鑰進行加密返回傳給服務器端。
- 服務器收到這個加密信息之後用自己的私鑰進行解密,解密得到這個隨機數,而這個隨機數便會當做雙方相互傳輸數據的密鑰(對稱加密)來進行數據傳輸。並且每隔一段時間更換一次此密鑰,這樣便實現了雙方的加密和認證通訊。
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解釋:
- base64只是一種編碼機制,類似ascii,它不是加密算法。 它是把常見的字符轉換爲64個對應字符。
- 它的目的就是把加密的結果(包含很多不可見字符等等,會是亂碼的格式)轉爲這64個可見的字符的形式來保存下來,這樣利於管理和查看保存。(當然不僅僅可用於加密,還可以用於其他)
- base64是把原始數據按照3個字節(24bit) 轉換爲4個字符(每個字符6bit,剛好是2^6=64個字符)的方式。
- 原始的數據是按照ascii的方式,每個字符佔8bit,包括許多不可打印字符等等,會亂碼
- 轉換後的數據按照每個字符佔6bit進行轉換爲64個可打印字符
- 如果原始的數據最後的部分不足以湊成3個字節(24bit),則將會以0來補位,而每一個補位的6bit的0在base64中將會以=來表示,它代表這些0並不是原始數據中的,而是補位補出來的。
- 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:
- centos6中可用grub-crypt 來生成$6的加密密碼用於其他地方,centos7中沒有可以直接生成密碼的命令了,只能grub2-setpasswd並把它放到文件裏去了。
- 利用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:
- 可以生成私鑰之後再修改權限,或者用小括號生成的時候直接修改也可
- 生成私鑰的時候 -out代表生成的文件 ,-des3 代表對私鑰文件再次進行一次加密並利用des3算法(也可其他算法,查看幫助) ,後面的數字代表私鑰的長度,默認512,注意這個必須是放在最後一個參數(1024,2048,4096)
2.2 如果創建的時候沒有加密,則可以再用openssl enc對其再次進行加密以保證私鑰的安全。 - 公鑰是在私鑰生成之後從私鑰中計算(提取)出來的,當然不能反過來提取。
隨機數生成器:僞隨機數字
鍵盤和鼠標,塊設備中斷
/dev/random:僅從熵池返回隨機數;隨機數用盡,阻塞(表現爲卡住,速度慢,可動動鼠標等繼續生成)
/dev/urandom:從熵池返回隨機數;隨機數用盡,會利用軟件生成僞隨機數,非阻塞
OpenSSL生成和頒發證書
- PKI:Public Key Infrastructure
CA
RA
CRL
證書存取庫 - 建立私有CA:
OpenCA
openssl - 證書申請及簽署步驟:
1、生成申請請求
2、 RA覈驗
3、 CA簽署
4、獲取證書
創建CA和申請證書
創建私有CA:
openssl的配置文件:/etc/pki/tls/openssl.cnf
三種策略:match匹配、 optional可選、 supplied提供
match:要求申請填寫的信息跟CA設置信息必須一致
optional:可有可無,跟CA設置信息可不一致
supplied:必須填寫這項申請信息
- 創建所需要的文件
touch /etc/pki/CA/index.txt 生成證書索引數據庫文件
echo 01 > /etc/pki/CA/serial 指定第一個頒發證書的序列號 - 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 查看指定編號的證書狀態
- 附加:查看證書中的信息:
- 頒發證書:在需要使用證書的主機生成證書請求
- 給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一致,這三項分別爲第1、2、4項在申請證書的需要填寫的信息(也可更改默認policy全部不需要匹配)
- 給web服務器生成私鑰:
- 吊銷證書
- 在客戶端獲取要吊銷的證書的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
- 在客戶端獲取要吊銷的證書的serial
注意點5:
- 第一步中的兩個文件必須要存在,且序列號必須要指定才能夠審覈頒發證書
- policy默認要匹配頒發證書時的第1/2/4項目,而第3567項沒要求。
- 注意要嚴格按照下面的名稱和位置目錄來生成和頒發證書。
- 當頒發一個新的證書的時候,index.txt文件中就會生成一個對應的表項來進行記錄,可用cat查看
- 同時,頒發一個新證書的時候,newcerts中會與certs中有相同的證書文件,只不過newcerts中是自動生成的證書文件,certs中是命令指定生成在此目錄下的證書。並且newcets中的證書文件是按照證書的序列號來命名的。
- 證書申請完畢之後便可以將證書拷貝給用戶以供服務和程序使用(以後再細說)
- 如果對一個證書申請文件csr再次頒發第二個證書,默認不允許會失敗(因爲兩個證書申請文件的subject也就是申請時填寫的信息完全一致,會被認爲有問題),不過如果修改了/etc/pki/CA/index.txt.attr文件中的unique_subject = yes 改爲no的話,這就可以對同一個證書申請文件多次頒發證書了。
- 在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