この記事を読んでくれている読者の中には、SSLデジタル証明書の使用方法については詳しい人もいるかもしれませんがSSLの歴史についてはあまり詳しくない人もいるかもしれません。今回はデジタル証明書の使い方の前に、デジタル証明書の核の部分について、あまり踏み込まないところを伝えていきたいと思います。

デジタル証明書とは鍵に資格情報(エンティティの ID に関する情報および識別を裏付ける他の情報)と制約情報を結合したもので、例として、”この証明書に関連した秘密鍵の所有者(エンティティ)はEmailに対して(制約情報)、ライアン・ハーストと署名する権利がある(資格情報)”と言い換えることができます。デジタル証明書の構想段階では、人やリソースといった主体（サブジェクト）と、ディレクトリ内の表示とを結びつける手助けをするために使われるはずでした。これが、証明書の中のサブジェクトネームが、ディレクトリサービス内でサブジェクトを一意に識別するのに使用されるDN(ディスティンギッシュネーム)の形式で構成されている理由です。

このことは、企業内のディレクトリからユーザーの暗号鍵を検索する際には理に適っているのですが、インターネット上には利用者のグローバルなディレクトリというものは存在しないため、合理的ではありません。この考え方が、ほとんどの大企業がディレクトリと認証局を彼らのアイデンティティ管理フレームワークの一部として導入した時期とほぼ同じ、1990年代半ばに導入が始まったSSLに対しても適用されたのです。

X.509の技術はテストされて世間に広く受け入れられており、またプロトコル設計者が抱えていた問題点に対する要件を満たしていたため、そのままの状態で取り込まれました。当時、証明書の所有者の概念を表す唯一の方法がコモンネーム（CN）だったため、彼らはそこにSSLサーバーのDNSネームを当てはめることを選択しました。そのことは技術的には許容可能でしたが、ユーザーの実名を設定することを意図していたフィールドの本来の目的を変えてしまいました。

SSLの仕様が確定した後、IETFはディレクトリサービスに関連付けられていない名前を設定することができる「サブジェクトの別名（SAN - SubjectAlternativeName）」という概念を含んだ、インターネット上で使用するためのX.509のプロファイルを公開しました。問題はこの考え方が標準化された90年代後半までには、誰もがコモンネームを使うことを決めていたということです。

このことは我々を間違った道へと導きました。まず、サーバーの多くは一つ以上のDNSネームやアプリケーションを備えており、コモンネームフィールドのみサポートした単体の証明書では一つ以上のDNSネームがある場合、動作しません。短期的にはDNSネーム毎に1枚の証明書を割り当てていましたが、このことは高コスト化を招き、さらにドメインネーム毎に一つのIPアドレスが必要となりました。

このアプローチのもう一つの問題は、アプリケーションがコモンネームフィールドに入る値について何を期待すべきなのか (人の名前なのかDNSネームなのか)がわからないことです。

多くの場合、事前にデータを検証することがルールとして決められており、DNSネームの場合がまさにこれに当てはまるため、このことが問題となるのです。

これらの理由のために少なくともRFC 2459で標準化された1999年以来、私たちは、ドメインネームにサブジェクトの別名へとすんなりと移行ができずにコモンネームを使用し続けています。

2012年頃にスタンフォード大学の研究者達は「世界で最も危険なコード：ブラウザ以外のソフトウェアでのSSL証明書の検証」（The most dangerous code in the world: validating SSL certificates in non-browser software）と題した論文を公開しました。基本的な証明書の検証作業を正しく行うことができないアプリケーションはセキュリティの脆弱性の源となります。

これらのアプリケーションは、悪意からではなく、彼らがその取り決めのために提供していたテクノロジーについての理解不足の結果として、ユーザーに対して誤ったセキュリティ感覚を与えてしまいました。そのうちの大部分は、18年間にわたる技術革新がもたらした複雑性によるものです。

検証に関する技術的な問題を解決するために多くの事柄を変更する必要はありますが、アプリケーション開発者向けに”有効”なSSL証明書が何で構成されているのかといった事をシンプルな形に変更し、もはや使われていない慣習を除外すれば、すぐに効果が現れると思われます。

いくつかの点でこのことがすでに起こっているのを見ることができます。まず、CA/ブラウザフォーラムはブラウザベンダーと協力して、すべての証明書が適合すべきベースラインプラクティスを定めました。また、ブラウザは実際に証明書が定義通りに発行されているかどうかの確認をおこなっています。

CA/ブラウザフォーラムで定義されたベースラインでは認証局がSSL証明書を発行する際には常に少なくとも1つのサブジェクトの別名が含まれていることを要求します。これによって、アプリケーションは、コモンネームとサブジェクトの別名の両方を検索する必要がなくなり、後者だけをチェックすればよいことになります。

現在、ほとんどの認証局では、サブジェクトの別名の中の1番最初のDNSネームをコモンネームフィールド内に記載していますが、これは主にレガシー上の理由によるもので、遠くない将来に中止されるでしょう。

それが実施される頃には証明書は少し小さくなり、開発者の生活は少し楽になっているでしょう。



※今回のレポートは、Ryan Hurstが執筆した英文をGMOグローバルサインスタッフが翻訳したものです。

出典：
・Baseline Requirements
・Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
・Microsoft Security Advisory: Update for minimum certificate key length