SSL証明書の署名と検証

SSLサーバー証明書について調べてみたのでまとめてみます。

SSLサーバ証明書について

SSLサーバー証明書は、https通信を行うサーバーが持っている電子証明書です。ウェブサイトの「運営者の実在性を証明」し、クライアントとサーバ間で「暗号化通信」を行うためのもので、認証局という場所で発行されます。

証明書の役割

証明書の役割は二つあります。

・サイト運営者の実在性の証明

・暗号化通信

証明書を利用することで、サーバーとクライアントで暗号化通信(HTTPS通信)が行えます。証明書に含まれる公開鍵を使ってHTTPS通信のセッションを確立します。通信内容の盗聴を防ぐことができます。

証明書発行のリクエスト

証明書が発行されるまでの流れを順に見ていきます。

証明書を発行するのは認証局(CA: Certification Authority)という機関です。まずサーバの管理者が、認証局に証明書を発行するリクエストを送ります。このリクエストを証明書署名リクエストやCSR(Certificate Signing Request)といいます。CSRはエンコードされたテキストファイルで、申請する会社の組織名・所在地・ドメイン名・公開鍵などの情報が含まれています。認証局はCSRを受け取ると、「ドメイン名の利用権」や「組織の実在性」の認証を行います。その時の認証レベルによって、証明書の種類が異なります。

証明書の種類

証明書には、大きく三つ種類があります。証明書の種類によって信頼性は異なりますが、暗号化強度などは全て同じです。

・DV証明書

ドメイン認証 : DV(Domain Validated)

DV証明書を発行する際には、メール認証やDNS認証により、ドメインの使用権のみが確認されます。組織の実在性は確認されません。個人でも発行でき低価格で、申請後すぐに発行可能です。「AWS ACM」や「Let's Encrypt」は無料でDV証明書を発行できます。

・OV証明書

実在証明型 : OV(Organization Validated)

OV証明書の発行では、ドメインの使用権と運営組織が法的に実在することも認証します。政府など第三者機関が公開しているデータベースなどを照会することで、組織の実在を確認します。また電話で証明書の申請意思を確認します。誰でも発行できるわけではないためDV証明書よりも信頼性は高くなります。しかし、DV証明書より料金は高く、証明書発行までに多少時間もかかります。

・EV証明書

実在証明拡張型 : EV(Extended Validation)

ドメインの使用権や、運営組織が法的・物理的に実在することを認証します。事業の存在、申請責任者など、OV証明書よりさらに多くの項目を確認します。EV証明書発行にはOV証明書よりも、多くの料金と時間がかかります。EV証明書は認証項目が多い分、最も信頼性の高い証明書になります。

署名と検証

認証局でドメイン利用権や組織の実在性の認証が終わるとCSRに署名が行われます。 認証局が行うCSRへの署名や、クライアントが行う証明書の検証とは、どのように行われるのかについて見ていきます。

・署名

CSRへの署名の流れを以下の図に表しました。まずCSRのデータをハッシュ関数にかけてハッシュ値を算出します。次にCSRのハッシュ値を署名生成鍵(秘密鍵)で暗号化します。その暗号化したハッシュ値と、元のCSRを合わせたデータが「署名済み証明書」となります。

署名済み証明書の発行後は、サーバーに証明書のインストールが行われます。このサーバーに対してクライアントがアクセスすると、署名済み証明書の検証が行われます。証明書の検証では、正当な証明書であるか、改竄されていないか、などが確認されます。

・検証

署名済み証明書の検証の流れを以下の図に表しました。署名済み証明書を受け取ったクライアントは、署名済み証明書に含まれるCSRのデータからハッシュ値を算出します。次に暗号化されたハッシュ値を検証鍵(公開鍵)で復号します。CSRから算出したハッシュ値と、復号したハッシュ値を比較することで検証を行います。一致すれば正しいサーバーとして認識されます。反対に、もし証明書に改竄があればハッシュ値が一致せず、クライアントのブラウザに警告が表示されます。

署名生成鍵と検証鍵

署名と検証の過程で署名生成鍵(秘密鍵)と検証鍵(公開鍵)が出てきました。

・署名生成鍵

検証鍵(公開鍵)と対応する署名生成鍵(秘密鍵)は認証局が持っていて、厳重に保管されています。署名生成鍵がもし流出した場合は、不正な証明書が発行されてしまいます。

署名生成鍵が流出した場合はOSの緊急アップデートなどで、その認証局のルート証明書が無効化されます。また証明書失効リスト(CRL)という、無効にした証明書の一覧があります。不正が疑われる証明書は認証局が管理するCRLに登録されて利用できなくなります。

・検証鍵

証明書の検証でクライアントは検証鍵を使っていますが、どうやって検証鍵を手に入れたのでしょうか。

認証局は様々な企業、組織が運営しており多数存在しています。企業が新しいパブリック認証局を作ろうと思うと、WebTrust for CAという認証局監査法人に認められる必要があります。その後、例えばMicrosoftなどの監査要件を満たし、信頼できる認証局と見なしてもらえたとします。すると、Windowsに認証局のルート証明書をPC出荷時からデフォルトでインストールしてくれます。この認証局のルート証明書の中に検証鍵が含まれています。ブラウザやOSに、認証局のルート証明書がインストールされることで初めて、その認証局で発行したSSL証明書が使えるようになります。

ルート認証局と中間認証局

ここまでの図では認証局を一つのイラストで表現しました。しかし正確には認証局には、ルート認証局と中間認証局があり階層構造をとっています。

なぜこのような構造にするかというと、セキュリティを向上させるためです。もし認証局が階層構造をとらず、脆弱性を突かれてルート証明書が無効になった場合、全ての証明書が無効になります。中間認証局があると、ルート認証局をオフラインで管理可能で、仮に中間認証局の脆弱性をつかれても影響が出る範囲を狭めることができます。

・ルート認証局

ルート認証局は、自身の証明のため、自分自身で署名したルート証明書を発行します。このルート証明書はPCに出荷時よりインストールされています。また、ルート認証局は中間認証局に対して、中間証明書を発行します。中間証明書は、ルート証明書に含まれる検証鍵で検証が行えます。

・中間認証局

認証局が階層構造をとると、証明書も階層構造になります。中間認証局は、中間証明書を持っています。中間認証局はサーバーからCSRを受け取ると、SSL証明書と中間証明書の2つを結合して返しています。

・階層構造をとる証明書の検証フロー

中間認証局で発行した証明書をインストールしているサーバーに接続すると、クライアントは中間証明書とSSL証明書を受け取ります。

中間証明書に署名しているのは、ルート認証局です。そのため、PCにインストール済みのルート証明書に含まれる検証鍵(公開鍵)を使って、中間証明書の検証が行われます。この検証により、中間証明書に改竄がないことが確認できました。次に、中間証明書に含まれる検証鍵を使って、SSL証明書を検証します。SSL証明書にはHTTPS通信を行うための公開鍵が含まれています。