さくらのレンタルサーバに他社の独自ドメインを設定できない

直面している問題

WorsPressでブログを立ち上げたいと思い、さくらインターネットのレンタルサーバ(スタンダード)を契約しました。
公式の手順に従い進めていき、STEP4 ドメイン設定 の通りにGoogle Domainsで取得した独自ドメインを設定したのですが、
設定したドメインからアクセスすると、「この接続ではプライバシーが保護されません」と書かれた白いページが表示されてしまいます。

環境

サーバ:さくらのレンタルサーバスタンダード(詳細はこちらになります)
Apache:2.4.41
データベース:MySQL 5.7
PHP:7.4.3
その他はスタンダードの設定の通りです。

現在の状況

WordPress自体は正常に稼働しており、最初に与えられたURL(http://[設定したサブドメイン].sakura.ne.jp/wp)からWordPressの初期設定に進むことができます。(httpsでも接続可能です)
WordPressのディレクトリ構造は /home/[設定したサブドメイン]/www/wp となっています。
独自ドメインを追加した際にパスを /wp と正しく設定しております。
独自ドメインはGoogle Domainsで取得した .dev ドメインになります。
Google DomainsのDNS設定で、ネームサーバをさくらのネームサーバ(ns1.dns.ne.jp, ns2.dns.ne.jp)に変更しております。
独自ドメイン追加後にアクセスした http://[独自ドメイン]/ と https://[独自ドメイン]/ のどちらもページを開くことができません。(.devドメインはGoogle Chromeの場合HSTSの関係でhttpsに強制リダイレクトされてしまいます)
さくらのコントロールパネルからドメインのSSL証明書を取得することができるのですが、「無料SSL証明書設定」に進むと、「お客様のドメインの名前解決ができないため無料SSL機能をご利用いただけません。」と言われ、SSL証明書を取得することができません。

考えうる問題について

.dev ドメインを使用するのにSSL化が必要だということは承知しているのですが、SSL化する際に.devにアクセスしようとするとエラーになる、というケースがこれまで何度か発生していました。
違うドメインを使用する、というのは問題の本質とは違う解決方法になってしまうのでなるべく避けたいと考えています。

pingを飛ばしたりすると設定したさくらのレンタルサーバのIPアドレスが正しく返ってくるのですが、以前としてページを表示することができません。
よくDNSの設定をした際に「反映するのに最大2日間かかる」と言われますが、１日たっても治らなかったため質問させていただきました。
もし2日待つのは当たり前というのが常識でしたら大変申し訳ございません。

もし知見、経験のある方がいらっしゃいましたら、ご教示いただけたらと思います。

hoshi-takanori

2020/03/22 21:42 編集

DNS が 2 日間かかるというのは変更した場合で、今回は新規でしょうから無関係では。 http://www.e-ontap.com/dns/propagation/ 無料 SSL は Let's Encrypt を使ってると思いますが、仕組み上 Let's Encrypt のサーバーから http でアクセスして確認するので、その際に http → https のリダイレクトが悪さしてるのかとも思いましたが、大丈夫という説もあります。 https://www.reddit.com/r/webdev/comments/awowyl/adding_ssl_to_a_dev_domain_using_letsencrypt/ が、無料 SSL の設定の際にさくら側で何かチェックしてる可能性もあり、その際に http → https のリダイレクトに引っかかってる可能性もありますね。ちなみに、.dev はよく知らないのですが、Firefox など Chrome 以外のブラウザでも http アクセスできないのでしょうか？

退会済みユーザー

2020/03/23 13:56

>DNS が 2 日間かかるというのは変更した場合で、今回は新規でしょうから無関係では。ネームサーバをさくらのものに変更したのですが、それについても無関係なのでしょうか...? >ちなみに、.dev はよく知らないのですが、Firefox など Chrome 以外のブラウザでも http アクセスできないのでしょうか？ HSTSが設定されているブラウザについては同様にhttpsにリダイレクトされてしまいますが、そうではないブラウザ(例えばIE)についてはhttpでアクセスすることができました。SSLについても同様で、サーバ側でリダイレクトの設定が行われてなければそもそもhttpsで要求するはずが無かったので、依然原因が分からないままといった感じです...