DNSをプラットフォームに向けたのに、カスタムドメインに「保護されていない通信」の警告が出る。そんなとき、DNSレコード自体はほぼ正しく、ホストと認証局のあいだのハンドシェイクが止まっている可能性が高いです。多くの代理店はこれをプラットフォームの不具合だと考えますが、実態はほぼいつも設定の競合状態です。ドメインは技術的には正しい場所を指しているのに、Mydropのホスト割り当て設定がまだ以前のターゲットを探している、というケースです。
よくわかります。クライアントは待っている、ブランドポータルは公開したい、なのにURLがセキュリティエラーを吐いている。まさに、順調なキャンペーン展開が、IT部門との緊迫した技術バトルに変わってしまう瞬間です。でも、皆さんだけではありません。私たちは何百ものブランド展開で、この状況を見てきました。原因はプラットフォームそのものではなく、マネージドSSLが完了する前に消しておくべき「ゴースト」レコードや、残った割り当てであることがほとんどです。
数字が動く前に、何が変わったのか
SSLのプロビジョニングが遅れる原因は、たいていDNS管理画面での小さくて何気ない変更から始まります。Mydropのホストを指すようにCNAMEレコードを更新したのに、古いAレコードが残っていたり、TTL（Time to Live）の設定が長かったりすると、グローバルなDNSキャッシュは何時間も古いルーティング情報を配り続けます。
本当のトラブルは、無理に直そうとしたときに始まります。多くのチームが「SSLを更新」ボタンを何度も連打して、システムを叩き起こしているつもりになります。でも実際は、すでに半分まで進んでいた自動バックグラウンド処理を、途中で中断しているだけだったりするんです。
エラーメッセージのループを止めるために、まずは現在のDNS状態をさっと点検しましょう。このチェックリストなら、「設定済み」のドメインと「プロビジョニング済み」のドメインのあいだにある、よくあるズレがわかります。
DNS/SSLヘルスチェック5項目
- 反映チェック：
CNAMEレコードはグローバルなネームサーバー全体に反映されていますか？（DNSCheckerなどのツールで確認しましょう）- レコードの整理： ドメインを古いサーバーに向けていた過去の
Aレコードは、すべて削除しましたか？- 割り当てロック： そのドメインは現在、Mydrop内の別の有効な画面に割り当てられていませんか？
- ホストの競合： そのドメインは現在、別のワークスペースや予約済みのパブリックホストに使われていませんか？
- プロビジョニング待ち時間： 手動で介入する前に、自動cronジョブが新しいDNS状態を検知するまで最低15分は待ちましたか？
DNSの状態は確認できたのに、sslStateがまだエラーを示しているなら、ターゲット割り当ての競合が疑わしいです。これは、同じドメインがlink-in-bio画面とbrand-portal画面の両方を同時に指しているときに、プラットフォームが証明書を発行しようとすると起こります。
ドメイン設定でいったん割り当てを完全に解除して競合を解消し、「DNS確認済み」のステータスをもう一度確認してから、必要なターゲットに割り当て直しましょう。ホスト割り当てレイヤーを完全にリセットするイメージです。ルーティングキャッシュがクリアされ、マネージドSSLのライフサイクルがまっさらな状態から始まります。
多くのチームに起きているのは、技術的な障害ではなく「調整のズレ」です。ドメイン設定とプラットフォームのルーティングが、ただ噛み合っていないだけ。レコードを確認できたら、あとはシステムにハンドシェイクを任せましょう。待つことが、いちばん頼りになる診断ツールです。
まず確認したい失敗パターン
ドメインが「保護されていない通信」の状態で止まっているとき、原因はほぼいつも、DNSレコードとプロビジョニングサービスのあいだの競合状態です。私たちは、代理店がここでつまずくのを何度も見てきました。DNSを更新して、ダッシュボードのボタンを押して、すぐにハンドシェイクが完了すると思ってしまう。でもDNSは気まぐれなもので、部分的にしか反映されないことがよくあります。あるサーバーは新しいCNAMEを見ているのに、別のサーバーは古いインフラや何もない空間を見ている、という状態です。
いちばんよくある原因は、目に見えない古いレコードが残っていることです。portal.clientbrand.comのCNAMEは更新したのに、古いサーバーを指すAレコードを削除し忘れている。これで「スプリットブレイン」状態が生まれます。マネージドSSLサービスが所有権を確認しようとすると、ときどきルーティングレイヤーではなく古いサーバーに当たってしまい、プロビジョニングがタイムアウトします。
よくあるミス： ブラウザの更新ボタンを頼りにすること。ブラウザはDNSの応答を積極的にキャッシュします。キャッシュをクリアするか、なお良いのは、レコードが本当にグローバルで有効になっていると決めつける前に、サーバー側でチェックすることです。
もうひとつのよくある障害は、ターゲット割り当ての競合です。そのドメインが以前に別のワークスペースを指していたり、システムレベルのホストとして予約されていたりすると、内部のルーティングロジックが安全策としてSSL処理をブロックします。現在のワークスペースが完全に所有していないホストに、証明書を付けることはできません。その結果、ずっと消えない「保留中」状態に陥ります。土台の割り当てサービスが、要するに「これはまだ皆さんのものとは認識していない」と言っているわけです。
ノイズと本物のシグナルを見分ける証拠
プラットフォームが「ただ遅いだけ」なのか、当てずっぽうで判断するのはやめて、実際のシグナルを点検しましょう。私たちが社内用のDNSチェックツールを作ったのは、まさにこの理由からです。唯一の正解（ソース・オブ・トゥルース）として使えるようにしました。「保留中」や「競合」のステータスが返ってきたら、「SSLを更新」を何度押しても結果は変わりません。
サポートチケットを切ったり、開発チームに連絡したりする前に、このDNS/SSLヘルスチェック5項目でさっと点検してみましょう。
| ステップ | 点検項目 | 失敗時の対応 |
|---|---|---|
| 1 | CNAMEの反映 |
digやnslookupを使って、レコードが古いサーバーではなく当社のホストを指していることを確認します。 |
| 2 | Aレコードの競合がないこと |
同じサブドメインのAレコードはすべて削除します。これがハンドシェイクのタイムアウトの最大の原因です。 |
| 3 | ホストの空き状況 | 設定内で、そのホストがすでに別のワークスペースに割り当てられていないか確認します。 |
| 4 | SSL状態のシグナル | ダッシュボードで具体的なsslErrorコードを確認します。DNS_PENDINGなら待つ、AUTH_FAILUREならレコードを直す、と判断できます。 |
| 5 | cronの同期 | 最低15分は待ちます。バックグラウンドのワーカーがドメインの状態を定期的に確認しています。手動更新をすると、そのタイマーがリセットされることがあります。 |
SSLの黄金ルール： DNSチェックが失敗しているなら、SSLのプロビジョニングは実質ストップしています。プラットフォームは、皆さんのものだと確実に証明できないドメインの証明書を取りに行こうとはしません。DNSチェックを門番だと考えてください。ここがグリーンになれば、マネージドSSLのライフサイクルが自動で動き出します。DNS_PENDINGのエラーが出たら、ほぼ間違いなく反映待ちです。コーヒーでも取りに行って、ネットワークが追いつくのを待ちましょう。AUTH_FAILUREが出たら、DNSプロバイダーの管理画面で退治すべき「設定のゴースト」がいる、ということです。
今週中に直すべきこと
いまSSLの失敗ステータスをにらめっこしているなら、ボタンの連打はやめて、DNSレコードから始めましょう。いちばんよくある解決策は、意外なほどシンプルです。CNAMEやAレコードがゴーストホストと競合していないことを確認する。多くの場合、古いサーバーやルートレベルのリダイレクトを指す古いAレコードがDNSプロバイダー側でまだ有効になっていて、当社のプロビジョニングサービスが壁にぶつかっています。
DNS設定を点検して、道をきれいにしましょう。Mydropでカスタムドメインを管理しているなら、CNAMEがワークスペース設定に表示されたパブリックなカスタムドメインのターゲットを正確に指しているか確認してください。どこか別の場所を指していると、マネージドSSLのライフサイクルは所有権を確認できず、プロビジョニングがいつまでも止まったままになります。
DNSとSSLを復旧する5ステップチェックリスト
- 重複レコードの確認： 同じホストをめぐって
CNAMEと競合する可能性のあるAレコードやAAAAレコードは削除します。 - ターゲットの一致を確認：
CNAMEが、ドメイン設定で指定されたパブリックターゲットを正確に指しているか確認します。 - 反映を待つ： インターネットが追いつくのを待ちます。DNSの変更は数分で反映されることもあれば、頑固なグローバルリゾルバーの場合は最大1時間かかることもあります。
- ホストの競合を解消： 同じホストを現在ほかのワークスペースや無効なポータルが使っていないか確認します。
- 手動で更新： レコードがきれいになったと確信できたら、Mydropのドメイン設定で手動更新を実行します。
レコードを整理してもまだ失敗するなら、そのホストが予約済みのパブリックホストではないか、すでに別のワークスペースに割り当てられていないか確認しましょう。大きなチームでよくあるのが、半年前にどこかの部署がランディングページ用にドメインを「借りた」まま、返却を忘れているケースです。
診断をやめて、ワークフローを変えるべきとき
SSL証明書のトラブルシューティングを月に1回以上やっているなら、それは技術的な問題ではなく、調整の問題です。優れたチームは、「保護されていない通信」の警告が出てからドメインの設定ミスに気づく、なんてことはしません。ドメインのプロビジョニングを、プロジェクトライフサイクルの中の独立した「関門」フェーズとして扱う、「まず確認」の文化を築いています。
多くの代理店がやりがちなミスは、DNSが完全に反映されSSLが有効になる前に、ブランドURLをクライアントに渡してしまうことです。これだと、公開直後にクライアントがリンクを開いてブラウザ警告を見たとき、大きなボトルネックになります。そこで、社内の運用習慣を変えましょう。「ドメイン準備完了」を、リンクインバイオページやクライアントポータルをキャンペーン資料に載せる前の必須チェック項目にするのです。
オペレーターのルール： MydropのDNSチェックが「確認済み」のステータスを返すまで、クライアント向けの連絡やローンチスケジュールにカスタムドメインを含めないこと。
確認のタイミングをプロジェクトの早い段階に移せば、直前になってDNSの反映を追いかけるストレスから解放されます。SSLのプロビジョニングは、技術バトルではなく、ルーティンで自動化されたバックグラウンド処理に変わります。「まず確認」のルールを標準化すれば、皆さんは自分のマーケティング画面のITトラブルシューターではなく、毎回必ず予定どおりにローンチできるチームになれます。
まとめ
Mydropのようなマルチテナント環境でのSSL失敗は、プラットフォームが壊れていることがほとんどありません。原因は、DNSレコードが期待されるホスト割り当てとぴったり一致していないことだったり、ドメインが二方向に引っ張られる設定の競合状態だったりします。SSLが、長いDNS確認の連鎖の最後のハンドシェイクにすぎないと理解すれば、「エラー状態」は謎ではなくなります。レコードを点検し、ゴーストを退治し、新しいブランドポータルごとに「まず確認」のポリシーを徹底しましょう。チームもクライアントも、ページを開いた瞬間から安全で、ブランドらしく、すぐ使えるサイトというシームレスな体験にきっと満足してくれます。
Google review
Trustpilot review
Product Hunt comment
