pem格式證書怎么獲得(pem格式文件怎么打開)
1. pem格式文件怎么打開
目前支持SSL證書文件(.crt文件)、SSL證書.key文件、SSL證書鏈文件(.pem文件，CA公布在其網(wǎng)站上).
2. 什么是pem格式
pfx是公鑰加密技術(shù)12號(hào)標(biāo)準(zhǔn)（Public Key Cryptography Standards #12，PKCS#12）為存儲(chǔ)和傳輸用戶或服務(wù)器私鑰、公鑰和證書指定了一個(gè)可移植的格式。它是一種二進(jìn)制格式，這些文件也稱為PFX文件。開發(fā)人員通常需要將PFX文件轉(zhuǎn)換為某些不同的格式，如PEM或JKS，以便可以為使用SSL通信的獨(dú)立Java客戶端或WebLogic Server使用
是一種Microsoft協(xié)議，使用戶可以將機(jī)密信息從一個(gè)環(huán)境或平臺(tái)傳輸?shù)搅硪粋€(gè)環(huán)境或平臺(tái)。使用該協(xié)議，用戶就可以安全地將個(gè)人信息從一個(gè)計(jì)算機(jī)系統(tǒng)導(dǎo)出到另一個(gè)系統(tǒng)中。
3. pem編碼的證書正文
CRL（證書吊銷列表）是一種包含被吊銷數(shù)字證書信息的文件。它用于驗(yàn)證數(shù)字證書的有效性，并幫助保護(hù)網(wǎng)絡(luò)通信的安全。
當(dāng)數(shù)字證書的私鑰遺失、過期、被盜或者證書持有者不再信任時(shí)，可以通過頒發(fā)吊銷證書來撤銷證書的有效性。被吊銷的數(shù)字證書將被列入CRL中，以通知其他系統(tǒng)不再信任該證書。
CRL文件中包含了被吊銷的數(shù)字證書的信息，如證書序列號(hào)、吊銷日期和原因等。使用CRL文件，客戶端可以檢查和驗(yàn)證本地保存的數(shù)字證書是否在吊銷列表中，從而確定證書的有效性。
CRL文件通常由證書頒發(fā)機(jī)構(gòu)（CA）定期發(fā)布，客戶端可以下載最新的CRL文件以保持?jǐn)?shù)字證書的驗(yàn)證和有效性。為了提高效率，CRL文件通常采用基于X.509標(biāo)準(zhǔn)的格式，如DER（二進(jìn)制DER編碼）或PEM（Base64編碼）。
總結(jié)而言，CRL文件是一種包含被吊銷數(shù)字證書信息的文件，用于驗(yàn)證和保護(hù)網(wǎng)絡(luò)通信的安全。它幫助客戶端檢查和確定數(shù)字證書的有效性，以減少惡意或無效證書的風(fēng)險(xiǎn)。
4. pem證書格式說明
可以使用open ssl提供的工具按需要生成
5. pem證書怎么打開
apache 是JKS 體系iis 是 windows的 一般應(yīng)該 是 pkcs12nginx 可能是 openssl 或 pemother 估計(jì)是 pem?？春缶Y名是看不出的。要用ultraedit之類的，文本/hex 編輯器打開看。pkcs12 是 data hex文件jks 也是 data hex文件，用 jre\bin\keytool.exe 可以操作openssl pem 是文本intermediate 就是中級(jí)證書機(jī)構(gòu)root是根，域名就是你的服務(wù)器證書。服務(wù)器證書如果是文本格式的，至少要有2段。------------分割有短 private key----- 的就是私鑰，另外段是服務(wù)器證書。亂扯了一大段，最后還是建議你按別人的傻瓜教程一步步跟著做。PKI （Public Key Infrastructure）幾篇文章才能入門，這里寫不完的。
6. pem格式證書提取公鑰
這就要求參加電子商務(wù)的買方和賣方都必須擁有合法的身份，并且在網(wǎng)上能夠有效無誤的被進(jìn)行驗(yàn)證。數(shù)字證書是一種權(quán)威性的電子文檔。它提供了一種在Internet上驗(yàn)證您身份的方式，其作用類似于司機(jī)的駕駛執(zhí)照或日常生活中的身份證。它是由一個(gè)由權(quán)威機(jī)構(gòu)----CA證書授權(quán)(Certificate Authority)中心發(fā)行的，人們可以在互聯(lián)網(wǎng)交往中用它來識(shí)別對(duì)方的身份。當(dāng)然在數(shù)字證書認(rèn)證的過程中，證書認(rèn)證中心（CA）作為權(quán)威的、公正的、可信賴的第三方，其作用是至關(guān)重要的。 數(shù)字證書也必須具有唯一性和可靠性。為了達(dá)到這一目的，需要采用很多技術(shù)來實(shí)現(xiàn)。通常，數(shù)字證書采用公鑰體制，即利用一對(duì)互相匹配的密鑰進(jìn)行加密、解密。每個(gè)用戶自己設(shè)定一把特定的僅為本人所有的私有密鑰（私鑰），用它進(jìn)行解密和簽名；同時(shí)設(shè)定一把公共密鑰（公鑰）并由本人公開，為一組用戶所共享，用于加密和驗(yàn)證簽名。當(dāng)發(fā)送一份保密文件時(shí)，發(fā)送方使用接收方的公鑰對(duì)數(shù)據(jù)加密，而接收方則使用自己的私鑰解密，這樣信息就可以安全無誤地到達(dá)目的地了。通過數(shù)字的手段保證加密過程是一個(gè)不可逆過程，即只有用私有密鑰才能解密。公開密鑰技術(shù)解決了密鑰發(fā)布的管理問題，用戶可以公開其公開密鑰，而保留其私有密鑰。 一個(gè)數(shù)字證書的內(nèi)容一般包括： 所有者的公鑰 所有者的名字 公鑰的失效期 發(fā)放機(jī)構(gòu)的名稱（發(fā)放數(shù)字證書的 CA） 數(shù)字證書的序列號(hào) 發(fā)放機(jī)構(gòu)的數(shù)字簽名 被廣泛接受的數(shù)字證書格式由 CCITT X.509 國(guó)際標(biāo)準(zhǔn)定義；因此任何符合 X.509 的應(yīng)用程序都可讀寫證書。在 PKCS 標(biāo)準(zhǔn)和 PEM 標(biāo)準(zhǔn)中有更進(jìn)一步的明確表達(dá)。 數(shù)字證書頒發(fā)過程一般為：用戶首先產(chǎn)生自己的密鑰對(duì)，并將公共密鑰及部分個(gè)人身份信息傳送給認(rèn)證中心。認(rèn)證中心在核實(shí)身份后，將執(zhí)行一些必要的步驟，以確信請(qǐng)求確實(shí)由用戶發(fā)送而來，然后，認(rèn)證中心將發(fā)給用戶一個(gè)數(shù)字證書，該證書內(nèi)包含用戶的個(gè)人信息和他的公鑰信息，同時(shí)還附有認(rèn)證中心的簽名信息。用戶就可以使用自己的數(shù)字證書進(jìn)行相關(guān)的各種活動(dòng)。數(shù)字證書由獨(dú)立的證書發(fā)行機(jī)構(gòu)發(fā)布。數(shù)字證書各不相同，每種證書可提供不同級(jí)別的可信度。可以從證書發(fā)行機(jī)構(gòu)獲得您自己的數(shù)字證書。 目前的數(shù)字證書類型主要包括：個(gè)人數(shù)字證書、單位數(shù)字證書、單位員工數(shù)字證書、服務(wù)器證書、VPN證書、WAP證書、代碼簽名證書和表單簽名證書。作用用來在網(wǎng)絡(luò)通訊中識(shí)別通訊各方的身份，并保證網(wǎng)絡(luò)安全的四大要素保密性完整性真實(shí)性不可否定性
7. pem證書格式轉(zhuǎn)換
HTTPS證書安裝步驟如下：
獲取證書文件，如果是證書系統(tǒng)創(chuàng)建的CSR，還包含：證書私鑰文件、證書公鑰文件、證書鏈文件。
在服務(wù)器上創(chuàng)建cert目錄，將下載的全部文件拷貝到cert目錄中。
根據(jù)證書類型，選擇不同的安裝方式：
如果是單域名證書，將證書文件（214852718690540.pem）和私鑰文件（214852718690540.key）拷貝到目錄中，然后重啟服務(wù)器。
如果是多域名證書，將證書文件（214852718690540.pem）和私鑰文件（214852718690540.key）以及證書鏈文件（chain.pem）拷貝到目錄中，然后重啟服務(wù)器。
配置Nginx服務(wù)器，在配置文件中添加以下內(nèi)容：
listen 443 ssl http2;ssl_certificate /path/to/cert/file; #證書文件路徑ssl_certificate_key /path/to/key/file; #私鑰文件路徑ssl_session_timeout 1d;ssl_session_cache shared:SSL:50m;ssl_dhparam /path/to/dhparam.pem; #DH參數(shù)文件路徑ssl_stapling on; #開啟STAPLINGssl_stapling_verify on; #開啟STAPLING驗(yàn)證
保存配置文件并重啟Nginx服務(wù)器。
8. pem格式證書下載
AC證書是指無線接入控制器（AC）的數(shù)字證書，用于保證AC與接入的無線設(shè)備之間的安全通信。安裝AC證書的具體步驟如下：
下載證書文件：從證書頒發(fā)機(jī)構(gòu)或者AC廠商處獲取證書文件，通常是以.pem或.crt為后綴的文件。
登錄AC：使用管理員賬號(hào)登錄AC的Web管理界面。
導(dǎo)入證書：在Web管理界面中找到“系統(tǒng)管理”或“安全設(shè)置”等相關(guān)選項(xiàng)，選擇“證書管理”或“SSL證書”等選項(xiàng)，然后點(diǎn)擊“導(dǎo)入證書”按鈕。
選擇證書文件：在彈出的對(duì)話框中選擇要導(dǎo)入的證書文件，并輸入證書密碼（如果有）。
配置證書：導(dǎo)入證書后，需要配置證書的相關(guān)參數(shù)，如證書名稱、證書類型、證書鏈等。具體配置方法可以參考AC的使用說明書或者廠商提供的技術(shù)支持文檔。
保存配置：完成證書配置后，點(diǎn)擊“保存”或“應(yīng)用”按鈕，使配置生效。
測(cè)試連接：重新啟動(dòng)AC，并測(cè)試連接AC的無線設(shè)備是否能夠正常通信。如果連接成功，則表示AC證書安裝成功。
9. pem證書在線生成
讓網(wǎng)站永久擁有HTTPS - 申請(qǐng)免費(fèi)SSL證書并自動(dòng)續(xù)期 Let’s Encrypt
為什么要用HTTPS??網(wǎng)站沒有使用HTTPS的時(shí)候，瀏覽器一般會(huì)報(bào)不安全，而且在別人訪問這個(gè)網(wǎng)站的時(shí)候，很有可能會(huì)被運(yùn)營(yíng)商劫持，然后在網(wǎng)站里顯示一些莫名其妙的廣告。
??有HTTPS的時(shí)候，通俗地講所有的數(shù)據(jù)傳輸都會(huì)被加密，你和網(wǎng)站之間的數(shù)據(jù)交流也就更加安全。
相關(guān)簡(jiǎn)介L(zhǎng)et’s Encrypt??如果要啟用HTTPS，我們就需要從證書授權(quán)機(jī)構(gòu)處獲取一個(gè)證書，Let’s Encrypt 就是一個(gè)證書授權(quán)機(jī)構(gòu)。我們可以從 Let’s Encrypt 獲得網(wǎng)站域名的免費(fèi)的證書。
Certbot??Certbot是Let’s Encrypt推出的獲取證書的客戶端，可以讓我們免費(fèi)快速地獲取Let’s Encrypt證書。
便宜SSL??便宜SSL是一家國(guó)內(nèi)的SSL證書提供商，同樣也擁有免費(fèi)證書。而且提供豐富的工具: https://www.pianyissl.com/tools。
獲取HTTPS證書??獲取SSL證書的過程大體上都一樣。既可以圖形化，也可以命令行，最后實(shí)現(xiàn)的效果都完全一樣，大家各取所需。
命令行安裝Certbot??進(jìn)入Certbot的官網(wǎng)，選擇你所使用的軟件和系統(tǒng)環(huán)境，然后就會(huì)跳轉(zhuǎn)到對(duì)應(yīng)版本的安裝方法，以Ubuntu + Nginx為例。
sudo apt-get updatesudo apt-get install software-properties-commonsudo add-apt-repository ppa:certbot/certbotsudo apt-get updatesudo apt-get install certbot申請(qǐng)證書??安裝完成后執(zhí)行：
certbot certonly --webroot -w /var/www/example -d example.com -d www.example.com??這條命令的意思是為以/var/www/example為根目錄的兩個(gè)域名example.com和www.example.com申請(qǐng)證書。
??如果你的網(wǎng)站沒有根目錄或者是你不知道你的網(wǎng)站根目錄在哪里，可以通過下面的語句來實(shí)現(xiàn)：
certbot certonly --standalone -d example.com -d www.example.com??使用這個(gè)語句時(shí)Certbot會(huì)自動(dòng)啟用網(wǎng)站的443端口來進(jìn)行驗(yàn)證，如果你有某些服務(wù)占用了443端口，就必須先停止這些服務(wù)，然后再用這種方式申請(qǐng)證書。
??證書申請(qǐng)完之后，Certbot會(huì)告訴你證書所在的目錄，一般來說會(huì)在/etc/letsencrypt/live/這個(gè)目錄下。
圖形化??進(jìn)入便宜SSL的官網(wǎng)https://www.pianyissl.com，注冊(cè)了賬號(hào)之后，選擇那個(gè)體驗(yàn)版的免費(fèi)測(cè)試，然后點(diǎn)確認(rèn)購(gòu)買。
??輸入域名并點(diǎn)擊生成CSR并提交申請(qǐng)按鈕。
??點(diǎn)擊確定按鈕。
??接下來會(huì)選擇驗(yàn)證方式。
??這里我選擇郵箱驗(yàn)證方式，其它另外兩種依照你的個(gè)人情況而定，反正就是為了驗(yàn)證域名是不是你的而已。
??大約過幾分鐘，郵箱會(huì)收到一封驗(yàn)證郵件，如下圖，復(fù)制②指向的一串驗(yàn)證碼，點(diǎn)擊①處的Here鏈接。
??輸入驗(yàn)證碼，點(diǎn)擊Next>按鈕。
??提示已經(jīng)輸入正確的驗(yàn)證碼，點(diǎn)擊Close Window。
??大約等到10分鐘左右，再次登陸 https://www.pianyissl.com，進(jìn)入個(gè)人中心，可以看到已經(jīng)成功申請(qǐng)SSL證書，點(diǎn)擊查看詳情。
??此時(shí)你可以點(diǎn)擊箭頭所指的證書打包下載，然后免費(fèi)的SSL證書就可以下載到本地了，下載后可以看到SSL壓縮包內(nèi)的文件。
部署HTTPS證書??找到網(wǎng)站的Nginx配置文件，找到listen 80;，修改為listen 443;在這一行的下面添加以下內(nèi)容：
ssl on;ssl_certificate XXX/fullchain.pem; 修改為fullchain.pem所在的路徑ssl_certificate_key XXX/privkey.pem; 修改為privkey.pem所在的路徑ssl_session_timeout 5m;ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;ssl_protocols TLSv1 TLSv1.1 TLSv1.2;ssl_prefer_server_ciphers on;??保存退出后，通過nginx -t來檢查配置文件是否正確，有錯(cuò)誤的話改之即可。配置文件檢測(cè)正確之后，通過nginx -s reload來重載配置文件。
??然后通過訪問https://example.com來查看是否配置成功。
??如果發(fā)現(xiàn)無法訪問或者是加載不出來的話檢查一下443端口有沒有開啟！
設(shè)置HTTP強(qiáng)制跳轉(zhuǎn)HTTPS??上一步成功之后大家可能會(huì)發(fā)現(xiàn)通過原來的http://example.com無法訪問網(wǎng)頁了，因?yàn)镠TTP默認(rèn)走的是80端口，我們剛才將其修改為443端口了。在這里我們可以在配置文件的最后一行加入以下代碼：
server {listen 80;server_name example.com; 這里修改為網(wǎng)站域名rewrite ^(.*)$ https://$host$1 permanent;}意思是每一個(gè)通過80端口訪問的請(qǐng)求都會(huì)強(qiáng)制跳轉(zhuǎn)到443端口，這樣一來訪問http://example.com的時(shí)候就會(huì)自動(dòng)跳轉(zhuǎn)到https://example.com了。
命令行下設(shè)置證書自動(dòng)續(xù)期??有心的小伙伴可能會(huì)留意到我們剛才申請(qǐng)的整數(shù)的有效期只有90天，不是很長(zhǎng)，可是我們可以通過Linux自帶的cron來實(shí)現(xiàn)自動(dòng)續(xù)期，這樣就相當(dāng)于永久了。
??隨便找一個(gè)目錄，新建一個(gè)文件，名字隨便起，在這里以example為例，在里面寫入0 */12 * * * certbot renew --quiet --renew-hook "/etc/init.d/nginx reload"，保存。
??然后在控制臺(tái)里執(zhí)行crontab example一切都OK了。原理是example里存入了一個(gè)每天檢查更新兩次的命令，這個(gè)命令會(huì)自動(dòng)續(xù)期服務(wù)器里存在的來自Certbot的SSL證書。然后把example里存在的命令導(dǎo)入進(jìn)Certbot的定時(shí)程序里。
附：其它環(huán)境下的證書部署??https://www.pianyissl.com/support/
Nginx相關(guān)命令nginx -t 驗(yàn)證配置是否正確nginx -v 查看Nginx的版本號(hào)service nginx start 啟動(dòng)Nginxnginx -s stop 快速停止或關(guān)閉Nginxnginx -s quit 正常停止或關(guān)閉Nginxnginx -s reload 重新載入配置文件crontab相關(guān)命令cat /var/log/cron 查看crontab日志crontab -l 查看crontab列表crontab -e 編輯crontab列表systemctl status crond.service 查看crontab服務(wù)狀態(tài)systemctl restart crond.service 重啟crontab參考文檔https://lucien.ink/archives/81/https://www.cnblogs.com/zoro-zero/p/6590503.htmlhttp://blog.csdn.net/gsls200808/article/details/53486078https://certbot.eff.org/#ubuntuxenial-otherhttp://nginx.org/en/docs/http/configuring_https_servers.html
https://www.cnblogs.com/zdz8207/p/10729294.html
10. pem文件格式
以Nginx對(duì)OpenSSL的使用為入口，來分析OpenSSL的API的模型。OpenSSL是兩個(gè)庫(kù)，如果以握手為目的只會(huì)使用libssl.so這個(gè)庫(kù)，但是如果有加密的需求，會(huì)使用libcrypto.so這個(gè)庫(kù)。Nginx中對(duì)于OpenSSL的使用大部分是直接使用的libssl.so的接口API的，但是仍然會(huì)有少部分使用libcrypto.so。除了Nginx，本章還會(huì)分析一個(gè)s_server程序，通過這個(gè)程序的設(shè)計(jì)，能夠?qū)penSSL的內(nèi)部架構(gòu)有一個(gè)初探。
Nginx的Stream中SSL的實(shí)現(xiàn)
Nginx的Stream Proxy中有對(duì)于SSL的Terminator的支持。這個(gè)終端的意思是可以在Nginx層面把SSL解掉，然后把明文傳輸給后端。也就是說支持SSL的Nginx的Stream模塊實(shí)際上是一個(gè)TLS的握手代理，將TLS信道在本地解了再發(fā)送到后端，所以整個(gè)過程是一個(gè)純粹的握手過程，至于ALPN這種功能就需要后端與TLS的配合才可以，所以這種行為在stream 的SSL中是不能支持的。
這是一個(gè)Nginx的Stream SSL模塊相關(guān)的函數(shù)列表，主要的Stream模塊特有的功能也都就在這個(gè)列表里了。可以看到除去配置和模塊的整體初始化函數(shù)，只剩下一個(gè)連接初始化，ssl的入口handler和握手的handler。顯然握手的handler是入口handler的深入部分。鑒于Nginx的異步模型，可以很容易的想到是Nginx在收到一個(gè)連接的時(shí)候首先使用ssl_handler作為通用入口，在確定是SSL連接之后就會(huì)切換到handshaker_handler作為后續(xù)的握手handler函數(shù)。
但是Nginx在支持SSL的時(shí)候并不是這樣的輕松，因?yàn)榇罅康腟SL相關(guān)函數(shù)在ngx_event_openssl.c文件里，這個(gè)文件里的函數(shù)被HTTP模塊和Stream模塊或者其他需要SSL支持的模塊共同使用。包括Session Cache等Nginx重新實(shí)現(xiàn)的OpenSSL功能。通過這個(gè)例子可以看到如果要自己實(shí)現(xiàn)一個(gè)SSL支持，我們需要兩個(gè)東西，一個(gè)是SSL的用戶端的接口封裝庫(kù)（ngx_event_openssl.c），一個(gè)是如何把封裝庫(kù)的邏輯嵌入到我們的代碼流程的邏輯。Nginx作為一個(gè)強(qiáng)大的負(fù)載均衡設(shè)備，這一部分的接口嵌入應(yīng)該是要追求的最小化實(shí)現(xiàn)的。也就是說Stream模塊相關(guān)的代碼越少越好（ngx_stream_ssl_module.c）。所以我們可以看到幾乎就幾個(gè)鉤子函數(shù)的定義。
無論是Stream還是HTTP模式，整個(gè)TLS握手的核心函數(shù)都是ngx_ssl_handshake函數(shù)。我們看這個(gè)函數(shù)就能看到一個(gè)企業(yè)級(jí)的握手接口的使用案例。以下是一個(gè)簡(jiǎn)化版的函數(shù)流程：
以上是一個(gè)同步版本的大體邏輯，異步版本的就沒有顯示?？梢钥吹街饕腟SL握手的入口函數(shù)是SSL_do_handshake。如果握手正常，函數(shù)返回1之后，使用SSL_get_current_cipher或得到服務(wù)器根據(jù)客戶端發(fā)來的密碼學(xué)參數(shù)的列表選擇得到的密碼學(xué)套件。這里會(huì)返回服務(wù)器選擇的那個(gè)，如果返回為空，那么就代表了服務(wù)器沒有找到匹配的套件，連接就不能繼續(xù)。SSL_CIPHER_description函數(shù)輸入活的指針，返回一個(gè)字符串格式的套件的描述信息，Nginx這里使用了這個(gè)信息，最后一步就是查找當(dāng)前的Session Cache中是否有可以復(fù)用的邏輯。這里只是一個(gè)查詢，并不是就是復(fù)用的決定。因?yàn)槭欠駨?fù)用是在連接建立之前由配置決定的，如果Nginx配置了不使用OpenSSL的Session Cache，這個(gè)查詢就會(huì)一直返回0，表示沒有被復(fù)用。而且這里查詢的OpenSSL中是否有復(fù)用，并不代表Nginx內(nèi)部是否有復(fù)用，Nginx內(nèi)部還有一套自己的Session Cache實(shí)現(xiàn)，但是使用SSL_開頭的API函數(shù)都是OpenSSL的接口。
這個(gè)簡(jiǎn)單的接口可以看出對(duì)OpenSSL的API的使用的一些端倪。OpenSSL提供的API非常多，我們寫一個(gè)簡(jiǎn)單的示例程序僅僅會(huì)用到幾個(gè)最簡(jiǎn)單的接口，例如SSL_new等。但是一個(gè)正式的項(xiàng)目，會(huì)用到很多細(xì)節(jié)的API接口。由于OpenSSL只會(huì)暴露他認(rèn)為應(yīng)該暴露的API函數(shù)出來給調(diào)用者使用，其他的函數(shù)調(diào)用者是用不到的，并且OpenSSL內(nèi)部的結(jié)構(gòu)體外部也是不能使用的，所以使用者所有的行為都是要基于API進(jìn)行設(shè)計(jì)。
OpenSSL分為libcrypto.so和libssl.so兩個(gè)庫(kù)。在使用TLS握手的時(shí)候，主要的調(diào)用API都位于ssl.h文件中定義，都是SSL_開頭的API。但是這并不意味著只能調(diào)用libssl.so的接口，高級(jí)的用戶并不是想要使用OpenSSL的TLS握手功能，完全可以直接調(diào)用libcrypto.so里面的各種各樣的密碼學(xué)庫(kù)?？偟膩碚flibssl.so是一個(gè)TLS握手庫(kù)，而libcrypto.so是一個(gè)通用的密碼學(xué)的庫(kù)。只是libssl.so的握手使用的密碼學(xué)是完全依賴libcryto.so中提供的。也就是因此，在使用TLS握手的時(shí)候，是基本上不會(huì)直接用到libcrypto.so中的API的。
s_server
openssl s_server是一個(gè)簡(jiǎn)單的SSL服務(wù)器，雖然說是簡(jiǎn)單，但是其中包含了大部分用戶SSL編程需要考慮的東西。證書，密碼，過期校驗(yàn)，密碼學(xué)參數(shù)定制，隨機(jī)數(shù)定制等等。這是一個(gè)功能性的程序，用于驗(yàn)證openssl內(nèi)部的各項(xiàng)SSL握手服務(wù)器的功能是否能夠正常使用，并不能用于直接服務(wù)于線上業(yè)務(wù)。
s_server程序啟動(dòng)的第一步是解析各種參數(shù)，在正常運(yùn)作的時(shí)候，第一步是加載key。
我們看到OpenSSL內(nèi)部調(diào)用的函數(shù)和在使用OpenSSL庫(kù)接口的時(shí)候是不一樣的，OpenSSL的子程序會(huì)調(diào)用一些內(nèi)部的接口。比如這里使用了ENGINE_init，直接初始化了底層的引擎系統(tǒng)。ENGINE系統(tǒng)是OpenSSL為了適配下層不同的數(shù)據(jù)引擎設(shè)計(jì)的封裝層。有對(duì)應(yīng)的一系列API，所有的ENGINE子系統(tǒng)的API都是ENGINE_開頭的。一個(gè)引擎代表了一種數(shù)據(jù)計(jì)算方式，比如內(nèi)核的密碼學(xué)套件可以有一個(gè)專門的OpenSSL引擎調(diào)用到內(nèi)核的密碼學(xué)代碼，QAT硬件加速卡也會(huì)有一個(gè)專門的引擎，OpenSSL自己的例如RSA等加密算法的實(shí)現(xiàn)本身也是一個(gè)引擎。這里在加載key的時(shí)候直接初始化一個(gè)引擎，這個(gè)引擎在init之前還要先調(diào)用一個(gè)setup_engine函數(shù)，這個(gè)函數(shù)能夠設(shè)置這個(gè)將要被初始化的引擎的樣子。s_server之所以要自己用引擎的API接口是因?yàn)樗С謴拿钚休斎胍娴膮?shù)，指定使用的引擎。
可以看到，如果指定了auto，就會(huì)加載所有默認(rèn)的引擎。如果指定了特定ID的引擎，就只會(huì)加載特定的引擎。一個(gè)引擎下面是所有相關(guān)的密碼學(xué)的實(shí)現(xiàn)，加載key就是一個(gè)密碼學(xué)層面的操作，所以也要使用ENGINE提供的接口。事實(shí)上，最后都是分別調(diào)用了對(duì)應(yīng)的ENGINE的具體實(shí)現(xiàn)，這中間都是通過方法表的指針的方式完成的。ENGINE定義的通用的接口還有很多，這里只是用到了加載密鑰。
表內(nèi)都是對(duì)不同的EVP_CIPHER和EVP_MD的接口的定義。
我們回到加載key的函數(shù)，繼續(xù)閱讀發(fā)現(xiàn)一個(gè) key = bio_open_default(file, 'r', format); 這個(gè)key是一個(gè)BIO類型的指針，這個(gè)BIO類型的指針就是另外一個(gè)OpenSSL的子系統(tǒng)，所有的IO操作都會(huì)被封裝到這個(gè)子系統(tǒng)之下。例如這里使用的文件IO，用于從文件中讀取key的結(jié)果。BIO被設(shè)計(jì)為一個(gè)管道式的系統(tǒng)，類似于Shell腳本中見到的管道的效果。有兩種類型的BIO，一種是source/sink類型的，就是我們最常見的讀取文件或者Socket的方式。另外一種是管道BIO，就是兩個(gè)BIO可以通過一個(gè)管道BIO連接起來，形成一個(gè)數(shù)據(jù)流。所以BIO的方式是一個(gè)很重量級(jí)的IO系統(tǒng)的實(shí)現(xiàn)，只是目前只是被OpenSSL內(nèi)部使用的比較多。
繼續(xù)向下閱讀加載密鑰的函數(shù)，會(huì)發(fā)現(xiàn)PEM_read_bio_PrivateKey函數(shù)，這一步就是實(shí)際的從一個(gè)文件中讀取密鑰了。我們現(xiàn)在已經(jīng)有了代表文件讀寫的BIO，代表密碼學(xué)在程序中的封裝EVP，中間缺的橋梁就是文件中密鑰存儲(chǔ)的格式。這里的以PEM_開頭的函數(shù)就代表了PEM格式的API。PEM是密碼學(xué)的存儲(chǔ)格式，PEM_開頭的API就是解析或者生成這種格式的API，當(dāng)然它需要從文件中讀取，所以參數(shù)中也會(huì)有BIO的結(jié)構(gòu)體，PEM模塊使用BIO模塊提供的文件服務(wù)按照定義的格式將密鑰加載到內(nèi)存。
OpenSSL的所有apps都會(huì)共享一些函數(shù)，這些函數(shù)的實(shí)現(xiàn)都在一個(gè)apps.c文件中，以上的加載密鑰的函數(shù)也是其中的一個(gè)。s_server程序在調(diào)用完load_key之后會(huì)繼續(xù)調(diào)用load_cert來加載證書。load_cert使用的子系統(tǒng)與load_key非常類似，類似的還有后面的load_crl函數(shù)，CRL（Certificate revocation lists）是CA吊銷的證書列表，這項(xiàng)技術(shù)已經(jīng)基本被OCSP淘汰。OpenSSL還提供一個(gè)隨機(jī)數(shù)文件的功能，可以從文件中加載隨機(jī)數(shù)。
s_server在加載完相關(guān)的密碼學(xué)相關(guān)參數(shù)后，就會(huì)開始創(chuàng)建上下文，SSL_CTX_new函數(shù)的調(diào)用就代表了上下文的創(chuàng)建。這個(gè)上下文是后面所有SSL連接的母板，對(duì)SSL的配置設(shè)置都會(huì)體現(xiàn)在這個(gè)上下文的設(shè)置中。隨后，s_server會(huì)開始設(shè)置OpenSSL服務(wù)器支持的TLS握手版本范圍，分別調(diào)用SSL_CTX_set_min_proto_version和SSL_CTX_set_max_proto_version兩個(gè)函數(shù)完成所有操作。
OpenSSL在共享TLS握手的Session時(shí)，需要生成一個(gè)Session ID，默認(rèn)的情況，OpenSSL會(huì)在內(nèi)部決定Session ID怎么生成。但是也提供了用戶設(shè)置這個(gè)生成算法的API。s_server程序調(diào)用SSL_CTX_set_generate_session_id函數(shù)設(shè)置一個(gè)自己的回調(diào)函數(shù)，在這個(gè)回調(diào)函數(shù)中就可以完成Session ID的設(shè)置，從而取代掉OpenSSL自帶的內(nèi)部Session ID的生成器。OpenSSL在證書協(xié)商的時(shí)候還會(huì)允許外部的庫(kù)使用者動(dòng)態(tài)的修改采用的證書，這個(gè)機(jī)制是通過SSL_CTX_set_cert_cb來設(shè)置證書回調(diào)函數(shù)實(shí)現(xiàn)的。s_server也有這個(gè)函數(shù)的設(shè)置。程序走到這里，基本能看到OpenSSL的一個(gè)很大的特性，就是大部分的內(nèi)部流程都會(huì)提供一個(gè)回調(diào)函數(shù)給使用者來注冊(cè)，使用者可以按照自己的需求取代掉或者修改OpenSSL內(nèi)部的功能。顯然這個(gè)s_server程序是一個(gè)功能展示的程序，會(huì)用上大量的函數(shù)回調(diào)點(diǎn)。比如緊接著調(diào)用的SSL_CTX_set_info_callback函數(shù)就是在生成SSL的時(shí)候調(diào)用的，可以用于使用者獲得狀態(tài)。不但OpenSSL外部的機(jī)制可以在用戶端設(shè)置，用戶甚至可以設(shè)置加密算法的參數(shù)。例如s_server就會(huì)接下來根據(jù)用戶是否提供DH參數(shù)來設(shè)置內(nèi)部的參數(shù)。如果調(diào)用了SSL_CTX_set_dh_auto就意味著參數(shù)是使用內(nèi)部的機(jī)制生成，這也是默認(rèn)的行為。但是仍然可以提前提供，主要是為了性能的考慮，比如提前提供DH的大素?cái)?shù)，DH算法在運(yùn)算的過程中需要一個(gè)取模操作，這個(gè)取模是對(duì)一個(gè)大素?cái)?shù)進(jìn)行取模的，而這個(gè)大素?cái)?shù)默認(rèn)是在運(yùn)行的時(shí)候動(dòng)態(tài)生成的，但是我們可以提供這個(gè)素?cái)?shù)，從而以犧牲一定的安全性為代價(jià)換來性能的提高。
s_server在設(shè)置完整個(gè)上下文之后，就會(huì)進(jìn)入Socket監(jiān)聽和處理的模式。由于BIO框架包含了Socket的能力，所以這一步本質(zhì)上就是調(diào)用BIO的接口。
這是一個(gè)典型的OpenSSL的Socket邏輯。BIO_sock_init這個(gè)函數(shù)在Linux下就是空函數(shù)，沒有意義。BIO_lookup是一個(gè)通用的獲取地址的方法，對(duì)于Socket就是IP:PORT的字符串，對(duì)于文件是文件的目錄。BIO_socket意思就相當(dāng)于在使用Socket變成的socket函數(shù)。BIO_listen也就自然對(duì)應(yīng)listen函數(shù)，BIO_accept_ex和BIO_closesocket也是類似的意思。整個(gè)流程其實(shí)就與一個(gè)普通的Socket流程沒有太大區(qū)別，只是BIO多了一層封裝。因?yàn)镺penSSL是個(gè)跨平臺(tái)的庫(kù)，這層封裝更多的意義在于用在跨平臺(tái)的應(yīng)用上的。
通過一個(gè)簡(jiǎn)單的s_server程序的分析可以看到整個(gè)OpenSSL的主要設(shè)計(jì)思路。它對(duì)外封裝了不同的模塊，例如ENGINE，EVP，BIO之類的封裝。在大部分的流程上都提供了回調(diào)函數(shù)API，使用者可以用回調(diào)函數(shù)來修改OpenSSL原來的邏輯或者獲得其他的信息。在使用OpenSSL的時(shí)候一般需要遵循類似的流程，就是創(chuàng)建上下文，然后配置上下文，然后運(yùn)行服務(wù)。
強(qiáng)推
