はじめに
- 認証局に発行してもらった証明書の発行状況は簡単に検索できてしまいます。非公表のつもりだったFQDNも，証明書を発行していたらFQDNが簡単にバレます。
- FQDNバレを防ぐため，ステージング用・開発用・テスト用などの公開したくないドメインはプロダクションとは分けましょう。
まず調べてみる
まず，ご自分が管理または所有するドメインをお持ちであれば，そのドメイン名を下記サイトに入力してみてください。
非公表のつもりだったFQDNが表示された方は，そのFQDNの存在は公開されているものと思ってください。
なぜ公表されているのか
不正な証明書の発行を監視するためです。Wikipediaによれば，2011年デジノター事件をきっかけに，不正な証明書の発行に対する取組みが始まったそうです。証明書発行の透明性を担保するCT(Certificate Transparency)として，RFC9162に規定されています。
証明書発行ログとは
RFC9162に規定されています。
証明書発行時
認証局が証明書を発行するタイミングで公開ログサーバに仮の証明書を送信してSCTを発行してもらいます。申請者に対して，証明書にSCTを埋め込んで発行します。SCT（Signed Certificate Timestamp）とは，TLS証明書が公開ログサーバに追加されたことを示す署名つきタイムスタンプです。
例えばqiita.comのサーバ証明書を見ると，以下3つのSCTが登録されていました。
証明書発行後
ブラウザがHTTPSのサイトにアクセスする際に，証明書に記載されたSCTと公開ログサーバの情報を突合し，証明書の正当性を検証します。（Chrome,Edgeは実装していますが，Firefoxは実装していないそうです。そもそもCTの言い出しっぺはGoogleなので，Chrome,Edgeへの実装はむべなるかな）
例えばqiita.comでcrt.shを検索すると以下のように登録されています。おそらく証明書のsha256フィンガープリントとログサーバ上のフィンガープリントなどを比較していると思われます。
公開ログサーバ
以下のサイトで，公式に運用されているログサーバの一覧を確認できます。
Chromeが検証している公開ログサーバのURIのリストです。
証明書発行ログが公開されていることによるメリット
- 第三者による証明書の発行を検出できる
もし意図せず第三者が証明書を発行していた場合に証明書の検出ができます。もし自分が発行したはずのない証明書が検索結果にあったら，誰かが証明書を不正に取得して悪用しているかもしれません。
証明書発行ログが公開されていることによるデメリット
- 証明書を取得したFQDNが公開されてしまう
非公開にしたかったはずのFQDNも例外ではなく，証明書を発行してしまえば検索対象になるのでその存在が明らかになってしまいます。証明書を発行したということは，何らかの形でそのFQDNで証明書を使う予定がある・使っていることを示唆します。例えば，AWS Certificate Managerのようなサービスで一時的にでも証明書を発行した場合にはログに残ってしまいます。
非公開運用中のドメインの危うさ
悪意のある第三者に非公開前提のFQDNがばれてしまうことで，攻撃の対象とされる恐れがあります。devとかstagingとかtestといった文字列を含むFQDNは，開発用・テスト用であることがあからさまに判別できます。開発用やテスト用のドメインで運用しているサーバやサービスは，（偏見かもしれませんが）プロダクション用と比較してセキュリティ対策が甘いケースがあるようなので注意が必要です。もちろんプロダクション相当の対策を実施していたり，接続元IPアドレス制限をするなどの適切な対処をしていれば攻撃されるリスクは低くなります。
証明書発行ログの確認方法
再掲ですがhttps://crt.shで確認できます。crt.shでは，公開ログサーバに対してまとめてクエリー投げ，その検索結果を表示してくれるようです。
まとめ
- 認証局に発行してもらった証明書の発行状況は簡単に検索できてしまいます。非公表のつもりだったFQDNも，証明書を発行していたらFQDNが簡単にバレます。
- FQDNバレを防ぐため，ステージング用・開発用・テスト用などの公開したくないドメインはプロダクションとは分けましょう。
- 記事の内容が①CTの説明と，②プロダクションとテスト用開発用でFQDNを分けましょう，で多少ごっちゃになってます。タイトルの主旨的には②がメインです。