公開直後はなぜ狙われやすい？ SSL 証明書を発行した直後に潜む CT スキャンとは

AI でアプリやサイトを作り、自分のサーバーで公開すると、まだだれにも URL を教えていないのに、知らない相手からのアクセスが届くことがあります。この記事では、その理由の 1 つと考えられる「証明書の公開の記録」のしくみと、編集部が測った発行の直後のアクセス、公開の前にできる対策を説明します。

証明書を取ると、ホスト名が公開の記録に載る

Certificate Transparency(CT)とは

Certificate Transparency(CT)は、発行された証明書を、公開の記録(ログ)に残す仕組みです。2013年の RFC 6962 で定められ、2021年に第 2 版の RFC 9162 が出ています。目的は、誤って発行された証明書や不正に発行された証明書に、だれでも気づけるようにすることです。

発行の手順は、次のとおりです。

1. サイトの持ち主が、認証局(証明書を発行する組織)に発行を頼みます。
2. 認証局は、発行の前に、ホスト名の入った「事前の証明書」を CT の記録先に届けます。記録先は、受け取った時刻に署名を付けた SCT(署名付き証明書タイムスタンプ)を返します。
3. 認証局は、SCT を入れた証明書を発行します。

無料の認証局の Let's Encrypt は、発行するすべての証明書を CT の記録に届ける、と説明しています。編集部が確かめた 22 枚の証明書にも、記録先 2 か所の SCT が入っていました。

記録は、だれでも読める

CT の公式サイトは、記録について「だれでも問い合わせできる」と説明しています。RFC 6962 も、記録を見張る役(モニター)が、気になる証明書が出ていないかを確かめる、と定めています。もともとは、自分のドメインに知らない証明書が出ていないかを確かめるための仕組みです。

同じ記録から、新しく載ったホスト名を知ることもできます。載った直後のホスト名を調べに来る動きを、この記事では CT スキャンと呼びます。

記録に載るまでの時間は、RFC 6962 では、SCT を返してから、記録先ごとに決めた時間以内です。新しい方式の記録先(Static CT API)は、記録に並べてから SCT を返す作りです。編集部のサーバーに何秒でアクセスが届いたかは、あとの実測で示します。

「載せない」は選べない

• Chrome の決まり: 公開で信頼されるすべての TLS 証明書は、CT の条件を満たさないと検証に通りません。
• Apple の決まり: 条件を満たさない証明書では、TLS の接続が失敗します。

記録に届けていない証明書は、Chrome や Apple の製品(Safari など)で信頼されません。公開のサイトでは、記録に載せないことは選べません。

載るのは、証明書に書いた名前

記録に載るのは、証明書そのものです。証明書に書いたホスト名は、そのまま読めます。ページの中身や、URL のパス(/ から後ろの部分)は載りません。

ワイルドカード証明書(*.example.com のように、サブドメインを 1 枚でまとめて受ける証明書)では、載るのは *.example.com という形です。個々のサブドメインの名前は載りません。編集部の運営会社のワイルドカード証明書 2 枚でも、載っている名前は、*. の付いた名前と付かない名前の 2 つだけでした。

実測 1: 記録の流れは、1 秒に約 500 件

編集部の運営会社は、自社のドメインに知らない証明書が出ていないかを見張るために、公開の CT の記録を受け取っています。そこに残っていた最新の 10,000 件を、2026年10月12日に集計しました。

平均では、1 秒に約 500 件です。最後の 7 秒間は、1 秒に 381〜914 件でした。

発行した認証局は、Let's Encrypt が 6,014 件(60%)でした。個人や小さな会社が自動で取る証明書も、この流れに載ります。

ホスト名に入っていた語を数えると、test が 144 件、dev が 91 件、staging が 73 件、admin が 56 件ありました。名前を読むだけで、公開の前の物や管理用の物だと推測できます。test や admin のような名前にしても、隠れることにはなりません。

実測 2: 発行から 3 秒で、最初のアクセスが届いた

次に、証明書を発行したあと、知らない相手のアクセスがいつ届くかを数えました。編集部の運営会社の、検証用のサイトを置いているサーバー 1 台の記録です。

• 最初のアクセスまで: 中央値は 3 秒、幅は 1〜6 秒でした。22 回のうち 21 回は、5 秒以内です。
• 基準との比べ: 発行と関係のない時刻で数えると、中央値は 104 秒でした。5 秒以内だったのは、2,000 回のうち 4.7% です。
• 直後の 5 秒: 発行の前の 60 秒間に新しく現れた送り元は、22 回を合わせて 10 か所でした。発行から 0〜5 秒の 5 秒間だけで、38 か所です。

ホスト名ごとの記録が残っていたあるホスト名では、編集部が動作を確かめるために送ったアクセス(発行の 12 秒後)よりも先に、知らない相手のアクセス(3 秒後)が届いていました。

発行から 5 分間に新しく現れた送り元は 229 か所で、直前の 30 分の平均(5 分あたり 61 か所)の約 3.8 倍でした。1 回の発行あたりでは、10 分で 15.5 か所(ふだんは 4 か所)、60 分で 48 か所(ふだんは 24 か所)です。30 分を過ぎると、ふだんの水準に近づきます。

来たのは、仕組みで動いているとみられる相手

最初の 60 秒に現れた送り元は、22 回を合わせて延べ 67 でした。名乗り(User-Agent。アクセスする側が自分で書くソフトの名前)で分けると、次のとおりです。

• 巡回や調査を名乗るもの: 31。名乗りに、巡回の名前や連絡先の URL を書いているものです。同じ名前の巡回が、22 回のどれでも 60 秒以内に来ていました。
• ふつうのブラウザと同じ名乗り: 33。このうち 1 つの送り元は、22 回のうち 20 回に現れました。人が開いたとは考えにくく、仕組みで動いているとみられます。
• AI の巡回を名乗るもの: 3。

検索エンジンを名乗るアクセスは、あとで述べる 3 つのホスト名の最初の 24 時間には、1 件もありませんでした。

CT の記録を見て来た、と考える理由

アクセスの記録には、相手がどこでホスト名を知ったかは残りません。CT の記録を見て来た、と断定はできません。そう考える根拠は、発行の直後に集まっていること(上の、発行と関係のない時刻との比べ)と、次の 3 つです。

• DNS の登録は増えていない: 28 個のうち 27 個は、どんな名前でも同じサーバーに届く設定(ワイルドカードの DNS)で受けています。新しい名前を足しても、DNS の登録は増えません。
• まだだれにも伝えていない: 発行の数秒後は、URL をどこにも書いていない時点です。
• 証明書の名前がそのまま届いた: 22 回のうち 21 回で、発行から 60 分以内に、送り元が「前に開いていたページ」(Referer)としてそのホスト名を伝えてきたアクセスがありました。名前を 2 つ書いた証明書では、5 秒後に、2 つの名前の両方が届いています。

ホスト名を知らなくても届く、遠隔ログイン(SSH)への試しの記録は、公開したサーバーは、何秒で攻撃される？ 1 週間の記録と、おとり(ハニーポット)の使い方にまとめています。

最初の 24 時間と、そのあと

ホスト名ごとの記録が発行の直後から残っていた 3 つのホスト名(A・B・C)で、そのあとを数えました。名前を指定したアクセスだけが入る記録です。

• 最初の 1 時間: A は 177 件(27 か所)、C は 94 件(27 か所)でした。B の記録は、発行の 33 分後から残っています。
• 最初の 24 時間: 449〜1,116 件(中央値 758 件)、送り元は 34〜80 か所でした。
• 14 日間: 3 つの合計は 3,640 件で、64% が最初の 24 時間に届いています。3 日目からは 1 日に 10〜108 件ですが、8 日目のように、1 つの送り元がまとめて送ってくる日があります。

発行から 1 週間以上たっていた別の 5 つのホスト名にも、同じ期間に 1 日あたり 11 件(中央値)が届いていました。70 日分のうち 8 日は、100 件以上です。名前は記録に残り続け、日がたってもアクセスは続いていました。

取りに来た物の 59% は、秘密のファイル

• 秘密のファイルを探す(59%): パスワードや鍵を書く設定ファイル(.env)を探すものが 1,099 件で、パスは 222 種類ありました。/.env.production や /api/.env のように、名前や置き場を少しずつ変えて試しています。プログラムの履歴(.git)を探すものは 38 件です。
• トップページを開く(24%): 何が動いているかを調べています。
• ログイン画面・管理画面・PHP を探す(9%): /login や /info.php などです。WordPress に関係するパスは 88 件でした。

入口に認証(Basic 認証。ブラウザが ID とパスワードをたずねる、Web サーバーの認証)を付けていたホスト名の 1 つでは、14 日間のアクセスの 98% が「認証が必要」の応答で止まっていました。3 つとも、秘密のファイルの中身が返ったものはありません。

AI の道具の鍵や設定も探されている

同じサーバーの全部の記録を見ると、AI の道具に関係するパスへのアクセスが、この期間に 675 件(122 か所から)ありました。

• 鍵や設定のファイルを探すもの: 519 件です。AI の API の鍵が入っていそうな名前(/.env.anthropic、/.env.openai)や、AI のコーディングの道具の設定ファイル(/.claude/settings.json)を取りに来ています。
• AI の道具とつなぐ窓口(MCP)を探すもの: 156 件です。

鍵や設定の中身が返ったものは、ありませんでした。AI でアプリを作るときは、鍵を書いたファイルや道具の設定のフォルダを、公開されるフォルダに置かないでください。秘密情報の扱いは、AI コーディングの道具を安全に使う(権限・秘密情報・学習の設定)にまとめています。

対策: 手間の小さい順に 6 つ

ホスト名が記録に載ることは変えられません。載る前提で、見られて困る物を無くします。

1. 準備ができてから証明書を取る: 編集部の実測では、証明書を取った数秒後に最初のアクセスが届きました。認証と初期設定を済ませてから、発行のコマンドを動かします。
2. ホスト名に、秘密や管理用の言葉を入れない: 顧客の名前、公開の前の商品名、admin や internal のような言葉です。記録は追記だけの作りで、載った名前は消せません。
3. 公開の前から、認証や送り元の制限を付ける: 検証用のサイトには、Basic 認証か、送り元の IP アドレスの制限を付けます。
4. 検証用は、ワイルドカード証明書にまとめる: 個々の名前が記録に載らなくなります。Let's Encrypt では、DNS に確かめ用の値を書く方式(DNS-01)でだけ発行できます。*. の形は載るので、サブドメインがあることは分かります。
5. 初期設定のままの管理画面やインストーラーを置かない: インストールの途中の画面を置いたままにすると、先に開いた相手に設定を済まされるおそれがあります。編集部のサーバーにも、インストーラーのパスを探すアクセスが、この期間に 43 件届いていました。
6. 自分のドメインの発行を見張る: 次の節で説明します。

自分のドメインを見張る

• 検索する: crt.sh は、公開の CT の記録を検索できるサイトです。自分のドメインを入れて、どの名前が載っているかを確かめます。
• 知らせを受ける: Cert Spotter などの見張りの道具は、登録したドメインに覚えのない証明書が出たら知らせます。CT の公式サイトに、道具の一覧があります。料金や条件は、それぞれの公式のページで確かめてください。
• 発行できる認証局をしぼる: DNS の CAA レコードに、証明書を発行してよい認証局を書きます。認証局は、発行の前にこのレコードを確かめます。Let's Encrypt だけを許す例は、次のとおりです。

example.com.  IN  CAA  0 issue "letsencrypt.org"

見張りと CAA では、調べに来るアクセスは止まりません。1〜5 と組み合わせます。

AI の道具を動かすサーバーの守り方は、サーバーで AI を動かすメリットとは？ VPS で使う code-serverにまとめています。

まとめ