【SSL証明書・証明書】SSL証明書の基本概念、証明書形式、opensslとkeytoolの違い

関連記事：
//-----------Java SSL はじめます----------------------
【SSL認証・証明書】SSL 2- way認証 SSL片方向認証との違い（概念図）
【ssl認証、証明書】 Javaのssl構文 API記述（SSLContext）、keytoolツールとの接続
【ssl認証、証明書】 SSL双方向認証 java実戦、keytool証明書を作成するには
[SSL 認証、証明書] Wireshark パケット キャプチャ分析
[SSL 証明書、証明書] キーストア ファイルの内容を表示します
//-----------Java SSL 終了------ ---------- ----------

//----------以下は CA 証明書と openssl に関する知識です---------------
[SSL 証明書、証明書] TLS/SSL 双方向証明書概念、openssl genrsa 例
[ssl 証明書、証明書] openssl genrsa コマンド詳細説明
[ssl 証明書、証明書] SSL 証明書の基本概念、証明書の形式、openssl と keytool の違い

1.keytool VS openssl

keytool と openssl は 2 つの証明書管理です工具。

まず前提を確認しておく必要があります keytool で生成される証明書は Java 言語の ssl 通信と密接に関係しています OpenSSL で生成される証明書は対応する形式に従って Java が認識できる形式に変換してからでないと使用できません利用される。

• keytool は Java JDK に付属する証明書管理ツールで、keytool を使用すると鍵を生成し、証明書を作成できます。jdk がインストールされ、環境変数が正しく設定されていれば、コマンド ラインから keytool コマンドを実行して証明書を管理できます。

  keytool は自己署名デジタル証明書のみを生成できます。いわゆる自己署名証明書は、CA 発行機関が発行するのではなく、自ら発行する証明書であり、CA ルート証明書では証明書の正当性を判断できないため、証明書の検証は証明書の検証が行えません。ホワイト リスト。接続するサーバーごとに、証明書のコピーを事前にコピーし、信頼キー ストア (略して TKS) に配置する必要があります。TKS 内の証明書は、信頼できる証明書のホワイト リストです。 Java SSL 通信における標準 SSL、JAVA による証明書の検証のカスタマイズ、TKS は CA_ROOT 検出証明書を置き換えるように設計されています。したがって、Keytool は事前にコピーしてホワイトリストとして TKS にインポートする必要があるという欠点があります。

• openssl は、keytool よりも多くの機能を備えたオープンソースの Secure Sockets Layer 暗号化ライブラリです。

  OpenSSL は、相互認証または一方向認証に証明書チェーンを利用する標準的な SSL 実装です。証明書チェーンとは、証明書の署名に事前に展開された既知の署名者の署名があることを意味します。そのため、証明書を検証する必要があるたびに、公開署名者の公開キーのみを使用する必要があります (ルート証明書は本質的にはこの公開キー) 検証用です。たとえば、私たちが使用するブラウザは、一般的に使用される CA_ROOT (つまり、よく呼ばれるルート証明書) をいくつか保存します。Web サイトに接続するたびに、この Web サイトの証明書がこれらの CA_ROOT によって署名されていると判断されれば、認識され検証されます。

  また、証明書はネットワークを通じてピアエンドに送信され、事前にピアエンドにコピーする必要はありません。CA_ROOT は事前に設定されており、有名な CA 機関であり、非常に信頼できます。

  共有 CA_ROOT サービスは無料ではなく高価ですが、企業内の内部通信であれば、自己発行の CA_ROOT を使用して自己署名証明書を生成すると同時に、CA_ROOT を事前にピアに送信し、その後のフォローアッププロセスは標準と同じです SSL フローは同じです

2. X.509 VS PKCS

コンピューターの世界には、コンピューター内でさまざまなアルゴリズムを計算、保存、送信などする方法を表すさまざまな暗号化標準があり、これらの標準は IEFT、ITU-T、ISO などの標準化団体によって作成されています。

これらのことについて説明する前に、注意すべき点が 1 つあります。以下のいくつかの場所で言及されている秘密キーは、実際には純粋な秘密キー (RSA など) ではなく、キー ペア全体の必要な情報がすべて含まれています
。公開キーも含まれます)。これが、公開キーを秘密キーから抽出できる理由です。

たとえば、RSA 公開キーは RSAPrivateKey に含まれ、ECC 公開キーは ECPrivateKey に含まれます。

PKCS 协议组和 X.509 协议均采用 ASN.1 来定义密钥或证书的数据结构。すべてASN.1 协议具体的な実装です。

関係の概要:

2.1 PKCS

PKCS の正式名称は Public-Key Cryptography Standards、つまり公開鍵標準であり、15 の標準がリリースされています。

• PKCS#1 は X.509 に近い
• …
• PKCS#12 には、.pfx証明書ファイルのサフィックスが付いたバイナリ形式の証明書の形式で公開キーと秘密キーが含まれています。他のタイプの一般的な公開鍵と秘密鍵はまとめられず、通常はフォーマットされていません.pfx。

公開鍵標準と呼ばれていますが、秘密鍵標準も含まれています。

標準	バージョン	名前	序章
PKCS #1	2.2	RSA 暗号化標準	RSA アルゴリズムに基づく公開キー暗号化の実装に関する提案を提供します。これには、暗号化プリミティブ、暗号化スキーム、付録付きの署名スキーム、キーを表現しスキームを識別するための ASN.1 構文が含まれます。RFC 8017 を参照してください。
PKCS #2	-	廃止する	元々は RSA 暗号化ダイジェストを標準化することを目的とした変換が PKCS #1 に組み込まれました。
PKCS #3	1.4	Diffie-Hellman プロトコル標準 (Diffie-Hellman 鍵協定標準)	Diffie-Hellman プロトコルに基づいた鍵合意標準を指定します。この機能により、2 者が合意を通じて会議キー (セッション キー) を草案することができます。
PKCS #4	-	廃止する	元々は、RSA キーの変換プロセスを標準化するために使用されていました。PKCS #1 に組み込まれています。
PKCS #5	2.1	パスワードベースの暗号化標準	RFC 8018を参照してください。
PKCS #6	1.5	拡張証明書構文標準	元の X.509 証明書形式標準を拡張します。
PKCS #7	1.5	暗号化メッセージ構文標準	RFC 2315 を参照してください。公開キー基盤 (PKI) によって生成される署名/暗号文の形式を指定します。同じ目的は、デジタル証明書の適用を拡大することです。その中には、S/MIMEとCMS（英語：Cryptographic Message Syntax）が含まれます。
PKCS #8	1.2	秘密鍵情報構文標準	秘密鍵情報を保存するための標準構文。RFC 5208を参照してください。
PKCS #9	2.0	選択した属性タイプ	PKCS #6、7、8、10 の選択属性形式を定義します。
PKCS #10	1.7	証明書申請基準（証明書要求基準）	RFC 2986 を参照してください。証明書センターに証明書を申請するためのCSR（証明書署名要求）のフォーマットを標準化します。
PKCS #11	2.20	暗号化トークン インターフェイス (Cryptoki)	暗号化デバイスのアプリケーション プログラミング インターフェイス (API) の仕様を定義します。
PKCS #12	1.0	個人情報交換構文標準	秘密鍵証明書と公開鍵証明書を含むファイル形式を定義します。秘密キーはパスワードで保護されています。一般的なPFX 形式はPKCS #12 を実装します。
PKCS #13	–	楕円曲線暗号規格	開発中で。楕円曲線暗号をベースに開発された暗号技術の応用を標準化する。楕円曲線暗号は新しい暗号技術であり、その強度と効率は指数演算に基づく現在の暗号アルゴリズムよりも優れています。ただし、このアルゴリズムの適用はまだ普及していません。
PKCS #14	–	擬似乱数発生器の標準	開発中で。擬似乱数発生器の使用と設計を規制します。
PKCS #15	1.1	暗号トークン情報フォーマット規格	暗号化デバイスの内部データの組織構造を定義します。

2.2X.509

X.509 は、暗号化における公開キー証明書の形式標準です。X.509 証明書は、TLS/SSL を含む多くのネットワーク プロトコルで使用されており、電子署名サービスなどの多くのオフライン アプリケーション シナリオでも使用されています。X.509 证书里含有公钥、身份信息（比如网络主机名，组织的名称或个体名称等）和签名信息（可以是证书签发机构 CA 的签名，也可以是自签名）

公開鍵標準と呼ばれていますが、秘密鍵標準も含まれています。

2.2.1 証明書のエンコード形式

DER と perm はプロトコルであり、前者はバイナリ、後者はテキストです。

2.2.1.1 DER 証明書エンコーディング形式バイナリ

X.690 は、いくつかの ASN.1 エンコード形式を指定する ITU-T 標準です。

• Basic Encoding Rules (BER、Basic Encoding Rules)のエンコード形式抽象。通常、実際にはサフィックスとして使用されません。
• 正規エンコーディング ルール (CER、正規エンコーディング ルール) バイナリ。実際のサフィックスとしてよく使用されます。
• Distinguished Encoding Rules (DER、Distinguished Encoding Rules) バイナリ。BER のサブセットで、実際のサフィックスとしてよく使用されます。

BER 是 ASN.1 标准制定的用于将数据编码为二进制格式的原始规则。ASN.1 用語では転送構文として総称され、これらのルールはデータのエンコードに使用される正確なオクテット (8 ビット バイト) を指定します。

DER 是 BER 的子集、ASN.1 値をエンコードする方法を提供します。DER は、暗号化など、一意のエンコーディングが必要な状況に適しており、デジタル署名を必要とするデータ構造が一意のシリアル化された表現になることを保証します。DER は、BER の標準形式と考えることができます。

暗号化に関して言えば、DER 就是 ASN.1 的二进制表达一般的に使用されるサフィックス.derキー/証明書ファイルには DER ルールのバイナリが保存されており、ASN.1 の抽象構造に解析できることが簡単に理解できます。

例として、これは実際の X.509 公開キーファイル.derのバイト内容です。

30 82 01 22 30 0D 06 09 2A 86 48 86 F7 0D 01 01
01 05 00 03 82 01 0F 00 30 82 01 0A 02 82 01 01
00 B5 42 F1 89 F0 7D 0D 70 44 D3 CA 3D 6A 94 A8
D8 5A A7 C9 CC 02 8A 23 F7 AB F8 87 A7 3A 60 FC
EC DE 1D 25 8C 27 8D 19 C3 21 84 5C D4 D7 8A 2E
32 BF 66 C1 51 8A 94 B3 72 06 BE D5 B8 41 15 DF
7F C4 1B 55 F4 4A 60 CC 54 0B B8 AD 3F AF AF 71
FC 17 42 78 72 AC 8D 5E BE C3 29 D8 98 6B AA DB
90 86 AB 08 A7 19 FE 33 FB FB 56 23 EE 33 3E F3
95 98 09 38 6C B9 A1 F9 F5 18 94 1B 8E CF D2 F0
27 4B BC 24 52 0C 70 E4 A6 B9 EB 96 60 14 09 BB
7C B7 FF E4 B0 17 A4 28 68 55 D5 1E 5E 84 57 CD
9C E0 FC 35 31 A7 53 80 BE 30 82 94 34 15 C0 75
DB EF A4 BB 01 D7 E6 17 83 52 8B 2E 0E B1 DA C5
32 2D B6 F7 EB 2F AE 3A ED DE 3B FA 3A F8 F2 5D
BC 84 BC E3 F8 BB 1B 5D 85 06 AB C2 B8 8A 82 8E
9D 38 71 79 54 7E 91 FA 7A 14 CF 20 AF 5E 54 22
F1 B6 D3 D2 89 21 43 75 65 3D 74 4B D7 2E 78 52
03 02 03 01 00 01

対応する ASN.1 は次のとおりです。

SEQUENCE {
    
    
  SEQUENCE {
    
    
    OBJECT IDENTIFIER 1.2.840.113549.1.1.1 rsaEncryption (PKCS #1)
    NULL
  }
  BIT STRING {
    
    
    SEQUENCE {
    
    
      INTEGER 228821442744892501318627381803596567786967739438082404228277133253533…
      INTEGER 65537
    }
  }
}

2.2.1.2 テキスト形式 pem

インターネットで使用されているいくつかのセキュリティ関連標準では、ASN.1 データ形式が定義されています。ASN.1 データ形式は通常、バイナリ エンコーディングである Basic Encoding Rules (BER) または Distinguished Encoding Rules (DER) を使用してエンコードされます。バイナリ データ形式の欠点は、電子メールやテキスト ドキュメントなどのテキスト送信では交換できないことです。テキストベースのエンコーディングの利点は、一般的なテキスト エディタを使用して簡単に変更できることです。たとえば、ユーザーはコピー アンド ペースト操作で複数の証明書を連結して証明書チェーンを形成できます。

Privacy Enhanced Mail (PEM、Privacy Enhanced Mail) は、Message Encapsulation (RFC 934) における Marshall Rose の提案に基づいた RFC 1421 にまで遡ることができます。当初は「PEM カプセル化メカニズム」、「カプセル化された PEM メッセージ」、または「PEM 印刷可能エンコーディング」として知られていましたが、現在ではこの形式は「PEM エンコーディング」と呼ばれることもあります。これは文法の標準形式を指定し、行末文字をキャリッジ リターン/ライン フィードのペアとして宣言します。

簡単に言えば、実際には です二进制内容用 Base64 编码一下，然后加上-----BEGIN label-----形式的头部和-----END label-----形式的尾部。

ただし、RFC は既存の実装を検討し、その実装が何を行うかを文書化することによって作成されます。RFC は最初から書かれたものではなく、既存の信頼できる文書に基づいたものでもありません。したがって、特定の実装と相互運用したい場合は、実装のソース コードを調べて、何がサポートされているかを判断する必要がある場合があります。

たとえば、OpenSSL はこれらBEGINとENDフラグを crypto/pem/pem.h で定義します。以下は、サポートされるすべての BEGIN タグと END タグを含むヘッダー ファイルの抜粋です。

# define PEM_STRING_X509_OLD     "X509 CERTIFICATE"
# define PEM_STRING_X509         "CERTIFICATE"
# define PEM_STRING_X509_TRUSTED "TRUSTED CERTIFICATE"
# define PEM_STRING_X509_REQ_OLD "NEW CERTIFICATE REQUEST"
# define PEM_STRING_X509_REQ     "CERTIFICATE REQUEST"
# define PEM_STRING_X509_CRL     "X509 CRL"
# define PEM_STRING_EVP_PKEY     "ANY PRIVATE KEY"
# define PEM_STRING_PUBLIC       "PUBLIC KEY"
# define PEM_STRING_RSA          "RSA PRIVATE KEY"
# define PEM_STRING_RSA_PUBLIC   "RSA PUBLIC KEY"
# define PEM_STRING_DSA          "DSA PRIVATE KEY"
# define PEM_STRING_DSA_PUBLIC   "DSA PUBLIC KEY"
# define PEM_STRING_PKCS7        "PKCS7"
# define PEM_STRING_PKCS7_SIGNED "PKCS #7 SIGNED DATA"
# define PEM_STRING_PKCS8        "ENCRYPTED PRIVATE KEY"
# define PEM_STRING_PKCS8INF     "PRIVATE KEY"
# define PEM_STRING_DHPARAMS     "DH PARAMETERS"
# define PEM_STRING_DHXPARAMS    "X9.42 DH PARAMETERS"
# define PEM_STRING_SSL_SESSION  "SSL SESSION PARAMETERS"
# define PEM_STRING_DSAPARAMS    "DSA PARAMETERS"
# define PEM_STRING_ECDSA_PUBLIC "ECDSA PUBLIC KEY"
# define PEM_STRING_ECPARAMETERS "EC PARAMETERS"
# define PEM_STRING_ECPRIVATEKEY "EC PRIVATE KEY"
# define PEM_STRING_PARAMETERS   "PARAMETERS"
# define PEM_STRING_CMS          "CMS"

PEM ファイルのファイル形式:

-----BEGIN (label)-----
/*　　data　　*/
-----END (label)-----

ラベルは、エンコードされたメッセージのタイプを決定します。通常、これらのタイプは次のとおりです:
「CERTIFICATE」、「CERTIFICATE REQUEST」、「PRIVATE KEY」、「ENCRYPTED PRIVATE KEY」、および「X509 CRL」。

たとえば、X.509 公钥マークアップは次のとおりです。

-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----

X.509 证书は次のようにマークされています:

---- BEGIN CERTIFICATE----
/* 证书 */
----END CERTIFICATE----

X.509 证书请求は次のようにマークされています:

-----BEGIN CERTIFICATE REQUEST-----
/*    CSR    */
-----END CERTIFICATE REQUEST-----

PKCS #1 公钥は次のようにマークされています:

-----BEGIN RSA PUBLIC KEY-----
-----END RSA PUBLIC KEY-----

PKCS #1 加密私钥は次のようにマークされています:

-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

PKCS #8 未加密私钥は次のようにマークされています:

-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----

PKCS #8 暗号化後の秘密キーの署名は次のとおりです。

-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----

2.2.2 ファイル拡張子

証明書の形式がバイナリ形式とテキスト形式であることは以前からわかっていたため、ユーザーが証明書のプロトコルやその他の情報を識別しやすくするために、いくつかのサフィックスが合意されています。サフィックスを通じて、ユーザーはおそらく、証明書に関する何らかの情報を知っていることになります。証明書

ファイル拡張子	ファイルの種類	説明する
*.CRT	バイナリまたはテキスト形式	Certificate の略語。証明書ファイルを意味し、秘密キーではなく証明書情報のみが含まれます。主に Linux システムで使用されます
*.CER	バイナリまたはテキスト形式	上記の crt とほぼ同じで、主に Windows で使用される証明書ファイルを意味します。
*.PEM	テキスト形式	これはプロトコルとサフィックスの両方であり、テキスト形式は IDE でエンコードされ、通常は証明書または秘密キー、または証明書と秘密キーの両方を保存します。 .PEM ファイルに秘密キーのみが含まれている場合、通常は .KEY ファイルに置き換えられます。
*.THE	バイナリ形式	これはプロトコルとサフィックスの両方であり、バイナリ形式の IDE コードであり、通常は証明書または秘密キーを保存するか、証明書と秘密キーの両方を含みます。
.PFX または .P12	バイナリ形式	証明書と秘密キーの両方が含まれており、通常はパスワードで保護されています。
.JKS	バイナリ形式	証明書と秘密キーの両方が含まれており、通常はパスワードで保護されています。

上の表から次のことがわかります。

• CER または CRT は証明書と同義であり、秘密キーは含まれません。

• der と pem はプロトコルであり、バイナリで保存されているかテキストで保存されているかをユーザーに知らせるためのサフィックスとして直接使用できますが、特定のコンテンツは証明書またはキーである可能性があります。

• pem 形式は、cat コマンドを使用して直接表示できます。「—–BEGIN…」で始まり、「—–END…」で終わります。

• 二进制格式无法直接查看，可以通过 openssl x509 -text -in server.cert 进行查看，此时会转换为以”—–BEGIN…”开头, “—–END…”结尾

• 二进制 和 文本之间PEM可以互相转换 ，因为只是 编码格式的转换 ，你也可以把pem转换为二进制格式

• PFX和JKS 是包含证书和私钥的，其他的一定都不含。

  • 利用Java的一个叫”keytool”的工具,可以将PFX转为JKS,当然了,keytool也能直接生成JKS
  • 此外，证书含有私钥，那么别人获取证书时，要是导出私钥怎么办？很简单，在创建pfx时，有参数可以禁止导出私钥；即使允许导出私钥，你需要提供导出私钥的密码，这个密码保证了不是任何人都能随意导出私钥

• BER是编码的基础规范，一般不作为文件的具体后缀名

• .csr 是证书请求文件，由客户生成，然后提供给CA签发机构，是由 RFC 2986定义的PKCS10格式，包含部分/全部的请求证书的信息，比如，主题, 机构，国家等，并且包含了请求证书的公玥，这些被CA签发机构中心签名后返回一张证书。返回的证书是公钥证书（只包含公玥不含私钥）。

  也就是说公司名称等这些参数是放在请求文件中的，并且含有公钥，一并交给CA机构，公钥怎么来的？是利用私钥生成的，因此这个步骤入参需要私钥。虽然用到了私钥，但是产出的请求文件中，一定不含私钥。

  证书签名请求是申请人向证书颁发机构发送的一条消息，用于申请数字身份证书。

  有 CSR 必定有 KEY，是成对的，CSR 最终变成为证书 crt，和私钥 key 配对使用。证书下发后，CSR 就没有用了，只是在交时候需要。

3. 常见Web服务软件及证书格式

证书的使用分为2种场景，一种是web服务器，就是我们通过浏览器访问web网站时，由网站侧开启Https，通过443端口进行安全通信，背后实际上是web服务器在起作用，而web服务器能只能识别指定的证书格式；另一个场景就是端到端通信，就是socket编码，此时需要根据不同的语言，来实现具体的证书格式。

一般的な Web サービス ソフトウェアは、通常、OpenSSL と Java という 2 つの基本的な暗号化ライブラリに基づいています。

• Tomcat、Weblogic、JBoss などの Web サービス ソフトウェアは、通常、Java が提供するパスワード ライブラリを使用します。Java Development Kit (JDK) ツールキットの Keytool ツールを使用して、Java Keystore (JKS) およびキーストア形式の証明書ファイルを生成します。

  .keystore と .jks は両方とも、Java がキーを保存するために使用するファイルです。これにより、ユーザーは、(デジタル署名を介して) 自己認証 (ユーザーが他のユーザー/サービスに対して自分自身を認証する) またはデータの整合性と認証サービス用に、自分の公開/秘密キーのペアと関連する証明書を管理できるようになります。また、ユーザーは通信相手の公開鍵を (証明書の形式で) 保存することもできます。

• Apache や Nginx などの Web サービス ソフトウェアは通常、OpenSSL ツールによって提供される暗号化ライブラリを使用して、PEM、KEY、CRT などの形式で証明書ファイルを生成します。

• Websphere、IBM Http Server (IHS) などの IBM の Web サービス製品は、通常、IBM 製品に付属の iKeyman ツールを使用して KDB 形式の証明書ファイルを生成します。

• Microsoft Windows Server のインターネット インフォメーション サービス (IIS) サービスは、Windows に付属の証明書ライブラリを使用して、PFX 形式の証明書ファイルを生成します。

参考

SSL証明書の基本概念 リテラシー
暗号（2）：暗号規格 - X.509とPKCSシリーズ
SSL/TLSデジタル証明書の各種フォーマット解説
SSL証明書の各種フォーマットの詳細解説