【Jimdo】Googleビジネスプロフィールの
ページが
「証明書が見つかりません」と表示され
てしまう?
(ドメイン変更)

  • Googleの店舗情報から「ウェブサイト」を押すとエラーになってしまう、という相談がありました。
  • 原因は、登録されたURLが .jimdo.com という古い名前のまま残っていたことでした。
  • HTTPSでは、転送の指示の前に、TLSハンドシェイクで証明書を確かめる手続きがありますが、古い名前の証明書を出さなくなると、転送にたどり着く前に接続が止まってしまいます。
  • そのため、URLの変更が「SSLの問題」として見えてくることがあり、Googleに登録したURLを直す必要があります。

関連記事

1. 「証明書が見つかりません」の奥にあったのは、サブドメインの変更

1. 「証明書が見つかりません」の奥にあったのは、サブドメインの変更

Googleビジネスプロフィールについて、このような相談がありました。

Googleで店名を検索すると、右側に店舗情報が出ます。
そこの「ウェブサイト」ボタンを押すと、「安全に接続できません」と表示されてしまう。
ホームページはJimdo(ジンドゥー)で作ったもので、新しいサイトに作り替えている最中です。

とのことでした。

画面を見せてもらうと、iPhoneでは「このサイトにアクセスできません」と出ていました。
アドレス欄の左にある情報のアイコンを押すと、「証明書が見つかりません」。

これだけを見ると、ホームページのSSLの設定が壊れているように思えます。

ところが、ホームページのアドレスと、表示されているURLをよく見ると違いがありました。

  • 公開されているホームページの今のURLを見ると 「https://example.jimdofree.com/」 です。
  • 一方、Googleビジネスプロフィールから表示されたアドレスは「https://example.jimdo.com/」でした1。

ホームページの方は、鍵のマークが付いて普通に表示されます。
違いは jimdo と jimdofree だけ。

では、原因は「SSLの設定不良」なのか、「URLが古い」なのか。
最初はどちらかだと思って迷いましたが、調べてみると、この2つは別々の原因ではありませんでした。
同じ出来事を、ブラウザの側から見るか、Googleの登録の側から見るかの違いです。

2. jimdo.comからjimdofree.comへ、2019年の名前変更と2026年の転送終了

実は、Jimdoでは「*.jimdo.com 」というサブドメインを、何年もかけて少しずつユーザーサイトから廃止していました。

2. jimdo.comからjimdofree.comへ、2019年の名前変更と2026年の転送終了

2.1. jimdo.comのサブドメインの廃止

1回目は2019年です。
Jimdoの無料版(クリエイターFreeプラン)のホームページが、〇〇〇.jimdo.com から 〇〇〇.jimdofree.com に切り替わりました2。
このときは、古いURLにアクセスしても新しいURLへ自動で転送されるので、利用者の対応は基本的に不要と案内されていました。

2回目は2024年9月です。
まだ jimdo.com を使っていたクリエイターのホームページも、〇〇〇.jimdo.com から 〇〇〇.jimdoweb.com に変わりました3。
こちらの転送は、2025年4月21日に終わっています4。

そして2026年3月、Jimdoは「~.jimdo.com でホームページが表示されない」という告知を出しました。
2019年に変わった無料版の旧URLについても、転送の対応が終わったという内容です5。

これで、*.jimdo.com のサブドメインではホームページが表示されなくなり、*.jimdo.com の証明書も廃止されました6。

2.2. 転送が効いていた間は、誰も気づけない

今回のGoogleビジネスプロフィールには、https://example.jimdo.com/ が登録されていました。
おそらく2019年より前に、そのとき正しかったURLを入れたわけです。

2019年からの数年間も、このURLは問題なく動いていました。
Googleのボタンを押すと、Jimdoが jimdofree.com へ転送してくれるので、利用者の目には普通にホームページが開いて見えます。

問題が表に出るのは、Jimdoが転送をやめるタイミングです。
ホームページの持ち主は何も触っていないのに、ある日からGoogleのボタンだけが開かなくなる。
しかも表示は「URLが変わりました」ではなく、「証明書が見つかりません」となりました。

3. HTTPSでは、リダイレクトより先にTLSハンドシェイクがある

3. HTTPSでは、リダイレクトより先にTLSハンドシェイクがある

ドメイン転送の廃止がSSLの問題に見えるのは、転送の仕組みがHTTPSの手続きの内側にあるからです。

ブラウザがURLを開くとき、裏では段階を踏んでいます。
まず名前からサーバーの場所を調べ、次に暗号化の手続きをして、最後にページの中身を受け取る。
どの段階で止まったかを、手元のMacのターミナルで順に確かめてみました。

https:// のURLを開くときの3つの段階。古い名前は2つめの段階で止まる

3.1. DNSは、古い名前をまだJimdoへ案内している

最初の段階は、DNS(Domain Name System:ドメインネームシステム)です。
example.jimdo.com という名前を、つなぎに行くサーバーのIPアドレスに変換します。
dig というコマンドで、古い名前と新しい名前を引いてみました。

$ dig +short example.jimdo.com
web.jimdo.com.
162.159.128.70
162.159.129.70

$ dig +short example.jimdofree.com
web.jimdofree.com.cdn.cloudflare.net.
185.60.251.251
185.60.251.252

古い名前も、ちゃんとIPアドレスが返ってきます。
行き先は web.jimdo.com で、Jimdoのサーバーです。
名前の案内は生きていて、最初の段階では止まっていません。

試しに、存在しないはずの zzzz-not-exist-9876.jimdo.com を引いても、同じ web.jimdo.com が返ってきました。
*.jimdo.com という名前は、中身に関係なく全部Jimdoのサーバーへ案内される設定になっているようです。

3.2. SSL証明書は、名前ごとに発行される

次の段階が、TLSハンドシェイク(TLS handshake:暗号化通信を始めるための握手)です。
一般にはSSLと呼ばれることが多いですが、今使われている仕組みの名前はTLS(Transport Layer Security:トランスポート層セキュリティ)7。
ブラウザは最初のメッセージで「example.jimdo.com につなぎたい」と名前を伝えます。
これをSNI(Server Name Indication:サーバー名表示)と言います8。
サーバーは、その名前に合う証明書を返さなければなりません。

openssl s_client で、この握手だけを試してみました。

$ openssl s_client -connect example.jimdo.com:443 -servername example.jimdo.com
CONNECTED(00000006)
... sslv3 alert handshake failure ... SSL alert number 40
---
no peer certificate available

サーバーには接続できています。
でも、example.jimdo.com という名前を伝えると、サーバーは握手を断ってきました。
証明書は1枚も返ってきていません。
iPhoneの「証明書が見つかりません」は、この状態をそのまま表示していたわけです。

新しい名前のほうは、証明書の中身まで見られます。

$ openssl s_client -connect example.jimdofree.com:443 -servername example.jimdofree.com \
    | openssl x509 -noout -subject -issuer -text | grep -E 'subject=|issuer=|DNS:'
subject= /CN=jimdofree.com
issuer= /C=US/O=Google Trust Services/CN=WE1
                DNS:jimdofree.com, DNS:*.jimdofree.comCode language: PHP (php)

証明書に書かれている名前は jimdofree.com と *.jimdofree.com の2つ。
* の部分には、どんなサブドメインでも入ります。
これがワイルドカード証明書で、1枚でたくさんのサイトをまとめて守れます9。

逆に言えば、この証明書で example.jimdo.com は守れません。
web.jimdo.com にも証明書はありますが、書かれている名前は web.jimdo.com の1つだけでした。
*.jimdo.com を守る証明書が、もう置かれていないのです。

3.3. 301リダイレクトは、暗号化の内側で返される

最後の段階が、HTTPのやりとりです。
URLが変わったとき、サーバーは「このページは移転しました、新しい住所はこちら」という返事をします。
これが301リダイレクト(301 Moved Permanently:恒久的な移転)で、ブラウザは自動で新しい住所へ移ります10。

curl で、http:// と https:// を比べてみました。

$ curl -sS -o /dev/null -w '%{http_code} -> %{redirect_url}\n' http://example.jimdo.com/
301 -> https://example.jimdo.com/

$ curl -sS -o /dev/null -w '%{http_code} -> %{redirect_url}\n' https://example.jimdo.com/
curl: (35) LibreSSL/3.3.6: error:1404B410:SSL routines:ST_CONNECT:sslv3 alert handshake failure
000 ->

$ curl -sS -o /dev/null -w '%{http_code} -> %{redirect_url}\n' https://example.jimdofree.com/
200 ->Code language: JavaScript (javascript)

暗号化しない http:// なら、サーバーは返事をしてくれます。
ただし中身は「https:// で来てください」という301で、jimdofree への案内ではありません。
https:// で開くと、今度はハンドシェイクで止まって、HTTPの返事までたどり着けない。
ステータスコードが 000 なのは、そもそもHTTPの会話が始まっていないからです。

301リダイレクトは、HTTPの返事の一種です。
https:// のURLでは、HTTPの返事は暗号化された通信の中で届きます11。
つまり、転送元の名前にも有効な証明書がないと、「移転しました」と伝える場所そのものがなくなってしまう。

4. 修正は「名前、証明書、中身」の順に見る

4. 修正は「名前、証明書、中身」の順に見る

直すこと自体は簡単です。
Googleビジネスプロフィールの編集画面で、ウェブサイトの欄を https://example.jimdofree.com/ に書き換えます。
Jimdoのホームページには手を入れる必要がありません。

もし、それでも同じような症状に出会ったら、ブラウザの段階に沿って見ていくと迷いません。

  • dig で名前が引けなければDNSの問題、
  • 名前は引けるのに握手で止まるなら証明書の問題、
  • 握手が通ってからエラーが出るならサーバーの中身の問題。

そして証明書で止まっているときは、「その名前はまだ使われているのか」を疑ってみる。
設定が壊れたのではなく、名前のほうが引っ越していることがあります。

新しいサイトを公開するときも、順番が大事です。
今回の相談では、STUDIOで作り替えたサイトを独自ドメインで公開する予定でした。
ドメインのDNSをSTUDIOのサーバーへ向けると、STUDIOが証明書を自動で発行します12。
https:// で開けることを自分で確かめてから、GoogleのURLを書き換える。
先に書き換えてしまうと、証明書ができるまでの間、同じ「安全に接続できません」を自分で作ってしまいます。

URLを変えるというのは、看板の文字を書き換えるだけの作業に見えます。
でもHTTPSの世界では、名前ごとに証明書がひも付いていて、古い名前にも証明書がないと「移転しました」の貼り紙すら出せません。
名前を変えることは、証明書を作り直すことでもあるわけです。

  1. Googleビジネスプロフィールのウェブサイト欄には、「http://」または「https://」を含む完全なURLを入力するよう案内されています。 – ビジネス プロフィールを編集する – Google ビジネス プロフィール ヘルプ
  2. 切り替えは2019年11月から12月にかけて順次行われました。対応は基本的に不要としつつ、SNSのプロフィールやメールの署名、名刺などに書いたURLは新しいものへ更新するよう勧めています。 – [重要]クリエイターFreeプランのサブドメイン変更について – ジンドゥー(Jimdo)
  3. 2024年9月18日から20日にかけて順次切り替え、9月23日に完了しています。jimdofree.com のホームページは対象外です。独自ドメインを使っていない場合は、Google Search Console などに登録したURLの更新が必要と案内されています。 – [重要]クリエイターホームぺージのURL変更について – ジンドゥー(Jimdo)
  4. 2025年3月21日の告知です。SNSやQRコード、印刷物に jimdo.com のURLを使っている場合や、GoogleのツールやBingウェブマスターツールに jimdo.com のURLで登録している場合が対象として挙げられています。 – クリエイター jimdo.com 自動転送終了のお知らせ – ジンドゥー(Jimdo)
  5. 告知は2026年3月17日付けですが、転送がいつ終わったのかは書かれていません。対応としては、SNSや外部サイト、メール、チラシなどに書いた旧URLを jimdofree.com のURLに変えるよう案内しています。Googleビジネスプロフィールについては触れられていません。 – 【クリエイター】「~.jimdo.com」でホームページが表示されない件について – ジンドゥー(Jimdo)
  6. 2026年の告知は「サブドメイン変更に伴う仕様変更」と説明しているだけです。2025年に jimdoweb.com 側の転送を終えたときは、「サービスを安定的にするため」にURLを統一すると説明していました。 – クリエイター jimdo.com 自動転送終了のお知らせ – ジンドゥー(Jimdo)
  7. SSLはTLSの旧規格で、安全性の面から推奨されていません。現在はTLSが主流ですが、「SSL/TLS」と併記されることもあります。 – TLS 証明書を発行する・確認する | Studio Help
  8. SNIは2003年に標準化された拡張仕様です。まだ暗号鍵を共有していない最初のメッセージ(ClientHello)に入るため、接続先の名前自体は暗号化されずに送られます。これによって、1つのIPアドレスで多数のHTTPSサイトを扱えるようになりました。 – 暗号化か喪失か。SNI暗号化の仕組みについて | Cloudflare ブログ
  9. ワイルドカード証明書が使えるのは、アスタリスクと同じ階層のサブドメインだけです。「*.example.jp」の証明書は「sub2.sub1.example.jp」には使えません。「*」を除いた「example.jp」自体に使えるかは認証局によって異なり、今回の証明書では jimdofree.com が別の名前として並べて書かれていました。 – ワイルドカード証明書について | JPRS
  10. 301は、リソースが恒久的に移動したことを示すステータスコードです。移動先のURLは Location ヘッダーで伝えられ、検索エンジンもリンクを新しいURLに付け替えます。 – 301 Moved Permanently – HTTP | MDN
  11. リダイレクトは、サーバーがステータスコード3xxと Location ヘッダーを含むHTTPレスポンスを返すことで行われます。HTTPSでは、このレスポンスもTLSで暗号化された通信の上で送られます。 – HTTP のリダイレクト – HTTP | MDN
  12. 発行には一般に数分から数時間かかり、DNSの反映に時間がかかると最大で約72時間ほど必要になることがあります。証明書の状態は、エディタの公開パネルの「独自ドメイン設定」で確認できます。 – TLS 証明書を発行する・確認する | Studio Help