SSLに関して、証明書と鍵の違いは何ですか？

証明書には公開鍵が含まれる。

証明書には、公開鍵の他に、発行者、証明書の使用目的、その他のメタデータなどの追加情報が含まれる。

通常、証明書はそれ自体がCAの秘密鍵を使用して証明局(CA)によって署名される。これにより、証明書の真正性が検証されます。

この2枚の写真ですべてがわかりました。 linuxvoice

ソース。情報源: infosecinstitute

A社が鍵ペアを持っていて、公開用の公開鍵を公開する必要があるとします(Webサイト上では別名ssl)。

• A社は、鍵ペアの証明書を取得するために、認証局(CA)に証明書要求(CR)を行わなければならない。
  
• A 社のキー・ペアの公開鍵は、秘密鍵ではなく、証明書要求の一部として含まれる。
  
• その後、CAはA社の身元情報を使用して、要求が証明書発行のためのCAの基準を満たしているかどうかを判断する。
  
• CAは、要求がCAの証明書発行の基準を満たしているかどうかを判断する。
  

つまり、有効なCAの秘密鍵で署名されたA社の公開鍵をA社の証明書と呼ぶ。

例を挙げて説明します。

通常のキーペアベースのPKIでは、秘密鍵と公開鍵がある。

証明書ベースのシステムでは、秘密鍵と証明書がある。証明書は公開鍵よりも多くの情報を保持している。

デモ（証明書と秘密鍵を生成できます）。http://www.selfsignedcertificate.com/ ](http://www.selfsignedcertificate.com/)

秘密鍵ファイルと証明書ファイルをダウンロードして開くと、証明書ファイルには以下のように多くの情報が含まれていることがわかります。

あなたの生成した証明書(テキストエディタで開く)と秘密鍵(テキストエディタで開く)は、このサイトから一致させることができます。 https://www.sslshopper.com/certificate-key-matcher.html

証明書がクライアントの秘密鍵と一致していれば、その証明書がクライアントから与えられたものか、クライアントの信頼できるエージェント(CA)から与えられたものであることをクライアントは確信していることになります。

ただし、秘密鍵と証明書だけの通信には問題がある。

なぜなら、誰でも自分の証明書と秘密鍵を生成することができるので、単純な握手だけでは、サーバが証明書の公開鍵と一致する秘密鍵を知っているということ以外は、サーバについて何も証明できないからです。この問題を解決する 1 つの方法は、クライアントが信頼できる 1 つ以上の証明書を セット にしておくことです。証明書がセットに含まれていない場合、サーバは信頼できません。

この単純なアプローチにはいくつかの欠点があります。サーバーは、証明書の公開鍵を新しい鍵に置き換える「鍵の回転」により、時間の経過とともにより強力な鍵にアップグレードできるようになるはずです。残念なことに、現在では、本質的にサーバー構成の変更により、クライアントアプリを更新しなければなりません。これは、サーバーがアプリ開発者の管理下にない場合、例えばサードパーティのWebサービスの場合などに特に問題があります。このアプローチは、アプリがウェブブラウザや電子メールアプリなどの任意のサーバーと通信する必要がある場合にも問題があります。

これらの欠点に対処するために、サーバーは通常、証明書発行者（CA）と呼ばれる有名な発行者の証明書を使用して構成されています。サーバと同様に、CAは証明書と秘密鍵を持っています。サーバの証明書を発行する際、CAはその秘密鍵を使用してサーバ証明書に署名します。その後、クライアントは、サーバがプラットフォームに知られたCAが発行した証明書を持っていることを確認することができます。

しかし、CAを使用することは、いくつかの問題を解決する一方で、別の問題を導入しています。CAは多くのサーバに対して証明書を発行しているため、目的のサーバと通信しているかどうかを確認するための何らかの方法が必要になります。これに対処するために、CAが発行する証明書は、gmail.comのような特定の名前か、*.google.comのようなワイルドカードのホストセットのいずれかでサーバを識別します。

以下の例では、これらの概念をもう少し具体的に説明します。コマンドラインからの以下のスニペットでは、opensslツールのs_clientコマンドがWikipediaのサーバ証明書情報を見ています。ポート443がHTTPSのデフォルトなので、これを指定しています。このコマンドはopenssl s_clientの出力をopenssl x509に送り、X.509標準に従って証明書情報をフォーマットします。具体的には、サーバ名情報を含むsubjectと、認証局を識別するissuerを要求します。

$ openssl s_client -connect wikipedia.org:443 | openssl x509 -noout -subject -issuer
subject= /serialNumber=sOrr2rKpMVP70Z6E9BT5reY008SJEdYv/C=US/O=*.wikipedia.org/OU=GT03314600/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org
issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA

RapidSSL CAによって、証明書が発行されたことがわかる。

0x1&

ご覧のように、CAからサーバに送信されるこの追加情報により、クライアントはサーバと通信しているかどうかを簡単に知ることができる。

SSL 証明書は、ウェブサイトの安全な接続を保証する信頼できる認証局から取得されます。SSL証明書には通常、認証のロゴと、コンピュータに送信されるデータを暗号化・復号化するために必要な公開鍵が含まれています。SSLキー機能

いくつかのSSL キーはセッション中に生成することができます。これらのキーは、コンピュータとの間で送受信される情報の暗号化と復号化に使用されます。

ライフサイクルの違い

証明書はSSL鍵よりも長持ちします。SSL証明書は認証局から取得し、銀行や企業が定期的に更新できるようになっています。一方、SSLキーやセッションキーは、セッション中に一意に生成され、セッション終了時に破棄されます。 続きはこちら

OK、技術的なことをしていない人にもわかるように分解してみましょう。

このように考えてください。証明書は銀行の貸金庫のようなものです。この中には多くの重要なものが入っており、一般的にはあなたの身元を示すものが入っています。証明書には公開鍵があり、それを開くためには秘密鍵が必要です。

貸金庫も証明書と同じように、開けるのに2つの鍵が必要です。
貸金庫の場合、銀行員の鍵は銀行に保管され、公開鍵は証明書と一緒に保管されるので、公開鍵と同じようなものです。証明書を手に入れる」ために必要な秘密鍵を持っているわけですが、貸金庫の例では公開鍵に加えて秘密鍵も必要になります。

貸金庫を実際に開ける前に、まず身元を確認しなければなりません (証明書要求のようなもの)。これは、証明書要求を行い、認証局から証明書を取得するようなものです（本人確認ができ（信頼され）、正しい鍵を持っている限り）。