技術

crt.shを使って証明書の発行履歴を確認する

はじめに

CTログサーバと呼ばれている「認証局による誤発行や悪意のある攻撃者などによる不正な発行を検知する仕組みをログとして管理しているサーバ」があるとのことで、実際に自分のドメインを入れて確認してみる。 https://www.nic.ad.jp/ja/basics/terms/ct.html

CTについて

CT（Certificate Transparency）は、インターネット上でのセキュリティと信頼性を向上させるための仕組みであり、
具体的には、SSL/TLS証明書の発行や使用状況を透明化し、不正な証明書の検出や悪意のある行動の防止を支援するものである。

CTログサーバとは

具体的に使用状況をログとして残しているサーバを確認できるサイトとして、https://crt.sh がある。
今回はこのサイトを利用して、k-bushi.com に関連する証明書の発行履歴を見てみる。

crt.shを使う

発行履歴を確認する

実際に、k-bushi.comの発行履歴を確認してみる。

https://crt.sh/?q=k-bushi.com

confirm-crt-for-crt-sh

さて、それぞれ意図した証明書の発行なのかを確認していく。

行番号crt.sh IDLogged AtNot BeforeNot AfterCommon NameMatching IdentitiesIssuer Name
1123374318832024-03-102024-03-102024-06-08blog.k-bushi.comblog.k-bushi.comC=US, O=Let’s Encrypt, CN=R3
2123374305712024-03-102024-03-102024-06-08blog.k-bushi.comblog.k-bushi.comC=US, O=Let’s Encrypt, CN=R3
3121155371282024-02-182024-02-182024-05-18k-bushi.comk-bushi.comC=US, O=Let’s Encrypt, CN=R3
4121155301392024-02-182024-02-182024-05-18k-bushi.comk-bushi.comC=US, O=Let’s Encrypt, CN=R3
5121150900282024-02-182024-02-182024-05-18www.k-bushi.comwww.k-bushi.comC=US, O=Let’s Encrypt, CN=R3
6121150832202024-02-182024-02-182024-05-18www.k-bushi.comwww.k-bushi.comC=US, O=Let’s Encrypt, CN=R3
7118073164242024-01-202024-01-202024-04-19k-bushi.com*.k-bushi.com k-bushi.comC=US, O=Google Trust Services LLC, CN=GTS CA 1P5
8118073218732024-01-202024-01-202024-04-19k-bushi.com*.k-bushi.com k-bushi.comC=US, O=Google Trust Services LLC, CN=GTS CA 1P5

まずは、1,2行目から見ていく、blog.k-bushi.com のものである。blog.k-bushi.com はHugoで構築したブログ(このブログ)をNetlify にホスティングしており、証明書の設定もしているので、これのことだろう。
2行にわたっているのはなんでだろうと思ったが、どうやら3行目のものは事前証明書 というもので、2行目はリーフ証明書というもののようだ。

3,4,5,6行目について、k-bushi.com, www.k-bushi.com については、Vue3+Vuetifyで作成したポートフォリオサイトをVercelにホスティングしており、証明書の設定もしている。

7,8行目について、k-bushi.com の本体に対して、 ワイルドカード証明書を発行しており、発行元が Google Trust Services LLC のものである。
この証明書は、Firebaseを使っていたころに自動で発行してくれていたものと記憶しているのだが、実はもうFirebaseを使っておらずの状態。
ただ、現在 k-bushi.comを含む、各サブドメインにアクセスするとこの証明書が使われている。
これは見直さないとな…。

意図していない発行履歴の確認

crt.shのサイトで k-bushi.comで検索して確認してみると、Common Name に見知らぬドメイン名があった。
このドメインは何なのか、どのような証明書の発行をしているのかを見てみる。
(怖いサイトだったら嫌なので、ドメインにはアクセスしません。)

invalid-issue-01

事前証明書の確認 invalid-issue-02 なんだこの、SANに書いてあるDNS名の数は！？

※補足: CN(Common Name)が非推奨となっており、それに置き換わる形で SAN(Subject Alternative Name)が使われている。

リーフ証明書の確認 リーフ証明書が作成されているようだった。

invalid-issue-03

※このような証明書を作られたくない場合はどうすればよいのかなどを調査してみる。

リーフ証明書とは

証明書は、そのサブジェクトが証明書内の公開キーの所有者であることを確認するデジタル・ドキュメントです。
証明書は、エンド・エンティティ証明書またはリーフ証明書とも呼ばれます。
エンド・エンティティ証明書は、他の証明書の署名に使用できない証明書です。
たとえば、TLS/SSLサーバーおよびクライアント証明書、電子メール証明書、コード署名証明書、限定証明書はすべてエンド・エンティティ証明書です。

https://docs.oracle.com/ja-jp/iaas/Content/certificates/overview.htmより引用

とあるので、リーフ証明書は、今回のサーバ証明書のことであっているようだ。

1件だけ Leaf証明書の発行履歴の中身を見てみる。

Summary: Leaf certificate となっている。

leaf-certificate

事前証明書とリーフ証明書の違い。
diff-leaf-pre-certificate

事前証明書とは異なり、SCT(Signed Certificate Timestamp) というタイムスタンプが付与されていることがわかる。
(左がリーフ証明書、右が事前証明書)

事前証明書とは

証明書について申請者から発行申請があった際に、認証局がCTログサーバに送る事前の証明書のこと。

[*1]プレ証明書: Certificate logsへの登録時に、認証局が事前作成する証明書。

https://jprs.jp/glossary/index.php?ID=0235

記載の通り、事前証明書→リーフ証明書の流れになっているようだ。

pre-certificate

おまけ: CAAレコードについて

証明書を特定の認証局にのみ発行許可をする「CAAレコード」がある。
これを利用することで、意図しない不正な証明書の発行を防ぐことができる。
https://jprs.jp/glossary/index.php?ID=0218

CAAレコードに対応していないドメイン管理サービスもあるので、まずは対応しているかどうかを確認する必要がある。
ちなみにぱっと検索すると、自分が使っている Cloudflare はあるようだった。

参考

© 2020 - 2024 kbushi
Hugo で構築されています。
テーマ Stack は Jimmy によって設計されています。