TLS 証明書の簡易ガイド 📝

JayP が公共のインターネット経由で youtube.com に接続したいとします。コミュニケーションが始まる前に、いくつかの懸念が生じます。

実際に YouTube と通信していることをどうやって確認できるのでしょうか? (認証)

JayP は自分のメッセージを誰も傍受していないことをどのようにして知ることができるのでしょうか? (秘密保持)

また、誰もメッセージを変更していないことをどうやって確認できるのでしょうか? （威厳）

さて、それぞれの問題に個別に取り組んでみましょう。まず第一に、JayP はYoutubeの身元を確認する必要があります。そのためには、Youtube の公開キーが必要です。公開キーは YouTube の ID を表します。

問題

問題は、攻撃者がインターネット上のあるコンピュータから別のコンピュータへのリクエストを傍受し、中間者攻撃を開始する方法を考え出したことです。この種の攻撃では、攻撃者 Chady は自分の公開キーを挿入し、JayP に Youtube と通信していると思わせますが、実際には Chady と通信しています。

Chady はこっそり侵入し、彼の公開鍵を送信します。

今思うと、怖いですよね？ログイン資格情報やクレジット カードの詳細などの個人情報の窃取から、マルウェアの配布やその他の悪意のある目的まで、この種の攻撃で何が可能になるかを想像してみてください。では、JayP はどのようにして、受け取った公開キーが本当に Youtube から来たものであると確信できるのでしょうか?そこでデジタル証明書が登場します。(TADAAA)

これらは、公開キーが悪意のある Chady からのものではなく、実際に Youtube からのものであることを保証します。実は電子証明書はHTTPSだけでなく、メールやIoT、VPNにも使えるんです…。

TLS 証明書内の情報

デジタル証明書にはかなりの量の情報が含まれています。最も重要な情報を見てみましょう。

• 発行者は、この証明書に署名したサードパーティです。これについては後ほど説明します。基本情報には、通称、組織、国などが含まれます。

• もちろん、デジタル証明書には、その前と後ではない 2 つの重要なフィールドを持つValidityも含まれます。

• 件名は証明書の所有者であり、この場合は Youtube になります。件名には、一般名、住所、そして最も重要な公開キーなどの情報が含まれます。

• 最後に、デジタル証明書にはそのSignatureが含まれます。これは、この証明書が本物であることを証明する発行者によって署名された署名です。

  
  

  

デジタル証明書に署名するのは誰ですか?

デジタル証明書は、認証局と呼ばれる団体 (DigiCert、Comodo、Symantec、Google Trust Services など) によって署名されます。

しかし、ちょっと待って、認証局とは何でしょうか?

簡単に言うと、認証局はデジタル証明書の発行を担当する信頼できるサードパーティ組織です。

認証局は独自の公開鍵と秘密鍵を持っています。そこから、署名がどのように行われるかを説明しましょう。

デジタル証明書に含まれる前述の情報は、たとえばSHA-256 アルゴリズムを使用してハッシュされます。ハッシュが生成された後、認証局は RSA 非対称キー暗号化を使用して秘密キーを使用してハッシュを暗号化します。この暗号化されたハッシュは証明書の署名であり、認証局の公開キーを使用してのみ復号化できます。この証明書に署名した認証局の公開キーを持っている人は誰でも、証明書を復号化して、証明書が本物であり、改ざんされていないことを確認できます。

ブラウザが証明書を受け取ると、同じハッシュ アルゴリズム (この例では SHA-256) を使用して、ブラウザ側のすべての情報をハッシュします。次に、認証局の公開鍵を使用して署名を復号し、認証局からハッシュを受け取ります。両方のハッシュが一致する場合、ブラウザは、この証明書が本当に主張された認証局からのものであることを確認できます。

認証局の階層

認証局には、ルート認証局と中間認証局という階層が存在します。

これらのルート CA は、実際にはサーバーのデジタル証明書を直接発行しません。代理として機能する中間 CA に対してのみデジタル証明書を発行します。中間 CA は、別の中間 CA に対して、またはサーバーに対して直接デジタル証明書を発行できます。

したがって、ルート CA からサーバーまでの信頼のチェーンが存在します。

オペレーティング システムには、信頼されたルート認証局のリストであるトラスト ストアがバンドルされています。このリストは、Apple や Microsoft などのオペレーティング システムを製造する企業によって管理されています。これらはすべて、ルート認証局がその信頼性と有効性を証明する 1 つ以上の監査を受けることを必要とします。

これらすべてがこの図にどのように収まるでしょうか?

最初からプロセス全体を視覚化してみましょう。

まず、youtube.com がまったく新しいスタートアップであると仮定しましょう。公的に利用可能なインターネット上で安全である必要性を理解しているため、Youtube は信頼できるデジタル証明書を所有し、それを訪問者に提示する必要があります。

ステップ 1: YouTube がデジタル証明書を購入する

まず、Youtube は中間認証局を探します。中間認証局はサーバーとルート認証局の間の仲介者であることに注意してください。 Youtube の場合、Google は Google Trust Services と呼ばれる独自の認証局を持っています。

中間 CA を選択した後、Youtube は証明書署名リクエストを作成します。証明書署名リクエストには、一般名、組織、そして最も重要な Youtube の公開キーなど、Youtube のデジタル証明書に含まれる情報が含まれます。 Youtube は証明書署名リクエストを中間 CA に送信します。

中間認証局は、サブジェクトとも呼ばれる所有者に関する情報を含む CSR を検証します。次に、中間証明書に関する情報である発行者情報や有効性などのフィールドを追加し、署名プロセスで前述したように、このすべての情報に署名します。署名後、中間認証局は YouTube のデジタル証明書を送り返します。

Youtube は、新しく購入したデジタル証明書を Web サーバーに添付できるようになりました。

ステップ 2: JayP は youtube.com に接続してフィットネス ビデオを視聴します

彼が Youtube に接続すると、Youtube は独自の証明書と中間認証局の証明書を送信します。ルート認証局は JayP のオペレーティング システムで使用できるため、送信されません。 Youtube の証明書には、中間認証局である発行者の情報が含まれます。したがって、ブラウザは、この証明書が Google トラスト サービス中間認証局によって署名されていることを認識し、その証明書を取得します。前述したように、デジタル証明書には情報と署名が含まれます。ブラウザはすべての情報をハッシュしてそのハッシュ値を取得します。次に、発行者の公開鍵、つまり中間認証局の公開鍵を使用して署名を復号化します。繰り返しになりますが、署名は発行者の公開キーを使用してのみ復号化できることに注意してください。その後、ブラウザーは 2 つのハッシュ値を比較し、それらが同じであれば、チェーンのこの部分が検証され、ブラウザーは中間認証局の検証に進みます。これは、説明したように、中間認証局は直接信頼されていないためです。オペレーティングシステム。

さて、ブラウザは Google Trust 中間認証局の証明書を検証します。この中間証明書は、Google Trust Services のルート認証局によって署名されています。このステップの前に、エンド証明書とルート証明書の間に多くの中間認証局が存在する可能性があり、チェーンの各部分で同じ検証プロセスが発生することに注意してください。

この例では、1 つのみに限定します。前述したように、中間認証局の証明書の署名は、ルート認証局の公開鍵を使用して検証されます。ルート認証局に到達すると、そこでチェーンが終了します。自己署名されたルート認証局は、JayPee のオペレーティング システムの信頼ストアで利用可能になります。

それでおしまい！この検証の後、ブラウザーには、ブラウザーにあるものと同様の、見栄えの良い鍵のアイコンが表示されます。これで、通信が本当に Youtube で行われ、安全であることが保証されました (万歳)

3種類のドメイン証明書

最後に、3 つの主要なタイプの TLS 証明書について簡単に説明します。

1) 単一ドメイン証明書

単一ドメイン証明書は、単一の完全修飾ドメイン名を保護するように設計されています。これは、証明書が 1 つの特定のドメインに対してのみ有効であり、サブドメインや追加のドメインはカバーされないことを意味します。たとえば、ドメイン「www.youtube.com」の場合、単一ドメイン証明書はそのドメインのみを保護し、「academy.youtube.com」や「blog.youtube.com」などの他のバリエーションは保護しません。

使用例: 単一ドメイン証明書は、追加のサブドメインを必要としない単一の Web サイトまたは Web アプリケーションがある場合に最適です。これらは、特定のドメインを保護するための最も簡単でコスト効率の高いオプションです。

2) ワイルドカード証明書

次に、ワイルドカード証明書があります。これは、単一の証明書を使用してメイン ドメインとそのすべてのサブドメインに対して発行される TLS 証明書の一種です。ワイルドカード文字のアスタリスクは、共通名 (CN) フィールドまたはサブジェクト代替名 (SAN) フィールドで使用され、指定されたドメインの下のサブドメインが対象であることを示します。たとえば、「 .youtube.com」のワイルドカード証明書がある場合、「youtube.com」、「academy.youtube.com」、「blog.youtube.com」などが保護されます。

使用例:ワイルドカード証明書を使用すると、サブドメインごとに個別の証明書を管理および更新する必要がなくなります。ただし、ワイルドカード証明書は 1 レベルのサブドメインのみをカバーすることに注意することが重要です。たとえば、「*.youtube.com」のワイルドカード証明書は「academy.blog.youtube.com」をカバーしません。

3) マルチドメイン (SAN) 証明書

サブジェクト代替名証明書とも呼ばれるマルチドメイン証明書を使用すると、単一の証明書内で無関係な複数のドメインを保護できます。保護される各ドメインまたはサブドメインは、証明書のサブジェクト代替名 (SAN) 拡張子にリストされます。

たとえば、Google やその他の大企業は、これらのマルチドメイン証明書を使用します。主な利点の 1 つは、証明書管理の簡素化です。Google は、それぞれ独自のドメインまたはサブドメインを持つ多くの Web サービスとアプリケーションを運用しています。マルチドメイン証明書を使用すると、複数のドメインまたはサブドメインの証明書の管理を 1 つの証明書に統合できます。これにより、証明書の発行、更新、監視のプロセスが合理化されます。

次回の記事では、TLS による暗号化について説明します。