SSL/TLS on qwerty.work

CloudFlareを使ったサイトのcPanelでDNS DCVエラーに対処

Mon, 08 May 2023 19:56:40 +0900

発端はcPanelからのエラーメール

レンタルサーバーはミックスホストを利用しています。このレンタルサーバー上で、複数のサイトを公開しています。その中で、いくつか表示を高速化させる目的で無料で使えるCDNのCloudFlareを使用しています。CloudFlareを使用しているドメインを対象にミックスホストのコントールパネルであるcPanelから、以下のメールが届きました。

DNS DCV: No local authority: “cpanel.example.com”; HTTP DCV: “cpanel.example.com” does not resolve to any IP addresses on the internet.

DNS DCV: ローカルオーソリティがありません： “cpanel.example.com”; HTTP DCV: “cpanel.example.com” は、インターネット上のどの IP アドレスにも解決しません。内容としては、AutoSSLでサーバー証明書を更新するために必要な****ドメイン認証ができなかったということでした。

この時点で、何かしらの設定をcPanel側かCloudFlare側のどちらにすればいいのか？初めてのことでチンプンカンプンでした。しかし、このまま放っておくと、サーバー証明書の期限が切れて面倒なことになると嫌だなと対処することにしました。

一時的にCloudFlareを無効化してからAutoSSLを更新

海外のサイトにヒントがありました。

https://www.liquidweb.com/kb/how-to-repair-the-dns-dcv-error-in-cpanel/ https://www.liquidweb.com/kb/how-to-repair-the-dns-dcv-error-in-cpanel/

日本語訳にしたこのページによると、この問題を解決するには、以下の4つが候補とありました。

スタンドアロンのSSL証明書を購入する
cPanelのAutoSSLをオフにして、CloudflareのSSLのみを使う
CloudflareのSSLはなしで、cPanelのAutoSSLのみを使う
Cloudflareを一時的に停止してから、AutoSSLの証明書を更新する

私はどちらのSSLも有効なまま使用したいので、迷わず4番を実行することにしました。

手順

1.CloudFlareにログインして、対象のドメインを選択

2.「Overview」メニューを選択し、ページ右下の「Advanced Action」にある**「Pause Cloudflare on Site」**をクリック

3.**「Confirm」**をクリック

4.MixhostのcPanelの「SSL/TLS Status」を開き、**「Run AutoSSL」**ボタンをクリック

5.処理が終わるまで数分待ちます

6.するとエラーが消え更新完了となります

7.最後に、Cloudflareに戻り、「Overview」メニューを選択し、ページ右下の「Advanced Action」にある**「Enable Cloudflare on Site」**をクリックして有効化

以上。

エラーが残ったままになる場合

cPanelの「SSL/TLS Status」の画面でエラーが一部残ったままになる場合は、CloudflareのDNSにCNAMEまたはAレコードの登録が不足しているのが原因かと思われます。特にサブドメインのURLです。私はこのパターンでした。以下のようにレコードを追加して、再度**「Run AutoSSL」**を行ってみてください。解消されるはずです。

CNAMEを追加した例

CloudflareのDNS Recordsにサブドメイン名とFQDN（対象ドメイン）を追加

Aレコードを追加した例

CloudflareのDNS Recordsにサブドメイン名とレンタルサーバー（Mixhost）のIPアドレスを追加

この事に繋がるヒントが以下のページにありました。

https://define.co.jp/ssl/certificate-generation-process/domain-control-validation#vk-htags-dfb56e88-98c0-4aac-ba09-32e85145aaaa https://define.co.jp/ssl/certificate-generation-process/domain-control-validation#vk-htags-dfb56e88-98c0-4aac-ba09-32e85145aaaa

まとめ

今回のエラーはDNSに対してCNAMEによるドメイン認証、またはhttp通信でコモンネーム（FQDN）をCSRを元に作成したハッシュ値をファイル名にしたテキストファイル（http(s)://ドメイン/.well-known/pki-validation/ハッシュ値.txt）をサイト上で確認したかったが、それをクラウドフレアが邪魔しているといった話のようです。AutoSSLは3ヶ月に一度、サーバー証明書が自動更新される仕組みなので、3か月後もこの作業をしなければならないかもしれません。

今度試してみたいこと（その1）

後からの気づきですが、3ヶ月に1回この作業をするのも面倒なので、Cloudflareに設定を追加して今回のドメイン認証エラーを回避することができるのではないかと思いました。

例えば、

/.well-known/pki-validationの階層では「キャッシュを無視（スキップ）」、「SSLオフ」、「アプリの無効化」など、考えられるいずれかのルールを追加する
【効果なし】DNS Recordsにあるドメインを除き、サブドメインのAレコードをすべてCNAMEに変更する
【効果なし】DNS Recordsにあるドメインを除き、サブドメインのAレコードをすべて削除する

このどれかで回避できちゃったりするのかもしれませんので、またエラーが出たときに試してみたいと思います。

以下のCloudflareによるDCVのページ（下の階層も含む）にもヒントがありそうです。

https://developers.cloudflare.com/ssl/edge-certificates/changing-dcv-method/ https://developers.cloudflare.com/ssl/edge-certificates/changing-dcv-method/

今度試してみたいこと（その2）

以下のページではHTTPSへのリダイレクトが原因とありました。これも試してみたいと思います。

https://interactivewebs.com/cpanel/cpanel-autossl-certificate-expiry-on-date-cloudflare-enabled-domain/ https://interactivewebs.com/cpanel/cpanel-autossl-certificate-expiry-on-date-cloudflare-enabled-domain/

【効果なし】Cloudflare側のHTTPSの強制をやめる
【効果なし】Cloudflare側の/.well-known/pki-validationの階層では「SSLオフ」のルールを追加する
.htaccessで/.well-known/pki-validation階層ではhttpsに転送を除外する

今度試してみたいこと（その3）

Cloudflareの**［SSL/TLS］-［オリジンサーバー］-［認証済みOrigin Pull］を「オン」**にしてみる。

AutoSSLの更新がうまくいってるドメインのサイトは、ここがONになっていました。次回エラーが出た際はこれを試してみたいと思います。

Mixhostに他のレンタルサーバーで使っているSSL証明書を持ち込み（移行）してみる

Thu, 24 May 2018 23:37:28 +0900

他社の証明書（DV:ドメイン認証）をMixhostに持ち込みたい（移行したい）

レンタルサーバーを Mixhost に移行しました。Mixhost は標準（無料）で独自SSLでSSL化できるのですが、移行前のサーバーをSSL化したときに他社で購入した証明書（DV:ドメイン認証）の期限がたっぷり残っていたので、できれば期限切れまで Mixhost のSSL化に使いたいなと思い、 Mixhost にSSL証明書（DV:ドメイン認証）を移行することにチャレンジしてみました。

SSL証明書って移せるの？

証明書の移行はは初めてで、証明書についてあまりよくわかっていないので、以下のことが気になりました。

移行元のサーバーで使用していた証明書を別のサーバーでも使うことができるのか？
移行元のサーバーから証明書を削除しないと移行できないのか？
鍵のエクスポートとか何か難しそうな作業がいるのか？
二つのサーバーに同じ証明書を入れることができるのか？

など、モヤモヤしながら不安になっていたのですが、以下が揃っていて証明書のドメイン（コモンネーム）が同一ならば移行できることがわかりました。特に移行元のサーバーから削除とかせずに Mixhost に入れることができました。

準備するもの

証明書（CRT）
秘密鍵（KEY）
中間証明書（CABUNDLE)

これはすべて証明書の管理画面から取得できます。

Mixhostに証明書をインストールしてみる

[SSL/TLS Status] クリック

Mixhost のコントロールパネル **[cPnael] **の [セキュリティ]-[SSL/TLS Status] をクリックします。

[証明書の表示] クリック

証明書をインストール（インポート）するドメイン欄にある [証明書の表示] をクリックします。

サイト所有者が確認できないというエラーが出ているとき

上記のぺージは証明書を移行する前に AutoSSL を有効にしてみたときの画面で、以下のエラーが表示されている場合があります。

An Error occurred the last time AutoSSL ran, on 2018年5月22日

その詳細について http://ドメイン/.wel-known/pki-validation/123A4B5C6D7E89F0A12B34C5D6EF7890.txt がどうたらと表示されているときは、サイトの所有者が確認できなかったことを意味しているみたいです。表示されている通りの階層とファイル名でテキストファイルを作ってアップロードしてください。ファイルが存在していればテキストファイルの中身は空でもいいのかどうかわかりませんが、ファイル名にもある 123A4B5C6D7E89F0A12B34C5D6EF7890 の1行のみを記載して保存しましたことろエラー表示が消えました。

証明書の適用状況を確認

ページをスクロールしていくと使用ドメインに赤い鍵マーク*が表示されていてSSLが有効になっていない状態が確認できます。

証明書を登録

更にスクロールしていくと [SSL Web サイトをインストールします] という部分が現れます。ここに移行元のサーバーで使用しているサーバー証明書の 証明書（CRT)、中間証明書（CABUNDLE)、**秘密鍵（KEY) **をそれぞれの欄にコピペで貼り付けます。それぞれの欄にはあらかじめキーが表示されていますが、全部消してからコピペします。

プライベートキー（RSA PRIVATE KEY）は [秘密キー（KEY）] の欄に、中間証明書は [証明機関バンドル：（CABUNDLE)] の欄に貼り付けます。

貼り付けが終わったら [証明書のインストール] ボタンを押します。

インストール完了

以下の画面が表示されたら証明書の登録は完了です。

緑の鍵マークになった

[SSL/TLS Status] の画面に緑の鍵マーク*と Domain Validated の文字が表示されました。

[証明書の表示] から適用状況を再度確認してみると先ほど赤の鍵マーク*が、証明書に対応しているドメインのみ緑の鍵マーク**に変わっていました。

証明書の移行完了

あとは http:// ではなく、 https:// でページにアクセスして表示されれば証明書の移行と Mixhost のSSL化は成功です。

起動時に毎回battery.dllの「発行元を確認できませんでした」とエラーが出るときにしたこと

Wed, 28 Mar 2018 18:48:35 +0900

「不明な発行者」とエラー表示が出る

富士通のノートパソコンをリカバリーしていろいろいじっていたら、起動のたびに以下のエラーが必ず出るようになりました。OSはWindows7です。

FUJITSU Battery Check Tool - セキュリティの警告

発行元を確認できませんでした。このソフトウェアを実行しますか？

名前:　battery.dll

発行元:　不明な発行者

このファイルには、発行元を確認できる有効なデジタル署名がありません。信頼できる発行元のソフトウェアのみ実行してください。実行することのできるソフトウェアの詳細を表示します。

battery.dllのデジタル署名が原因っぽい

FUJITSU Battery Check Toolは工場出荷時に初期化したら最初から入っているソフトウェアです。今まで何度もリカバリしてきてこのようなエラーが出たことはありませんでした。

**［不明な発行者］**を開いてみると、富士通の署名を認証するCOMODOの証明書に「この証明は問題があります」といった表示があり、battery.dllの電子証明書が正当なものか確認できていないっぽい感じでした。

リカバリ作業の途中でLANケーブルを抜いたり挿したりしていたので、オンラインで認証局に確認することができなかったためにエラーが出ていたようです。

インターネット回線に接続したら解決できた

さっそくLANケーブルを挿して、インターネットにつながる状態にしたら**「証明書の状態」が「この証明書は問題ありません。」**に変わっていました。

その後はLANケーブルを抜いたままオフライン状態で何度も再起動してみましたが、エラーは出てこなくなりました。

WEBサイトの表示が高速化されるプロトコル「HTTP/2」と「QUIC」についてメモ

Thu, 01 Mar 2018 23:30:46 +0900

常時SSL化が当たり前になる時期が近付いています。SSL化すればWEBサイトを高速に表示できるプロトコル「HTTP/2」が使え、Chromeでは更に高速化が期待できる「QUIC」が使えるようです。それについていろいろ調べて気になることをメモ。

HTTP/2対応かURLからオンラインで確認

以下のページでURLからWEBサイトがHTTP/2に対応しているか確認できます。

https://tools.keycdn.com/http2-test https://tools.keycdn.com/http2-test

ブラウザでHTTP/2で通信しているか確認する方法

以下のページが参考になります。

https://nelog.jp/http2-browser-extensions https://nelog.jp/http2-browser-extensions

HTTP/2について

HTTP/2がなぜ高速なのかは以下のページが参考になります。

https://blog.redbox.ne.jp/http2-cdn.html https://blog.redbox.ne.jp/http2-cdn.html

https://zenlogic.jp/aossl/basic/response/ https://zenlogic.jp/aossl/basic/response/

https://lolipop.jp/http2/ https://lolipop.jp/http2/

このWEBサイトを高速に表示させるための技術として、HTTP1.1からGoogleがSPDYという高速化技術を作り、それが元でHTTP/2というのができて標準化されたそうです。

速度の違いを体感してみる

以下のページでHTTPで接続した場合と、HTTPSで接続した場合、見た目と表示完了時間で違いを視覚的に体感でできます。画面右上の「HTTP」と「HTTPS」のリンクをそれぞれクリックしてみてください。

https://www.httpvshttps.com/ https://www.httpvshttps.com/

HTTP/2が使えるブラウザ

HTTP/2はInternet Explorer 11（IE11)、Google Chrome、FireFoxなど、主要なブラウザで使えます.

Microsoft Windows 10上のInternet Explorer 11
Microsoft Edge
Google Chrome (Ver.30は設定が必要）
Mozilla Firefox (Ver.34から標準で有効)
Opera
Safari 9

その他のブラウザを含めた対応状況の参考ページ

https://caniuse.com/#feat=spdy https://caniuse.com/#feat=spdy

ブラウザだけではなくWEBサーバーのHTTP/2対応が必要

HTTP/2による通信はブラウザが対応していてもWEBサーバーというかWEBサイトがこのプロトコルに対応していないとできません。WEBサーバーが対応していなくても、CloudFlareなどのHTTP/2に対応したCDN経由で公開していれば、HTTP/2対応サイトにできます。

更に速いQUICで高速化？

GoogleがHTTP/2よりも安全で高速なレスポンスを実現するQUIC（Quick UDP Internet Connections）というTCPではなくUDPをベースにしたプロトコルを開発しているようです。

https://qiita.com/flano_yuki/items/251a350b4f8a31de47f5 https://qiita.com/flano_yuki/items/251a350b4f8a31de47f5

https://internet.watch.impress.co.jp/docs/column/ietf2017/1060156.html https://internet.watch.impress.co.jp/docs/column/ietf2017/1060156.html

https://www.iij.ad.jp/dev/tech/techweek/pdf/151111_4.pdf https://www.iij.ad.jp/dev/tech/techweek/pdf/151111_4.pdf

ChromeのQUIC関連の表示

QUICが使えるブラウザはまだChromeしかなさそうですが、ChromeでQUICに関する設定や状況表示は以下のURLをChromeのアドレスバーに入力すると表示できます。使い方はよくわかりません。

chrome://flags
chrome://net-internals/#quic

QUIC対応のレンタルサーバー

今のところ、HTTP/2とQUICに対応しているレンタルサーバーは以下だけのようです。

https://mixhost.jp/ https://mixhost.jp/

Chromeから信頼されなくなるSSL/TLSサーバー証明書かURLで調べるページ

Mon, 26 Feb 2018 20:59:17 +0900

2018年3月リリース予定のGoogle Chrome 66ベータ版および、2018年9月リリース予定のGoogle Chrome 70ベータ版から古いシマンテック系のSSLサーバー証明書（2016年6月1日以前に発行したSymantec、GeoTrust、Rapidsslブランドの証明書）を使っているサイトは信頼が停止され、警告が出るという話があります。自分のサイトのSSL/TLSサーバー証明書がChromeに信頼されなくなるものか、その警告対象かどうかURLで調べることができるページがあったのでメモ。

SSLチェッカー

シマンテック（Symantec）が運営していたSSL/TLSサーバー証明書などの事業を買収したデジサート社（DigiCert）が以下の「Google Chromeにより警告がでるウェブサイトかチェックする（SSLチェッカー）」というページを公開しています。ここから対象のサイトのURLを入力することで警告対象か調べることができます。

https://www.websecurity.symantec.com/ja/jp/support/ssl-checker https://www.websecurity.symantec.com/ja/jp/support/ssl-checker

証明書の更新しないとどうなる？

警告対象のSSL/TLSサーバー証明書を更新しなかった場合、**「問題のある証明書が入ったウェブサイト」としてChromeで閲覧時に「ウェブサイトが信頼されていない」および「このウェブサイトは安全ではない」**といった警告が表示されるようになるそうです。更新期限が来る前にウェブサイトの管理者、ホームページ制作会社に相談して証明書を更新しておきましょう。時期は不明ですが、Mozilla FireFoxも同様の対応をしていくようです。