証明書ログ検索

誰でも読める台帳

TLS証明書は認証局（CA）が発行します。ブラウザは、リストにある100ほどの認証局のどれかが署名した証明書なら何でも信頼します。そのため長年、不注意な認証局や侵害された認証局が一つあれば、誰にも気づかれずにあなたの銀行のドメインの有効な証明書を発行できてしまいました。

Certificate Transparency（CT）がその穴をふさぎます。認証局はすべての証明書を、追記しかできない公開ログに提出しなければなりません。2018年4月からChromeは記録の証明がない証明書を拒否しており、Safariも同じルールを適用しています。ログはGoogle、Cloudflare、DigiCert、Sectigo、Let’s Encryptなどの企業が運営していて、誰でも検索できます。

これはあなたにとって両刃の剣です。自分が頼んでいないものも含め、ドメインに発行されたすべての証明書を見ることができます。同じことがほかの誰にでもでき、証明書に書かれた各ホスト名も見られます。

検索がログで行うこと

CTログの公開インデックスであるcrt.shに、登録ドメインとその配下のすべてを問い合わせます。結果は1時間保持します。そのうえで次のように処理します。

• 証明書は一度だけ数えます。発行はそれぞれ、プレ証明書と最終的な証明書としてログに2回現れます。発行元とシリアル番号が同じ項目はまとめます。
• サブドメインを集めます。各証明書の名前から集め、最新の証明書の日付順に並べます。*.example.com のようなワイルドカードは別に一覧にします。
• 最新の40の名前をDNSで解決し、まだどこかにつながっているかを確かめます。
• 発行元を集計します。全体と直近90日について数え、CAAレコードを公開していればそれと比べます。

履歴が非常に長いドメインでは、crt.shが一部しか返さなかったり、タイムアウトしたりします。その場合はページでお知らせし、まだ有効な証明書だけで代用します。

宙に浮いたCNAMEとサブドメイン乗っ取り

たとえば status.example.com が、かつて example.herokuapp.com へのCNAMEだったとします。誰かがアプリを削除し、DNSレコードを忘れました。この別名は今、誰でも取得できる名前を指していて、同じプラットフォームでその名前のアプリを作った人があなたのサブドメインへの通信を受け取ります。そこから、あなたのドメインでログインページを出し、その有効な証明書を取ることもできます。

ステータス列には、今日のDNSの答えが表示されます。

解決できる

名前にアドレスがあります。何もする必要はありません。

転送先なし（赤）

GitHub Pages、Heroku、Azure、Amazon S3、Netlify、Shopifyなど、放棄された名前を他人が再利用できることで知られるプラットフォームへのCNAMEで、転送先が NXDOMAIN を返します。緊急として扱ってください。

転送先なし（黄）

当方が把握していないサービスで同じ状況です。

消滅 / アドレスなし

サブドメイン自体がもう存在しません。無害ですが、名前はログに残ります。

修正は一手で済みます。CNAMEレコードを削除するか、サブドメインがまだ必要ならプラットフォームでリソースを作り直してください。そしてこれからは、ホスティングサービスを解約するときの手順に「DNSレコードを削除する」を入れてください。

発行元の表の読み方

ほとんどのドメインでは、認証局は1つか2つです。Let’s EncryptとGoogle Trust Servicesがよく出てくるのは、ホスティング会社やCDNが自動でそこに証明書を申請するからです。発行元に珍しいの印が付くのは2つの場合です。直近90日に発行していて、CAAレコードに載っていない場合。あるいは、CAAレコードがなく、証明書が10枚以上あるドメインでその発行元が2枚以下しか占めていない場合です。

珍しいからといって敵対的とは限りません。CDN、サイトビルダー、新しいランディングページツールを有効にすると、新しい認証局が一緒に入ってくることはよくあります。それらのサービスを管理している人に尋ねてください。誰も説明できない証明書なら、最後の表にあるcrt.shのリンクからシリアル番号を見つけ、その認証局に失効を依頼してください。

今後発行できる相手を制限するには、使っている認証局だけを指定したCAAレコードを公開します。

example.com.  CAA  0 issue "letsencrypt.org"
example.com.  CAA  0 issue "pki.goog"