作って学ぶTLS 1.3

Appearance

X.509証明書 ​

なりすましの対策とPKIのページで、電子証明書は「所有者の名前と公開鍵を結びつけ、認証局が署名したデータ」だと説明しました。本ページでは、電子証明書が実際にどのようなデータで構成されているのかを説明します。

本ページは、実装中に必要な情報を確認するための資料としても使えるようにまとめています。実装で直接扱うフィールドは一部なので、すべて覚える必要はありません。

証明書の構造 ​

証明書の形式はITU-TのX.509で定められており、インターネット上で利用するためのフィールドや拡張の使い方はRFC 5280で規定されています。ここでは、RFC 5280 §4.1に沿って証明書の構造を説明します。

証明書のフィールドは表1のとおりです。1〜11がtbsCertificate、12と13が署名に関する部分です。なお、7と8はsubjectPublicKeyInfoという1つのフィールドにまとめられており、表にはその内部のフィールド名を記載しています。

#フィールドASN.1名意味
1バージョンversionX.509規格のバージョン。現在はv3（値は2）
2シリアル番号serialNumberCAが証明書ごとに割り当てる識別番号。同じCAが発行する証明書の間で一意となる
3署名アルゴリズムsignatureCAが署名に使用するアルゴリズム
4発行者issuer証明書を発行したCAの名前（DN）
5有効期間validitynotBeforeとnotAfterの組
6サブジェクトsubject証明書の所有者を表す名前（DN）
7公開鍵アルゴリズムalgorithm所有者の公開鍵のアルゴリズム
8公開鍵subjectPublicKey所有者の公開鍵のデータ本体
9発行者識別子issuerUniqueIDCAの識別子（オプション。RFC 5280準拠のCAは生成禁止）
10サブジェクト識別子subjectUniqueID所有者の識別子（同上）
11エクステンションextensions用途や代替名などの拡張情報（v3のみ・オプション）
12署名アルゴリズムsignatureAlgorithm署名に使用したアルゴリズム（3と同一）
13署名値signatureValueDER符号化したtbsCertificate（1〜11）全体に対するCAのデジタル署名

X.509証明書のフィールド

9と10はRFC 5280で生成が禁止されているため、実際の証明書ではほとんど見かけません。

3と12には同じ署名アルゴリズムが記載されています。これは、RFC 5280が両者に同一のアルゴリズム識別子を指定するよう規定しているためです（§4.1.1.2・§4.1.2.3）。

外側の12は署名の対象に含まれませんが、内側の3はtbsCertificateの一部として署名されています。両者を比較することで、署名アルゴリズムの情報に食い違いがないことを確認できます。

v3拡張（extensions） ​

表1の11番にあたるエクステンションには、証明書の用途や検証に関わる重要な情報が入っています。TLSの証明書検証で使われる代表的な拡張を表2にまとめます。

拡張意味
Subject Alternative Name（SAN）証明書が有効なホスト名やIPアドレスなどの一覧。ホスト名の検証に使う
Basic ConstraintsCA証明書かどうか（CA:TRUEならCA）。チェーン検証で使う
Key Usage鍵の用途（デジタル署名・証明書への署名など）
Extended Key Usage用途の限定（サーバー認証・クライアント認証など）

TLSの検証で使われる代表的な拡張

かつてはサブジェクトのCN（Common Name）に記載されたホスト名を使っていましたが、現在はSANを使ってホスト名を検証します。

The Common Name RDN MUST NOT be used to identify a service because it is not strongly typed (it is essentially free-form text) and therefore suffers from ambiguities in interpretation.

訳）Common Name RDNは、強く型付けされておらず（実質的に自由記述のテキストである）解釈に曖昧さが生じるため、サービスの識別に使用してはならない。

引用元: RFC 9525 §3 Service Identity

RFC 9525（2023年）は、それまでのRFC 6125を置き換えたものです。RFC 6125ではSANがない場合の最後の手段としてCNの参照を認めていましたが、RFC 9525ではそれも認められなくなりました。発行側でも、CA/Browser ForumのBaseline RequirementsがsubjectAltNameを必須とし、CNは非推奨としています。Goのcrypto/x509もバージョン1.15から、標準ではCNへのフォールバックを行わなくなっています。

RFC 5280の§4.2.1では、15種類の標準拡張が規定されています。表2で紹介した4種類以外を表3にまとめます。

拡張意味
Authority Key Identifier発行者の鍵の識別子。チェーンを辿るときの手がかり
Subject Key Identifierこの証明書の鍵の識別子
Certificate Policies証明書のポリシー。DV・OV・EVなどの種類もOIDで識別できる
CRL Distribution Points失効リストのURL
Issuer Alternative Name発行者の別名
Subject Directory Attributes所有者の属性情報
Name ConstraintsCAが発行できる名前空間の制限
Policy Constraintsポリシー検証の制約
Policy MappingsCA間でポリシーを対応づける
Inhibit anyPolicyanyPolicyの無効化
Freshest CRL差分CRLの所在

RFC 5280が定義するその他の標準拡張

さらに、RFC 5280 §4.2.2で規定された拡張や、ほかのRFCで追加された拡張もあります。実際のWebサイトの証明書でよく見かけるものを表4にまとめます。

拡張意味
Authority Information Access（AIA）発行者証明書やOCSPレスポンダのURL（RFC 5280 §4.2.2.1）
Signed Certificate Timestamp（SCT）Certificate Transparencyのログが証明書の登録を受け付けたことを示す情報（RFC 6962）

Webサイトの証明書でよく見かける拡張

証明書の種類 ​

サーバー証明書は、発行時に認証局が何を確認するかによって分類されます。代表的なものはDV、OV、EVの3種類ですが、CA/Browser ForumのBaseline Requirementsでは、個人の本人確認を行うIVも定義されています。

種類審査プロセス主な利用先
DV（Domain Validation）ドメインの管理権限を確認する。DNSレコードやファイルの設置などによって確認でき、組織の実在性は審査しない。自動発行にも向いている個人サイトから大規模サイトまで、幅広いWebサイト
IV（Individual Validation）ドメインの管理権限に加えて、個人の本人確認を行う個人の身元情報を証明書に記載したいサイト
OV（Organization Validation）ドメインの管理権限に加えて、公的な記録などを使って組織の実在性を確認する。証明書に組織名が入る組織の身元情報を証明書に記載したい企業や学校などのサイト
EV（Extended Validation）OVよりも詳細な基準に基づき、組織の法的な実在性や申請者の権限などを確認する組織の身元情報をより厳格な審査によって証明したいサイト

サーバー証明書の種類

どの種類でも、TLSとしての暗号強度が変わるわけではありません。同じ署名アルゴリズムや鍵長を利用でき、違いは主に発行時に認証局が何を確認したかという点です。また、ドメイン名に対する保証の水準はどの種類でも同じです。

このように、公開認証局がサーバー証明書を発行する際には、所定の確認手続きが必要です。もっとも基本的なDVでも、ドメインの管理権限を確認できなければ証明書は発行されません。そのため、無関係な第三者が他人のドメインの証明書を取得することは容易ではありません。こうした審査が、証明書に記載された名前と公開鍵の対応を信頼できる根拠になっています。

実際の証明書 ​

opensslを使うと、実際の証明書の内容を確認できます。

sh
$ echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            06:24:d0:ab:31:15:58:78:0b:7d:52:13:b9:63:18:31
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
        Validity
            Not Before: Jul 29 22:10:08 2026 GMT
            Not After : Oct 27 22:17:21 2026 GMT
        Subject: CN=example.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    ...
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier:
                83:03:FD:E7:F6:F5:4A:4D:15:41:F4:ED:22:16:D3:32:0A:3E:CA:66
            Authority Information Access:
                CA Issuers - URI:http://i.cf-i.ssl.com/Cloudflare-TLS-I-E3.cer
                OCSP - URI:http://o.cf-i.ssl.com
            X509v3 Subject Alternative Name:
                DNS:example.com, DNS:*.example.com
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
                ...
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Key Usage: critical
                Digital Signature
            CT Precertificate SCTs:
                ...
    Signature Algorithm: ecdsa-with-SHA256
    Signature Value:
        ...

出力が長いため、公開鍵や署名の16進数の値は...に置き換えています。

Dataの部分が、表1の1〜11にあたるtbsCertificateです。Issuerには証明書を発行した中間認証局の名前が、SubjectにはCN=example.comが入っています。

X509v3 extensionsの部分が、表1の11にあたるv3拡張です。表2で紹介したSubject Alternative Nameには、example.comと*.example.comが記載されています。SubjectにもCN=example.comがありますが、ホスト名の検証には使いません。また、表4で紹介したAIAとSCTも含まれています。

次のページでは、証明書チェーンを使って、この証明書が信頼できるものかを検証する仕組みを説明します。