Cloudflare の Universal SSL は Cloudflare が自動で発行・更新するため、更新が止まるときは「ゾーンが有効な状態か」「認証局が発行できる条件がそろっているか（CAA・DNSSEC・ネームサーバー）」「対象のホスト名がそもそも Universal SSL の範囲内か」のどれかに原因があることがほとんどです。また、ブラウザのエラーが実は配信元（オリジン）サーバー側の証明書の問題だった、という取り違えもよくあります。この記事では、エッジとオリジンのどちらの問題かを見分ける方法と、Universal SSL の更新が止まる原因を確認しやすい順に説明します。
最初に：問題はエッジ証明書か、オリジン証明書か
Cloudflare を経由するサイトには2種類の証明書が関わります。
- エッジ証明書: 訪問者のブラウザと Cloudflare の間で使われる証明書です。Universal SSL はこちらにあたります。
- オリジン証明書: Cloudflare と配信元サーバーの間で使われる証明書です。配信元に入れた Let's Encrypt の証明書や Cloudflare Origin CA の証明書がこちらです。
見分けるには、表示されているエラーを確認します。ブラウザが「この接続ではプライバシーが保護されません」のような証明書エラーを出し、証明書の発行元が Cloudflare の利用している認証局になっている場合はエッジ側です。一方、Cloudflare のエラーページで 525（SSL handshake failed） や 526（Invalid SSL certificate） が表示される場合は、Cloudflare と配信元の間の問題で、Universal SSL の更新とは関係ありません。526 は SSL/TLS の暗号化モードが「フル（厳密）」のときに、配信元の証明書が期限切れ・ホスト名不一致などで検証に失敗すると出ます。
また、DNS レコードがプロキシ無効（グレーの雲）のホスト名は Cloudflare を経由しないため、エッジ証明書は使われません。そのホスト名で証明書エラーが出ているなら、配信元サーバーの証明書を確認します。
手元から、実際に配信されている証明書を確認するには次のコマンドが便利です。
# 配信中の証明書の発行元・有効期限・対象ホスト名
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -issuer -enddate -ext subjectAltName
# DNS がCloudflareのプロキシを向いているか（Cloudflare のIPが返るか）
dig +short example.com原因1：対象のホスト名が Universal SSL の範囲外
Universal SSL がカバーするのは、ゾーンの頂点（example.com）と1階層のサブドメイン（*.example.com、たとえば www.example.com）です。dev.app.example.com のような2階層以上のサブドメインは含まれません。
プロキシを有効にした2階層のサブドメインで証明書エラーが出る場合、更新が失敗したのではなく、最初から対象外です。対処は次のいずれかです。
- 1階層のホスト名（
dev-app.example.comなど）に変更する - 有料の Advanced Certificate Manager で、そのホスト名を含む証明書を発行する（Total TLS 機能もこの中に含まれます）
- 自分で取得した証明書をカスタム証明書としてアップロードする（プランによって利用可否が異なります）
どの機能がどのプランで使えるかは変わることがあるため、Cloudflare の公式ドキュメントで確認してください（2026年10月現在）。
原因2：ゾーンが有効（Active）になっていない、ネームサーバーが外れている
フルセットアップ（ネームサーバーを Cloudflare に向ける方式）では、Cloudflare は自分の権威 DNS を使って認証局のドメイン認証（DCV）を自動で済ませます。そのため、次の状態だと更新できません。
- レジストラでネームサーバーを Cloudflare 以外に戻した、または一部だけ別の DNS を混ぜている
- ゾーンの状態が保留中（ネームサーバー変更待ち）や、移動済みのまま放置されている
- ドメインの有効期限が切れかけていて、レジストラ側で停止されている
確認は、ダッシュボードのゾーン概要で状態を見るのと、外部からネームサーバーを引く方法の両方で行います。
dig +short NS example.com
whois example.com | grep -iE "name server|expir"ダッシュボードに指定された2つの Cloudflare ネームサーバーだけが返れば正常です。
パーシャル（CNAME）セットアップでは、DNS の管理が Cloudflare 以外にあるため、Cloudflare が自動で DCV を済ませられません。管理画面で指示される TXT レコードや、DCV 委任用の CNAME レコードを、利用中の DNS 事業者側に追加しておく必要があります。以前追加したレコードを DNS の整理で消してしまい、次の更新で止まる例が見られます。
原因3：CAA レコードが Cloudflare の認証局を許可していない
CAA レコードは「このドメインの証明書を発行してよい認証局」を指定する仕組みです。Universal SSL は Let's Encrypt や Google Trust Services など複数の認証局から発行されるため（使われる認証局は変わることがあります）、CAA で特定の認証局だけを許可していると発行できません。
dig +short CAA example.com何も返らなければ制限はないため、この原因ではありません。CAA がある場合、Cloudflare は Universal SSL に必要な認証局の CAA を自動で追加する仕組みを用意していますが、手動で CAA を細かく管理している場合や、サブドメインに個別の CAA を置いている場合は、ダッシュボードの DNS 設定と SSL/TLS のエッジ証明書の画面で、Cloudflare が使う認証局が許可されているかを確認してください。
原因4：DNSSEC の設定不整合
DNSSEC を有効にしていて、レジストラに登録した DS レコードが Cloudflare の現在の鍵と合っていないと、検証を行うリゾルバからはドメインが名前解決できなくなります。認証局も DNSSEC の検証を行うため、DCV や CAA の確認に失敗します。DNS 事業者を Cloudflare に移したときに、旧事業者の DS レコードをレジストラに残したままにしているのが典型的な原因です。
# 検証付きで引けるか（SERVFAIL なら DNSSEC の不整合を疑う）
dig example.com @1.1.1.1 +dnssec
dig +short DS example.com不整合がある場合は、Cloudflare のダッシュボードで表示される DS レコードの値をレジストラに登録し直すか、いったんレジストラ側で DNSSEC を無効にしてから設定をやり直します。DS レコードの変更は反映に時間がかかるため、作業時間には余裕を持たせます。
原因5：Universal SSL が無効、または状態が保留のまま
ダッシュボードの SSL/TLS の「エッジ証明書」の画面（表記は変わることがあります）で、Universal SSL が有効になっているか、証明書の状態が有効になっているかを確認します。状態が認証待ちのまま進まない場合は、上記の原因2〜4を先に解消します。
API で証明書パックの状態を確認することもできます。トークンには SSL 関連の読み取り権限を持たせ、値はコードや公開リポジトリに残さないようにします。
curl -s "https://api.cloudflare.com/client/v4/zones/your-zone-id/ssl/certificate_packs" \
-H "Authorization: Bearer your-api-token" | jq '.result[] | {type, status, hosts}'Universal SSL を無効にしてから再度有効にすると発行し直しが行われますが、無効にした時点でエッジ証明書がなくなり、新しい証明書が有効になるまでの間 HTTPS でアクセスできなくなるおそれがあります。原因を取り除いても進まない場合の最後の手段とし、アクセスの少ない時間帯に行うか、先に Cloudflare のサポートやコミュニティで状態を確認するのが安全です。
更新が止まらないようにする運用
- DNS 事業者やレジストラの変更、DNSSEC・CAA の変更をしたときは、その日のうちにエッジ証明書の状態と
opensslでの有効期限を確認する - 2階層以上のサブドメインを新しく作るときは、Universal SSL の範囲外であることを前提に設計する
- 外形監視で、エッジ側（
example.com）と配信元側（配信元のホスト名や IP に-servernameを付けた確認）の両方の有効期限を見張る
まとめ
- まずエラーがエッジ証明書か配信元の証明書かを切り分けます。525・526 は配信元側の問題で、Universal SSL の更新とは別です。
- Universal SSL の範囲は頂点ドメインと1階層のサブドメインまでで、2階層以上は対象外です。
- 更新が止まる主な原因は、ゾーンが有効でない・ネームサーバーが外れている、CAA の制限、DNSSEC の不整合、パーシャルセットアップでの DCV レコードの消失です。
- Universal SSL の無効化と再有効化は一時的に HTTPS が使えなくなるおそれがあるため、最後の手段にとどめます。