SSL証明書のドメイン認証とは

SSLサーバー証明書（以下、SSL証明書）を購入した際、「認証ファイル」という意味不明な文字列が記載されたファイルを受け取り、言われるがままそれを指定されたフォルダにアップロードした方が多いと思います。なぜSSL証明書にはこのような認証が必要なのでしょうか？その理由は、SSL証明書の役割の1つである「ドメインのなりすまし防止」に関係があります。

例えば、「example.jp」というサイトにSSL証明書を発行する場合、まず購入したユーザーや組織が「example.jp」というドメインを本当に所有しているのかを確認する必要があります。この所有者確認は、信頼された第三者機関である「認証局」が行っています。

さくらのSSLでSSL証明書を購入した場合、当社から認証ファイルが送付されますが、実は当社が認証局から受け取り、それをお客様へ転送しています。このドメイン認証は「ドメイン所有権確認」とも呼ばれており、ドメインを持っていることを証明するための手続きです。指定された場所に認証ファイルを設置し、認証局が設置を確認できた場合、初めてSSL証明書が発行されます。このような、認証ファイルを設置してドメイン認証を行う方法を「ファイル認証」と呼びます。

認証ファイルを使わないドメイン認証

認証ファイルを設置するWebサーバーが存在しない（ファイル認証が利用できない）場合は、「メール認証」や「DNS認証」などのドメイン認証を利用します。

「メール認証」を利用した場合、SSL証明書を購入すると特定のメールアドレス宛に認証局からメールが届きます。そのメールに記載されたURLにアクセスし、ページ内にある承認ボタンを押すことでドメイン所有権確認が行われます。もちろん、受信できるメールアドレスは限られており「admin@コモンネーム」や「postmaster@コモンネーム」のように決められたメールアドレス、もしくはWhoisに掲載されたメールアドレス※が指定できます。

• ※Whoisを利用する場合は、申請したコモンネーム以外のメールアドレスも指定できます。

しかしながら、近年はGDPR（General Data Protection Regulation：EU一般データ保護規則）の影響でWhois掲載項目が著しく制限されているため、ドメイン管理会社などの仕様によっては希望したメールアドレスが掲載できないケースも増えています。

メール認証はWebサーバーが無い（ファイル認証が利用できない）場合などに非常に便利な認証方法ですが、「メールを受信してWebページにアクセスし、画面上のボタンを自分でクリックする」という操作が必要になってしまいます。近い将来、SSL証明書の自動更新が一般化した場合、このような手動対応が発生する認証方法は自動化できず不便なため、今のうちに別の認証方法を検討することをおすすめします。

もう一つの認証方法は「DNS認証」です。DNS（Domain Name System）サーバー情報は、原則としてドメインの管理者しか変更することができません。これを利用して、認証局が指定したCNAMEレコードを設定する、もしくはTXTレコードへ指定の文字列を登録する、といった形でドメイン所有権確認を行います。

DNS認証のメリットは、誰でもDNSは設定しているので「確実に設定できる」ことと、APIに対応したDNS（さくらのクラウドのDNSなど）であれば「自動更新にも対応している」ことです。メール認証もDNS認証もWebサーバーがない場合は便利な認証方法ですが、WhoisやDNSなど外部のシステムで設定変更をする必要があるのがポイントです。

なぜドメイン認証は失敗するのか？

失敗することが多いドメイン認証ですが、多くの販売サイトではその失敗した原因を確認することができないため、原因がわからないまま発行が遅れてしまうケースがあります。ここではドメイン認証に失敗する原因をご紹介します。

ファイル認証の場合

ファイル認証において最も多い原因は、指定ファイルパスの書き間違い（スペルミス）による認証エラーです。認証局によって異なりますが、一般的には以下のようなフォルダに指定されたファイル名で認証ファイルをアップロードする必要があります。

例：http://example.jp/.well-known/pki-validation/dasf8wDdF83X.txt

ファイル名はそのまま（送られてきたまま）で良いですが、フォルダに関しては自身で作成する必要があるため「.well-known/pki-validation」などでスペルミスが多く、それが原因で認証エラーが発生します。メールやサポートページからフォルダ名をコピペするなど、スペルミスが発生しないように設定を行って認証エラーを回避しましょう。

また、認証ファイルを設置したフォルダにアクセス制限がかけられていることによって、認証エラーが発生するケースも多くあります。BASIC認証やIPアドレス制限がかかっていると認証局のクローラー（Bot）がアクセスできないため、ドメイン認証に失敗します。認証ファイルを設置した後は、スマートフォンなどの別ネットワークからそのアドレスにアクセスできるか確認してみると良いでしょう。なお、ハッシュ値なので暗号化された情報のように見えますが、認証局以外の第三者が見ても問題無い値ですので、公開領域に設置しても問題はありません。

また「example.jp」と「www.example.jp」のフォルダをWebサーバー上で分けている場合も注意が必要です。認証局によって異なりますが、一般的には両方のドメインを認証する場合はどちらのフォルダにも認証ファイルを設置する必要があります。

メール認証の場合

メール認証は「受信先メールアドレスのわかりにくさ」が原因で、受信したことに気づくことができず、「いつまで経ってもメールが来ない！」と勘違いしてしまうケースがあります。例えば、サブドメイン「aaa.example.jp」を申請した場合、「admin@example.jp」にメールを送信する認証局もあれば、「admin@aaa.example.jp」に送信する認証局もあります。受信先についてはサポートページなどに記載されていますので事前に確認しておきましょう。

また、前述のようにWhois情報を編集してもGDPRの影響でメールアドレスがWhoisに表示されない場合があります。そのため、ファイル認証を利用するためだけにレンタルサーバーを契約している方も存在します。

• ※さくらのレンタルサーバのライトプランは年間1,571円で利用できます。

DNS認証の場合

DNS認証についても、認証局の指定した文字列がハッシュ値のような「ランダムな文字列」であることが多いため、「コピペする際に1文字だけコピーし忘れる」などのミスが原因で認証エラーが発生します。また、DNS認証特有の事象として「DNSへの反映が完了していない」という可能性があります。DNSの反映にはネームサーバーによって若干時間が掛かり、さらにTTL（Time To Live）の設定時間だけ反映を待つ必要があります。DNSの設定変更が完了したにも関わらずSSL証明書が発行されない場合は、whatsmydns.netなどのDNS情報の反映が確認できるサイトで世界中のDNSへ正しく反映されたのかを確認してみましょう。

ドメイン認証以外の失敗原因

ドメイン所有権の確認以外にも発行に失敗する原因はいくつかあります。これらの原因は気づきにくい場合が多いので注意する必要があります。

CAAレコードの検証に失敗する場合

CAA（Certification Authority Authorization）レコードとは、認証局のコモンネームなどを設定する項目（DNSのリソースレコード）であり、設定を行うと指定した認証局以外はSSL証明書を発行することができなくなります。

• ※SSL証明書を第三者が勝手に発行することを防止する仕組みです。

任意で設定する項目なので知らない方も多いと思いますが、認証局はCAAレコードを確認しなければならないため、設定有無に関わらずに必ず検証が行われます。例えば、今回自分が申請したコモンネームが「example.jp」で、認証局のコモンネームが「example-ca.net」だった場合は、以下のようにCAAレコードを指定します。

example.jp CAA 0 issue "example-ca.net"

もし、別の認証局（例えばexample-ca.com）でSSL証明書を発行しようとしても、CAAレコードを検証すると「example-ca.net」のみが指定されているため、発行されることはありません。これはエラーでは無くCAAレコードを検証した結果なので正常な動作となります。

ここまでは「設定することによって不正な発行を阻止できる」という内容をご紹介しました。次は「CAAレコードが空の場合はドメインをさかのぼって検証する」という仕様についてご紹介します。

例えば、コモンネーム「sub.sub.example.jp」のSSL証明書を発行しようとした場合、CAAレコードが設定されていなくても、1階層上の「sub.example.jp」に設定されていれば、そこでCAAレコードが発見されるため検証が終了します。

次にCAAレコードが全て空のケースを見てみましょう。まず「sub.sub.example.jp」のCAAレコードへ検証に行き、空だった場合は「sub.example.jp」⇒「example.jp」へと検証が進み、最終的に「example.jp」が空であれば認証局の制限はかかっていないと判断されるため、発行処理に進みます。

ルートドメイン（example.jp）でSSL証明書を発行する場合は良いのですが、「sub.example.jp」で発行する場合は「example.jp」のゾーンも存在している必要があります。実際にサイトを運用していなくても（Aレコードが不要だったとしても）、DNSのゾーンは作成しておく必要があることに注意しましょう。

認証局の基準によって発行できない場合

ドメイン所有権確認のルールは、業界団体（CA/Browserフォーラム）が運用規定などをまとめた「Baseline Requirement」に記載されていますが、それ以外にも認証局独自の判断によってSSL証明書の発行に失敗する場合もあります。

例えば、ドメイン内に「google」や「apple」といった文字列が入っていると、フィッシングサイトを疑われてSSL証明書が発行できないケースが希にあります。こうした拒否リストは外部へ公開されているわけではないので、大企業が利用している文字列などは、あらかじめ避ける方が無難と言えます。ただし、SSL証明書の販売サイトによっては認証局と調整が可能な場合もありますので、問い合わせてみるのも良いでしょう。

今回ご紹介した原因以外にも、認証局のシステム障害などで発行が遅れてしまうケースもあります。一通りチェックしても問題が見つからない場合は、カスタマーサポートなどへ問い合わせてみましょう。

こちらの記事もあわせておすすめ！

発行後のエラーについては、『SSL設定時に表示されるエラーや警告の原因を徹底解明！～ブラウザエラー編～』や『SSL設定時に表示されるエラーや警告の原因を徹底解明！～コンテンツエラー編～ 』がおすすめです。組織認証や企業認証については『SSLサーバー証明書の違い』をご覧ください。