<output id="qn6qe"></output>

    1. <output id="qn6qe"><tt id="qn6qe"></tt></output>
    2. <strike id="qn6qe"></strike>

      亚洲 日本 欧洲 欧美 视频,日韩中文字幕有码av,一本一道av中文字幕无码,国产线播放免费人成视频播放,人妻少妇偷人无码视频,日夜啪啪一区二区三区,国产尤物精品自在拍视频首页,久热这里只有精品12

      一、什么是數字證書

      1. 證書定義

      數字證書通常代表符合X509標準的公鑰證書
      公鑰證書:由CA機構使用CA機構自身私鑰加密的密文,加密信息為網站域名,郵箱等等信息

      2. 證書類型

      2.1 自簽證書

      您可以創建自己的“自簽名”SSL證書。雖然這是免費的,但卻沒有身份驗證。當用戶訪問使用自簽名證書時,瀏覽器將顯示安全警告,告訴用戶該網站不受信任。就因為他們是免費的,為了節省開支,所以經常被內聯實驗室在開發網頁和系統時使用。

      2.2 DV證書(驗證域名)

      DV SSL 證書是 Domain Validation SSL Certificate 英文全稱的簡寫,翻譯成中文是域名型 SSL證書 或 域名驗證 SSL證書。1-2個小時左右就可完成域名確認和快速頒發證書,無需遞交紙質文件,僅驗證域名管理權,無需人工驗證申請單位真實身份。 DV SSL 證書不在證書中顯示申請單位名稱,只顯示網站域名。證書購買后,一般 1-2個小時左右即可獲得來自證書頒發機構簽發的 SSL 證書。

      2.3 OV證書(驗證組織)

      這些證書包括了完整的業務及公司驗證。該證書驗證是來自證書頒發機構,使用目前被認可和接受的手動審批程序。就是因為這個要求,這種證書提供比DV SSL證書更高水平的信任和安全性。但是,該這種證書并沒有通過由CA/B論壇的設定的發行標準,也不會使最新版本瀏覽器的地址欄變成綠色。這主要是要告訴您該網站的組織已經通過認證,您可以安全地進行任何交易。

      2.4 EV證書(驗證增強)

      EV證書是通過CA/B論壇設定的嚴格指導方針而被驗證的。CA/B論壇是一個獨立的標準組織,在頒發證書前,會對企業進行深入的合法性核查。正因如此,EV證書提供安全級別的安全性和信任給終端用戶。為了顯示更高的信任級別,如果您正訪問使用擴展驗證的網站,那么瀏覽器將地址欄變成綠色并直接顯示網站所屬企業名稱。
       

      3. 證書品牌

      3.1 免費自簽證書

      3.2 GeoTrust

      GeoTrust 是第二大數字證書頒發機構(CA),也是身份認證和信任認證領域的領導者,該公司各種先進的技術使得任何大小的機構和公司都能安全地低成本地部署SSL數字證書和實現各種身份認證。 150多個國家有超過10萬個用戶在使用 GeoTrust 的產品來進行安全的電子交易和確認并保護網上真實身份,為用戶的電子商務保駕護航。GeoTrust產品的市場占有率已經超過30%,每年的增長率高達150% GeoTrust 專注于SSL證書產品,GeoTrust SSL 證書主要有 5 種: QuickSSL Premium、QuickSSL Premium Wildcard、True Business ID 、True BusinessID Wildcard 與 True Business ID with EV

      3.3 Digicert

      Digicert為超過146個國家和地區的70,000多客戶提供了數字證書,提供SSL證書和SSL管理工具的超過十年認證。 Digicert 是總部設在美國的證書頒發機構,并一直以來致力于提供SSL證書和SSL管理工具超過十年。不像其他那些證書頒發機構提供數十個甚至數百個與SSL加密無關的產品,創建最安全的SSL數字證書是我們所做的一切。這使得我們可以提供最好的SSL產品和無與倫比的技術支持。

      3.4 其他品牌

      4. 證書格式

      4.1 JKS

      JKS和JCEKS是Java密鑰庫(KeyStore)的兩種比較常見類型,JKS的Provider是SUN,在每個版本的JDK中都有,JCEKS的Provider是SUNJCE,1.4后我們都能夠直接使用它。

      4.2 JCEKS

      JCEKS在安全級別上要比JKS強,使用的Provider是JCEKS(推薦),尤其在保護KeyStore中的私鑰上(使用TripleDES)

      4.3 PFX(PKCS12)

      PFX(PKCS#12)是公鑰加密標準,它規定了可包含所有私鑰、公鑰和證書。其以二進制格式存儲,在windows中可以直接導入到密鑰區,注意,PKCS#12的密鑰庫保護密碼同時也用于保護Key。

      4.4 BKS

      BKS來自BouncyCastleProvider,它使用的也是TripleDES來保護密鑰庫中的Key,它能夠防止證書庫被不小心修改(Keystore的keyentry改掉1個bit都會產生錯誤),BKS能夠跟JKS互操作。

      4.5 UBER

      UBER 比較特別,當密碼是通過命令行提供的時候,它只能跟keytool交互。整個keystore是通過PBE/SHA1/Twofish加密,因此 keystore能夠防止被誤改、察看以及校驗。SunJDK允許你在不提供密碼的情況下直接加載一個Keystore,類似cacerts,UBER不 允許這種情況。
       
       

      5. 名詞釋義

      5.1 PKCS

      由美國RSA數據安全公司及其合作伙伴制定的一組公鑰密碼學標準
      包括證書申請、證書更新、證書作廢表發布、擴展證書內容以及數字簽名、數字信封的格式等方面的一系列相關協議
      5.2 公鑰證書
      由CA機構簽發的證書,主要功能在于CA生成的證書綁定了用戶身份,真實性由CA機構生成的簽名保證

      5.3 PKI

      從狹義上講,PKI就是指CA機構,即實現了證書申請、審核、頒發、吊銷、更新等管理功能的權威機構
      從廣義上講,PKI不僅包含CA機構,還應包含證書及密鑰處理程序,并且這些程序應無處不在,使人們能夠在任何時間、任何地點來使用證書,這樣才能算是真正意義上的基礎設施。從這個角度看,PKI還應該包含處于各種應用環境中的、標準化的證書及密鑰處理程序。

      5.4 X.509標準

      服務器SSL數字證書和客戶端單位數字證書的格式遵循 X.509 標準。 X.509 是由國際電信聯盟(ITU-T)制定的數字證書標準。為了提供公用網絡用戶目錄信息服務, ITU 于 1988 年制定了 X.500 系列標準。其中 X.500 和 X.509 是安全認證系統的核心, X.500 定義了一種區別命名規則,以命名樹來確保用戶名稱的唯一性; X.509 則為 X.500 用戶名稱提供了通信實體鑒別機制,并規定了實體鑒別過程中廣泛適用的證書語法和數據接口, X.509 稱之為證書。
      X.509 給出的鑒別框架是一種基于公開密鑰體制的鑒別業務密鑰管理。一個用戶有兩把密鑰:一把是用戶的專用密鑰,簡稱為:私鑰,另一把是其他用戶都可得到和利用的公共密鑰,簡稱為:公鑰。用戶可用常規加密算法(如 DES)為信息加密,然后再用接收者的公共密鑰對 DES 進行加密并將之附于信息之上,這樣接收者可用對應的專用密鑰打開 DES 密鎖,并對信息解密。該鑒別框架允許用戶將其公開密鑰存放在CA的目錄項中。一個用戶如果想與另一個用戶交換秘密信息,就可以直接從對方的目錄項中獲得相應的公開密鑰,用于各種安全服務。
       
      為了進行身份認證, X.509 標準及公共密鑰加密系統提供了一個稱作數字簽名的方案。用戶可生成一段信息及其摘要(亦稱作信息“指紋”)。用戶用專用密鑰對摘要加密以形成簽名,接收者用發送者的公共密鑰對簽名解密,并將之與收到的信息“指紋”進行比較,以確定其真實性。

      5.5 鄧白氏編碼

      (D-U-N-S? Number,是Data Universal Numbering System 的縮寫)。它是一個獨一無二的9位數字全球編碼系統,相當于企業的身份識別碼 (就像是個人的身份證),被廣泛應用于企業識別、商業信息的組織及整理。這個號碼是由鄧白氏公司簽發的,每個號碼會跟一個唯一的企業實體相對應,不會重復 使用。也就是說,一個號碼代表一個公司實體。通過鄧氏編碼,瀏覽者可以迅速獲得獨創、豐富且高質量的信息產品和服務。

      二、證書運行原理

      1. 基本運行過程

      SSL/TLS協議的基本思路是采用公鑰加密法。
      (1) 客戶端向服務器端索要并驗證公鑰。
      (2) 雙方協商生成"對話密鑰"。
      (3) 雙方采用"對話密鑰"進行加密通信。
      (1)(2)為握手階段,此階段報文為明文傳輸。
      但是,這里有兩個問題。

      1.1 如何保證公鑰不被篡改?

      解決方法:將公鑰放在SSL數字證書中。只要證書是可信的,公鑰就是可信的。

      1.2 公鑰加密計算量太大,如何減少耗時時間?

      解決方法:每一次對話(session),客戶端和服務器端都生成一個"對話密鑰"(session key),用它來加密信息。由于"對話密鑰"是對稱加密,所以運算速度非常快,而服務器公鑰只用于加密"對話密鑰"本身,這樣就減少了加密運算的消耗時間。

      2. 詳細運行過程

      2.1 客戶端發起請求

      首先,客戶端(通常是瀏覽器)先向服務器發出加密通信的請求,這被叫做ClientHello請求。 在這一步,客戶端主要向服務器提供以下信息。
      (1) 支持的協議版本,比如TLS 1.0版。
      (2) 一個客戶端生成的隨機數,稍后用于生成"對話密鑰"。
      (3) 支持的加密方法,比如RSA公鑰加密。
      (4) 支持的壓縮方法。
      這里需要注意的是,客戶端發送的信息之中不包括服務器的域名。也就是說,理論上服務器只能包含一個網站,否則會分不清應該向客戶端提供哪一個網站的SSL數字證書。這就是為什么通常一臺服務器只能有一張數字證書的原因。 對于虛擬主機的用戶來說,這當然很不方便。2006年,TLS協議加入了一個Server Name Indication擴展,允許客戶端向服務器提供它所請求的域名。
       

      2.2 服務端回應

      服務器收到客戶端請求后,向客戶端發出回應,這叫做SeverHello。服務器的回應包含以下內容。 (1) 確認使用的加密通信協議版本,比如TLS 1.0版本。如果瀏覽器與服務器支持的版本不一致,服務器關閉加密通信。
      (2) 一個服務器生成的隨機數,稍后用于生成"對話密鑰"。
      (3) 確認使用的加密方法,比如RSA公鑰加密。
      (4) 服務器證書(返回給客戶端的的是CA簽發的公鑰證書)。
      除了上面這些信息,如果服務器需要確認客戶端的身份(即雙向證書,例如微信支付V2版本逆向資金接口),就會再包含一項請求,要求客戶端提供"客戶端證書"。比如,金融機構往往只允許認證客戶連入自己的網絡,就會向正式客戶提供USB密鑰,里面就包含了一張客戶端證書。

      2.3 客戶端回應

      客戶端收到服務器回應以后,首先驗證服務器證書。
      驗證證書合法性,是否由指定機構頒發,依據X509標準進行驗證證書簽名來鑒別
      如果證書不是可信機構頒布、或者證書中的域名與實際域名不一致、或者證書已經過期,就會向訪問者顯示一個警告,由其選擇是否還要繼續通信。 如果證書沒有問題,客戶端就會從證書中取出服務器的公鑰。然后,向服務器發送下面三項信息。 (1) 一個隨機數。該隨機數用服務器公鑰加密,防止被竊聽。
      (2) 編碼改變通知,表示隨后的信息都將用雙方商定的加密方法和密鑰發送。
      (3) 客戶端握手結束通知,表示客戶端的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值,用來供服務器校驗。
      上面第一項的隨機數,是整個握手階段出現的第三個隨機數,又稱"pre-master key"。有了它以后,客戶端和服務器就同時有了三個隨機數,接著雙方就用事先商定的加密方法,各自生成本次會話所用的同一把"會話密鑰"。
      至于為什么一定要用三個隨機數,來生成"會話密鑰", "不管是客戶端還是服務器,都需要隨機數,這樣生成的密鑰才不會每次都一樣。由于SSL協議中證書是靜態的,因此十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性。
      對于RSA密鑰交換算法來說,pre-master-key本身就是一個隨機數,再加上hello消息中的隨機,三個隨機數通過一個密鑰導出器最終導出一個對稱密鑰。
      pre master的存在在于SSL協議不信任每個主機都能產生完全隨機的隨機數,如果隨機數不隨機,那么pre master secret就有可能被猜出來,那么僅適用pre master secret作為密鑰就不合適了,因此必須引入新的隨機因素,那么客戶端和服務器加上pre master secret三個隨機數一同生成的密鑰就不容易被猜出了,一個偽隨機可能完全不隨機,可是是三個偽隨機就十分接近隨機了,每增加一個自由度,隨機性增加的可不是一。" 此外,如果前一步,服務器要求客戶端證書,客戶端會在這一步發送證書及相關信息。

      2.4 服務單最后回應

      服務器收到客戶端的第三個隨機數pre-master key之后,計算生成本次會話所用的"會話密鑰"。然后,向客戶端最后發送下面信息。
      (1)編碼改變通知,表示隨后的信息都將用雙方商定的加密方法和密鑰發送。
      (2)服務器握手結束通知,表示服務器的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值,用來供客戶端校驗。
      至此,整個握手階段全部結束。接下來,客戶端與服務器進入加密通信,就完全是使用普通的HTTP協議,只不過用"會話密鑰"加密內容。
       

      三、手動實踐(自簽證書)

      1. 使用Keytool生成證書

      1.1 創建keystore和密鑰對

      命令:
      keytool -genkey -alias www.yonyong.top -keyalg RSA -keystore keystore.jks -keysize 2048

       

      D:\data\certs\jks\www.yonyong.top>keytool -genkey -alias www.yonyong.top -keyalg RSA -keystore keystore.jks -keysize 2048
      輸入密鑰庫口令:
      密鑰庫口令太短 - 至少必須為 6 個字符
      輸入密鑰庫口令:
      再次輸入新口令:
      您的名字與姓氏是什么?
        [Unknown]:  yangde
      您的組織單位名稱是什么?
        [Unknown]:  yangde
      您的組織名稱是什么?
        [Unknown]:  yangde
      您所在的城市或區域名稱是什么?
        [Unknown]:  nj
      您所在的省/市/自治區名稱是什么?
        [Unknown]:  jiangsu
      該單位的雙字母國家/地區代碼是什么?
        [Unknown]:  CN
      CN=yangde, OU=yangde, O=yangde, L=nj, ST=jiangsu, C=CN是否正確?
        [否]:  y
      
      輸入 <www.yonyong.top> 的密鑰口令
              (如果和密鑰庫口令相同, 按回車):
      再次輸入新口令:
      
      Warning:
      JKS 密鑰庫使用專用格式。建議使用 "keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12" 遷移到行業標準格式 PKCS12。
      
      D:\data\certs\jks\www.yonyong.top>

      1.2 將秘鑰轉成行業標準格式PKCS12

      keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12

       

      D:\data\certs\jks\www.yonyong.top>keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12
      輸入源密鑰庫口令:
      已成功導入別名 www.yonyong.top 的條目。
      已完成導入命令: 1 個條目成功導入, 0 個條目失敗或取消
      
      Warning:
      已將 "keystore.jks" 遷移到 Non JKS/JCEKS。將 JKS 密鑰庫作為 "keystore.jks.old" 進行了備份。
      
      D:\data\certs\jks\www.yonyong.top>

      2. 使用Openssl生成證書

      詳細生成命令鏈接:https://www.chinassl.net/faq/n505.html

      2.1 生成頂級CA證書/根證書

      // 生成頂級CA的公鑰證書和私鑰文件,有效期10年(RSA 1024bits,默認) 
      openssl req -new -x509 -days 3650 -keyout CARoot1024.key -out CARoot1024.crt
      // 為頂級CA的私鑰文件去除保護口令 
      openssl rsa -in CARoot1024.key -out CARoot1024.key
      
      // 生成頂級CA的公鑰證書和私鑰文件,有效期15年(RSA 2048bits,指定) 
      openssl req -newkey rsa:2048 -x509 -days 5480 -keyout CARoot2048.key -out CARoot2048.crt 
      // 為頂級CA的私鑰文件去除保護口令 
      openssl rsa -in CARoot2048.key -out CARoot2048.key
      [root@VM-0-10-centos www.yonyong.top]# openssl req -new -x509 -days 3650 -keyout CARoot1024.key -out CARoot1024.crt
      Generating a 2048 bit RSA private key
      ...........................+++
      ..+++
      writing new private key to 'CARoot1024.key'
      Enter PEM pass phrase:
      Verifying - Enter PEM pass phrase:
      -----
      You are about to be asked to enter information that will be incorporated
      into your certificate request.
      What you are about to enter is what is called a Distinguished Name or a DN.
      There are quite a few fields but you can leave some blank
      For some fields there will be a default value,
      If you enter '.', the field will be left blank.
      -----
      Country Name (2 letter code) [XX]:yonyong
      string is too long, it needs to be less than  2 bytes long
      Country Name (2 letter code) [XX]:yoyong
      string is too long, it needs to be less than  2 bytes long
      Country Name (2 letter code) [XX]:x^HCN
      string is too long, it needs to be less than  2 bytes long
      Country Name (2 letter code) [XX]:CN
      State or Province Name (full name) []:jiangsu
      Locality Name (eg, city) [Default City]:nj
      Organization Name (eg, company) [Default Company Ltd]:yonyong
      Organizational Unit Name (eg, section) []:yonyong
      Common Name (eg, your name or your server's hostname) []:yonyong
      Email Address []:2365788736@qq.com
      [root@VM-0-10-centos www.yonyong.top]# 
      [root@VM-0-10-centos www.yonyong.top]# 
      [root@VM-0-10-centos www.yonyong.top]# ll
      total 8
      -rw-r--r-- 1 root root 1399 Apr 24 18:12 CARoot1024.crt
      -rw-r--r-- 1 root root 1834 Apr 24 18:12 CARoot1024.key
      [root@VM-0-10-centos www.yonyong.top]# 
      [root@VM-0-10-centos www.yonyong.top]# openssl rsa -in CARoot1024.key -out CARoot1024.key
      Enter pass phrase for CARoot1024.key:
      writing RSA key
      [root@VM-0-10-centos www.yonyong.top]# 

      2.2 生成應用證書/用戶證書

      // 為應用證書/中級證書生成私鑰文件 
      openssl genrsa -out app.key 2048 
      // 根據私鑰文件,為應用證書/中級證書生成 csr 文件(證書請求文件) 
      openssl req -new -key app.key -out app.csr 
      // 使用CA的公私鑰文件給 csr 文件簽名,生成應用證書,有效期5年 
      openssl ca -in app.csr -out app.crt -cert CARoot1024.crt -keyfile CARoot1024.key -days 1826 -policy policy_anything

      2.2.1 生成應用證書請求

      注意生成證書是 common name不能重復
      [root@VM-0-10-centos www.yonyong.top]# openssl genrsa -out app.key 2048 
      Generating RSA private key, 2048 bit long modulus
      ................................................................................................................+++
      ...............+++
      e is 65537 (0x10001)
      [root@VM-0-10-centos www.yonyong.top]# openssl req -new -key app.key -out app.csr 
      You are about to be asked to enter information that will be incorporated
      into your certificate request.
      What you are about to enter is what is called a Distinguished Name or a DN.
      There are quite a few fields but you can leave some blank
      For some fields there will be a default value,
      If you enter '.', the field will be left blank.
      -----
      Country Name (2 letter code) [XX]:CN
      State or Province Name (full name) []:jiangsu
      Locality Name (eg, city) [Default City]:NJ
      Organization Name (eg, company) [Default Company Ltd]:alibaba
      Organizational Unit Name (eg, section) []:alibaba
      Common Name (eg, your name or your server's hostname) []:ali
      Email Address []:alibaba@126.com
      
      Please enter the following 'extra' attributes
      to be sent with your certificate request
      A challenge password []:123456
      An optional company name []:alibaba
      [root@VM-0-10-centos www.yonyong.top]# ll
      total 16
      -rw-r--r-- 1 root root 1098 Apr 26 18:26 app.csr
      -rw-r--r-- 1 root root 1679 Apr 26 18:24 app.key
      -rw-r--r-- 1 root root 1399 Apr 24 18:12 CARoot1024.crt
      -rw-r--r-- 1 root root 1679 Apr 24 18:20 CARoot1024.key

      2.2.2 創建文件(踩坑,初次簽證書會有報錯,走這一步解決)

      # 根據報錯創建文件
      [root@VM-0-10-centos www.yonyong.top]# touch /etc/pki/CA/index.txt
      # 根據報錯創建文件
      [root@VM-0-10-centos www.yonyong.top]# touch /etc/pki/CA/serial
      # 根據報錯創建文件
      [root@VM-0-10-centos www.yonyong.top]# echo '01' >/etc/pki/CA/serial

      2.2.3 生成應用證書

      [root@VM-0-10-centos www.yonyong.top]# openssl ca -in app.csr -out app.crt -cert CARoot1024.crt -keyfile CARoot1024.key -days 1826 -policy policy_anything
      Using configuration from /etc/pki/tls/openssl.cnf
      Check that the request matches the signature
      Signature ok
      Certificate Details:
              Serial Number: 1 (0x1)
              Validity
                  Not Before: Apr 24 10:37:05 2022 GMT
                  Not After : Apr 24 10:37:05 2027 GMT
              Subject:
                  countryName               = CN
                  stateOrProvinceName       = js
                  localityName              = nj
                  organizationName          = yd
                  organizationalUnitName    = yd
                  commonName                = yd
                  emailAddress              = yd@qq.com
              X509v3 extensions:
                  X509v3 Basic Constraints: 
                      CA:FALSE
                  Netscape Comment: 
                      OpenSSL Generated Certificate
                  X509v3 Subject Key Identifier: 
                      EA:82:46:3F:C6:D4:CD:E6:62:00:72:DE:89:55:6D:D7:68:00:14:F4
                  X509v3 Authority Key Identifier: 
                      keyid:B1:0A:8A:8B:C5:11:4E:47:22:C3:12:C8:47:23:26:C2:1F:24:09:E3
      
      Certificate is to be certified until Apr 24 10:37:05 2027 GMT (1826 days)
      Sign the certificate? [y/n]:y
      
      
      1 out of 1 certificate requests certified, commit? [y/n]y
      Write out database with 1 new entries
      Data Base Updated
      [root@VM-0-10-centos www.yonyong.top]# ll
      total 24
      -rw-r--r-- 1 root root 4551 Apr 24 18:37 app.crt
      -rw-r--r-- 1 root root 1062 Apr 24 18:21 app.csr
      -rw-r--r-- 1 root root 1679 Apr 24 18:20 app.key
      -rw-r--r-- 1 root root 1399 Apr 24 18:12 CARoot1024.crt
      -rw-r--r-- 1 root root 1679 Apr 24 18:20 CARoot1024.key
      [root@VM-0-10-centos www.yonyong.top]# 

      2.3 生成中級證書(可選)

      // 使用CA的公私鑰文件給 csr 文件簽名,生成中級證書,有效期5年 
      openssl ca -extensions v3_ca -in app.csr -out app.crt -cert CARoot1024.crt -keyfile CARoot1024.key -days 1826 -policy policy_anything
      [root@VM-0-10-centos www.yonyong.top]# openssl ca -extensions v3_ca -in app.csr -out app.crt -cert CARoot1024.crt -keyfile CARoot1024.key -days 1826 -policy policy_anything
      Using configuration from /etc/pki/tls/openssl.cnf
      Check that the request matches the signature
      Signature ok
      Certificate Details:
              Serial Number: 2 (0x2)
              Validity
                  Not Before: Apr 24 10:41:20 2022 GMT
                  Not After : Apr 24 10:41:20 2027 GMT
              Subject:
                  countryName               = CN
                  stateOrProvinceName       = js
                  localityName              = nj
                  organizationName          = yd
                  organizationalUnitName    = yd
                  commonName                = yd
                  emailAddress              = yd@qq.com
              X509v3 extensions:
                  X509v3 Subject Key Identifier: 
                      EA:82:46:3F:C6:D4:CD:E6:62:00:72:DE:89:55:6D:D7:68:00:14:F4
                  X509v3 Authority Key Identifier: 
                      keyid:B1:0A:8A:8B:C5:11:4E:47:22:C3:12:C8:47:23:26:C2:1F:24:09:E3
      
                  X509v3 Basic Constraints: 
                      CA:TRUE
      Certificate is to be certified until Apr 24 10:41:20 2027 GMT (1826 days)
      Sign the certificate? [y/n]:y
      failed to update database
      TXT_DB error number 2
      [root@VM-0-10-centos www.yonyong.top]# ll
      total 16
      -rw-r--r-- 1 root root    0 Apr 24 18:41 app.crt
      -rw-r--r-- 1 root root 1062 Apr 24 18:21 app.csr
      -rw-r--r-- 1 root root 1679 Apr 24 18:20 app.key
      -rw-r--r-- 1 root root 1399 Apr 24 18:12 CARoot1024.crt
      -rw-r--r-- 1 root root 1679 Apr 24 18:20 CARoot1024.key
      [root@VM-0-10-centos www.yonyong.top]# 

       

      四、證書與Java

      1. Java解析證書文件獲取證書對象

      1.1 PKCS12格式的證書

      /**
       * 通過PKCS12格式的證書庫文件獲取證書對象(包含公鑰和私鑰證書)
       * 自簽證書:
       * https://csr.chinassl.net/keytool-commands.html
       * keytool -genkey -alias mydomain -keyalg RSA -keystore keystore.jks -keysize 2048
       */
      private static void test() throws Exception {
          InputStream inStream = new FileInputStream(CERTIFICATE_SELF_SIGN);
      
          KeyStore ks = KeyStore.getInstance("PKCS12");
          ks.load(inStream, "123456".toCharArray());
      
          String alias = ks.aliases().nextElement();
      
          //獲取私鑰
          PrivateKey privateKey = (PrivateKey) ks.getKey(alias, "123456".toCharArray());
      
          //獲取公鑰證書
          X509Certificate certificate = (X509Certificate) ks.getCertificate(alias);
          System.out.println(certificate.getNotAfter());
      }

      1.2 pem、crt文件

      /**
       * 通過pem文件獲取證書對象
       */
      private static void test2() throws Exception {
          CertificateFactory fact = CertificateFactory.getInstance("X.509");
          X509Certificate certificate = (X509Certificate) fact.generateCertificate(new FileInputStream (CERTIFICATE_IT610));
          PublicKey publicKey = certificate.getPublicKey();
      }

       

      2. Java依據證書文件字符串獲取證書對象

      2.1 依據公鑰證書pem 獲取公鑰對象

      /**
       * 從字符串中加載公鑰
       *
       * @param publicKeyStr 公鑰數據字符串
       * @throws Exception 異常信息
       */
      public static PublicKey loadPublicKey(String publicKeyStr) throws Exception {
          try {
              byte[] buffer = Base64.decode(publicKeyStr);
              KeyFactory keyFactory = KeyFactory.getInstance(KEY_ALGORITHM);
              X509EncodedKeySpec keySpec = new X509EncodedKeySpec(buffer);
              return keyFactory.generatePublic(keySpec);
          } catch (NoSuchAlgorithmException e) {
              throw new Exception("無此算法");
          } catch (InvalidKeySpecException e) {
              throw new Exception("公鑰非法");
          } catch (NullPointerException e) {
              throw new Exception("公鑰數據為空");
          }
      }

      2.2 依據私鑰證書pem獲取私鑰對象

      /**
       * 從字符串中加載私鑰<br>
       * 加載時使用的是PKCS8EncodedKeySpec(PKCS#8編碼的Key指令)。
       *
       * @param privateKeyStr 私鑰
       * @return {@link PrivateKey}
       * @throws Exception 異常信息
       */
      public static PrivateKey loadPrivateKey(String privateKeyStr) throws Exception {
          try {
              byte[] buffer = Base64.decode(privateKeyStr);
              PKCS8EncodedKeySpec keySpec = new PKCS8EncodedKeySpec(buffer);
              KeyFactory keyFactory = KeyFactory.getInstance(KEY_ALGORITHM);
              return keyFactory.generatePrivate(keySpec);
          } catch (NoSuchAlgorithmException e) {
              throw new Exception("無此算法");
          } catch (InvalidKeySpecException e) {
              throw new Exception("私鑰非法");
          } catch (NullPointerException e) {
              throw new Exception("私鑰數據為空");
          }
      }

       

      posted on 2022-05-19 21:59  yonyong  閱讀(1990)  評論(0)    收藏  舉報
      主站蜘蛛池模板: 老司机免费的精品视频| 精品福利视频一区二区三区| 99久久99久久久精品久久| 中文字幕精品无码一区二区| 亚洲欧美色一区二区三区| 国产成人一区二区三区免费 | 丁香五月婷激情综合第九色| 婷婷四虎东京热无码群交双飞视频 | 国产在线观看播放av| 苍井空浴缸大战猛男120分钟| 欧美日韩国产图片区一区| 色综合国产一区二区三区| 榆林市| 色偷偷久久一区二区三区| 上司人妻互换中文字幕| 把女人弄爽大黄A大片片 | 偷炮少妇宾馆半推半就激情| 男女无遮挡激情视频| 人妻av一区二区三区av免费| 国产亚洲精品久久久久久无亚洲| 成人免费A级毛片无码网站入口| 在线观看精品视频网站| 亚洲人成小说网站色在线| 无码AV无码免费一区二区| 国产欧美久久一区二区| 中文字幕午夜福利片午夜福利片97| 国产在线午夜不卡精品影院 | 亚洲一二三区精品美妇| 国产日韩av二区三区| 免费看国产曰批40分钟| 精品无码久久久久久久久久| 国产360激情盗摄全集| 日本一区二区三区四区黄色| 国产va免费精品观看| 日韩中文字幕亚洲精品| 欧美国产日产一区二区| 上蔡县| 亚洲一级特黄大片一级特黄| 蜜臀av无码一区二区三区| 日韩精品中文字幕人妻| 不卡一区二区国产精品|