Zenn
🙌

デジタル証明書まとめ

2024/11/17に公開
Web
Security
エンジニア
暗号
TLS
tech

はじめに

SSL/TLSハンドシェイクの一部であるサーバ証明書の検証プロセスがややこしいので、整理してみました。

対象

・サーバやネットワーク関連の基礎知識を習得されている方

デジタル証明書とは

デジタル証明書とは、X.509で規格化され、WEBサーバなどにインストールされ、自身の真正性を保証するものです。
※真正性：例えばWEBサーバAが、WEBサーバAであることを保証するもの

※以下はサンプルです。

classDiagram
    class "X.509 Certificate" {
        Version: v3
        Serial Number: 4e:b7:13:2e:9c:d1
        Signature Algorithm: sha256WithRSAEncryption
        
        Issuer
        - CN = Example Root CA
        - O = Example Corp
        - C = JP

        Validity
        - Not Before: 2024-01-01
        - Not After: 2025-01-01

        Subject
        - CN = www.example.com
        - O = Example Web Service
        - C = JP

        Subject Public Key Info
        - Algorithm: RSA
        - Public Key: (2048 bit)
        
        X509v3 Extensions
        - Basic Constraints
        - Key Usage
        - Subject Alternative Name

        Signature
        - Issuer's Digital Signature
    }
項目 内容
バージョン X.509証明書のバージョン
認証局デジタル署名 認証局の署名
シリアル番号 CAによって付与されるユニークな番号
認証局名 証明書に署名して発行した機関の名前
有効期間 開始日と終了日
所有者名 DN（Distinguished Name）によって表記
所有者の公開鍵情報 公開鍵、公開鍵のアルゴリズム
拡張領域 オプションで利用する領域
署名アルゴリズム CAが署名に利用したアルゴリズム

HTTPS通信をクライアントとWEBサーバＡ間で行う際に、クライアントは、WEBサーバから共有されるデジタル証明書を検証することで、通信先が本当にWEBサーバＡであるかどうかを確認します。

デジタル署名

デジタル証明書を検証するにあたって、デジタル署名という概念を理解する必要があります。
デジタル署名という名前がややこしいのですが、まとめると以下のようになります。

実体：ハッシュ値を送信者の秘密鍵で暗号化したもの
目的：データが改ざんされていないことの保証、否認防止

ただ、このデジタル署名は後続で説明する仕組み自体を指して使用されることも多いので、要注意です。
下記にデジタル署名を使用して、データの完全性の保証および否認防止が実現される仕組みを図示します。

検証方法としては、受信者が自身で計算したハッシュと、送信者から共有されたデジタル署名を復号したハッシュ値が一致するかどうかを確認します。
※補足
・データに手が加えられるとハッシュ値が変化します。ハッシュ値を比較することでデータに手が加えられていないことが保証されます。
・送信者の公開鍵で復号できたということは、送信元が鍵ペア（秘密鍵）を持つ送信者であることになります。

デジタル署名は、デジタル証明書含まれます。
私たちがHTTPS通信をする際には、アクセス先からデジタル証明書が共有され、そのデジタル証明書を検証することで、サーバの真正性をチェックしています。

なお、メッセージ認証コード（MAC）という似た概念があるのですが、
MACは共通秘密鍵を使用し、SSL/TLSハンドシェイクだともっと後で登場します。

PKI

今までの仕組みではその公開鍵の所有者が本当に信頼できるかどうか判断できません。
信頼できる第三者が公開鍵と秘密鍵の対応関係を保証する仕組みをPKIといいます。
この第三者のことを認証局といいます。

認証局が、サーバ証明書を発行するプロセスを記載します。
①申請者が公開鍵と秘密鍵の鍵ペアを作成する
➁CSR(Certificate Signing Request)を作成し、秘密鍵で署名し、認証局に共有する
③認証局が➁で共有されたCSRを審査する
④認証局がサーバ証明書を発行し、CAの秘密鍵で署名し、申請者に共有する

※認証局の公開鍵がクライアントにインストールされている必要がある理由を説明する
クライアントは、認証局の公開鍵を事前にインストールしておくことで、上記のデジタル署名を検証できます。

ただ、このやり方だとサーバ証明書を発行した認証局の公開鍵すべてを、クライアントにインストールしておく必要があります。
認証局の数は無数にあるため、こちらは現実的ではありません。

認証局はルート認証局を頂点とした階層構造になっており、信頼できる認証局配下の認証局が発行したデジタル証明書は、信頼できる仕組みになっています。
そのためクライアントとしては、階層上位にある認証局の公開鍵をルート証明書としてインストールしておきます。
※通常はプリインストールされています。

デジタル証明書の検証方法

ではようやく、アクセス先サーバにインストールされたデジタル証明書の検証方法を確認していきます。


①クライアントがWEBサーバにアクセスすると、WEBサーバにインストールされているデジタル証明書および、証明書チェーンを構成しているデジタル証明書（CA2,CA1）がクライアントに共有される
➁クライアントはルートCAの公開鍵を用いて、CA1のデジタル証明書を検証し、CA1の公開鍵を取り出す
③クライアントはCA1の公開鍵を用いて、CA2のデジタル証明書を検証し、CA4の公開鍵を取り出す
④クライアントは、CA2の公開鍵を用いて、サーバ証明書を検証する

このように一つ一つ証明書を検証することで、証明書に改ざんがないことを確認します。
その後に証明書に記載されている内容（有効期間やCommon Name）を確認することで、サーバ証明書の検証が完了し、アクセス先が安全だと保証することができます。

ただ、このサーバ証明書の検証はSSL/TLSハンドシェイクの一部として実行されます。
SSL/TLSハンドシェイクについては別途記事にしておりますので、詳しくはこちらをご確認ください。

SSL/TLSについてまとめてみた

おわりに

次は暗号化アルゴリズムについて深堀したいです。

Discussion