IDCF テックブログ

IDCF テックブログ

クラウド・データセンターを提供するIDCフロンティアの公式テックブログ

SSLサーバー証明書 HTTPファイル認証方法変更について!とレンタルサーバー中の人の対応

はじめまして。 オペレーション本部サービス基盤部の西岡です。

私はホスティングサービスZenlogicの仮想マシンやドメイン、証明書といったリソースの調達や管理を行うシステムの開発を担当しています。
特に証明書については業界全体の流れによる仕様変更やトラブルも多く、社内ではなんか証明書で苦労してるやつとして認知されています。

今回は先日あった証明書取得時のドメイン使用権確認のHTTPファイル認証の審査方法変更について、前提知識とZenlogicとしての対応も含めつつおさらいしたいと思います。

そもそも1: ドメイン使用権確認について

証明書の発行時には、申請したドメインの使用権を申請者が持っていることの確認が必要になります。

方法としては以下の3つがあります。

HTTPファイル認証

証明書申請時にベンダーから渡されるトークン(文字列)をファイルとしてWebサイト上の特定のパスに置き、認証を取る方法です。

パスはベンダーによって変わりますが、たとえば http://example.com/.well-known/pki-validation/fileauth.txt にHTTPアクセスするとトークンが見れる状態にするということです。

f:id:nnishioka_idcf:20211202191905p:plain
HTTPファイル認証 トークン設置例

ベンダーのシステムがそのファイルを参照できる必要があるため、ファイアウォールなどアクセス制限がある場合は一時的な解除が必要です。

DNS認証

証明書申請時に渡されるトークンをドメインのDNS TXTレコードに追加し、認証を取る方法です。

f:id:nnishioka_idcf:20211202181734j:plain
DNS認証 TXTレコード設定例

メール認証

  • ドメイン管理者としてみなされるメールアドレス(admin@〜など)
  • WHOIS情報に登録されているメールアドレス

にメールが送信され、そこに記載されたアクションを起こして認証を取る方法です。

そもそも2: 証明書の2way取得とは?

証明書取得時にSANs(Subject Alternative Names)として、申請するFQDNとは別のFQDNを指定することができます。
これにより、1枚の証明書を複数FQDNへ設定することが可能になります。

ベンダーの仕様にもよりますが、申請ドメインと「www.」サブドメインに対して無償で提供されることが多く、2wayと呼ばれます。
example.com と www.example.com に設定できる証明書が取れる、ということです。

ちなみにブラウザの鍵マークから証明書情報を表示し、DNS名の項目から確認ができたりします(Google Chrome 96.0.4664.55の場合)。
たとえば当社Webサイトの証明書は www.idcf.jp に cdn.www.idcf.jp を追加して発行されているようですね。

f:id:nnishioka_idcf:20211202191143p:plain
www.idcf.jp証明書 DNS名

「www.」サブドメイン以外は有償となるケースが多いですが、SANsに追加して取得することは可能です。

今回何が変わった?

従来は単一FQDNの使用権確認で2way取得ができました。
これまたベンダーの仕様によりけりですが、example.com(ベースドメイン)の確認が取れれば www.example.com をSANsに含めた2wayで発行しますよ、というような形です。

これが2021年12月1日以降、HTTPファイル認証でのドメイン使用権確認を行う場合、すべてのFQDNでの認証が必要になりました。
CA/Browser Forumという証明書についての議論やガイドライン策定を行う団体の決定で、つまるところ業界全体での変更です。 cabforum.org

従来、example.com の認証が取れていれば www.example.com 込みの証明書が取得できていたところ、同様のものを取得するためには example.com、www.example.com 双方での認証が必要になった形です。

また、ワイルドカードでの取得はHTTPファイル認証以外の方法でドメイン使用権確認を行うことが必要になりました。

Webサイトでの認証では、DNSのようにサブドメインの管理の委任ができず、example.com も www.example.com も nnishioka.genius.example.com もすべて同一の所有者とされてしまいます。
そのうえで example.com の使用権確認ができれば他のサブドメインの証明書が発行できるというのはセキュリティ上の問題があるため、今回の変更が決定されました。

Zenlogic中の人の対応

Zenlogicでは、ジオトラスト クイックSSL プレミアムGMOグローバルサイン クイック認証SSLの2製品において、ドメイン使用権確認としてHTTPファイル認証を採用し、なおかつ example.com と www.example.com の2way取得を行なっています。

また、HTTPファイル認証を採用している製品においては、証明書取得ワークフローをシステムが自動で行うようになっており、取得までに必要なお客さまの操作は申し込みだけになっています。

つまりシステム側の変更が必要になるのですが、ベンダー側システムが申請FQDNとSANsのFQDNにファイル認証に来てくれるので、変更内容としてはすべてのFQDNにファイル設置するようにするだけ!
example.com、www.example.com 双方での認証に対応し、従来どおりの証明書が取得できるようにしました。

システム変更はすでに適用済みです。
すでに取得されているお客さまの証明書についても次回更新時に新しい認証方法で行われますが、従来どおり更新時に必要な作業はなく、また現在の証明書から設定できるFQDNが変わるといったこともないのでご安心ください!
ただし、example.com、www.example.com 双方がZenlogicにドメイン登録されていないと2way取得されない場合があるので、その点はご留意ください。

おわりに

今年は証明書苦難の年で他にもいろいろありましたが、、、自分が今のシステムを担当するまで知らなかったような初心者向けの内容に多く触れられる本件を記事にさせていただきました。
前述のCA/Browser Forumの決定で来年もシステム変更が発生しそうな予定がすでにあるので、引き続き情報キャッチアップしつつ対応していきたいです。

最後まで読んでいただきありがとうございました。よいお年を!

Copyright © IDC Frontier Inc.