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

ドメイン転送の廃止がSSLの問題に見えるのは、転送の仕組みがHTTPSの手続きの内側にあるからです。
ブラウザがURLを開くとき、裏では段階を踏んでいます。
まず名前からサーバーの場所を調べ、次に暗号化の手続きをして、最後にページの中身を受け取る。
どの段階で止まったかを、手元のMacのターミナルで順に確かめてみました。

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. 修正は「名前、証明書、中身」の順に見る

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