ALB の相互認証機能を試してみる 「トラストストアで検証」編 【続き】失効リスト機能を試してみた

記事タイトルとURLをコピーする

こんにちは😺 カスタマーサクセス部の山本です。

前回、ALB の相互認証機能を試してみました。
ALB の相互認証機能を試してみる 「トラストストアで検証」編 - サーバーワークスエンジニアブログ

今回はその続きで、失効リスト機能を試してみました。
本記事では前回の記事で作成したクライアント証明書を失効させてみるので、併せて呼んでいただけると嬉しいです。

失効リスト機能を試してみる

失効リストの作成

まずは 認証局サーバーにログインして、失効リストを作成します。
まず、認証局が発行した証明書の状態を追跡するためのテキストファイルを作成します。

touch index.txt

次に、失効リストを作成するための設定ファイルを作ります。vi エディターなどを使って以下のファイルを作成ください。

  • crl.cnf
[ ca ]
default_ca = CA_default

[ CA_default ]
dir = ./
database = $dir/index.txt
private_key = ./rootCA.key
certificate = ./rootCA.pem
default_crl_days = 30
crl_extensions = crl_ext
default_md = sha256

[ crl_ext ]
authorityKeyIdentifier = keyid:always

最後に失効リスト (crl.pem) を作成します。

openssl ca -gencrl -out crl.pem -config crl.cnf

作成した失効リスト (crl.pem) を見てみます。

openssl crl -in crl.pem -noout -text

No Revoked Certificates.

となっており、今のところ失効リストは空です。

前回の記事で作成したクライアント証明書を失効させてみます。

openssl ca -revoke clientcert.pem -config crl.cnf

失効リスト (crl.pem) を再作成し上書きします。

openssl ca -gencrl -out crl.pem -config crl.cnf

上書きした失効リスト (crl.pem) を見てみます。

openssl crl -in crl.pem -noout -text

Revoked Certificates: Serial Number: 1A82639C47B8F76E7155446DBB5AC324A582F5D5 Revocation Date: Feb 13 10:20:47 2024 GMT

となっており、失効リストに追加できました。
index.txt も見てみると、失効リストに追加したクライアント証明書の情報を確認できました。

R 250207113454Z 240213102047Z 1A82639C47B8F76E7155446DBB5AC324A582F5D5 unknown /C=JP/ST=Yamanashi/L=Tsuru/O=shika-darake/OU=tech/CN=sample-2

失効リストをトラストストアに追加する

S3 に失効リストをアップロードします。

EC2 のサービス画面で左ペインの「ロードバランサー」枠内に「トラストストア」があります。

ロードバランサーのリスナールールに関連付けたトラストストアを選択し、失効リストを追加します。

失効リストの追加ができました。

失効リストの追加によって、対象の WEB サイトに接続できなくなっています。

確認

curl で接続してもエラーになります。

curl https://test.yamaaazon.com -v --key clientkey.pem --cert clientcert.pem

他のクライアント証明書を使った場合は、引き続きアクセスできました。

補足

上記の例では、失効リストを作成する際にその有効期限を30日間に設定しています。
これは、default_crl_days = 30という設定によるものです。しかし、失効リストの期限が切れていても、そのリストがトラストストアにアップロードされ、証明書に失効IDが付与されている場合、その証明書は失効と判断されます。また、失効リストの期限が切れていても、有効なクライアント証明書を使用して、クライアント認証を行うことが可能でした
トラストストアを使う際には、失効リストをトラストストアにアップロードし失効IDが付くと、リスト内の証明書は無効とされます。 逆に、失効IDを削除すると、リスト内の証明書は再び有効となります
参考、失効リストの削除画面:

参考ドキュメント:
docs.aws.amazon.com

証明書失効リストが信頼ストアに追加されると、失効 ID が割り当てられます。失効 IDs、トラストストアに追加された失効リストごとに増加し、変更することはできません。証明書失効リストが信頼ストアから削除されると、その失効 ID も削除され、信頼ストアの存続期間中は再利用されません。

もう少し補足として、openssl で作成する失効リストに期限が設定されている理由をお伝えします。これは、証明書の管理者が定期的に失効リストを確認し、新たに失効した証明書をリストに追加するように促すためです。例えば、default_crl_daysが30日に設定されているなら、少なくとも30日ごとに失効リストを更新する必要があります。 30日が過ぎて失効リストが期限切れになった場合、その間に失効した証明書がまだリストに反映されていない可能性があります。このような状況を防ぐために、「失効リストの期限が切れている時には、失効リストに含まれていない証明書でも認証を拒否する」という方法を採用したい場合もあります。 しかし、このような方法を採用したい場合、今回のトラストストアは適していません。トラストストアを利用する場合は上述したように、トラストストア上に失効リストの追加・削除を行い、失効IDを使って失効リストを管理します。

まとめ

失効リスト機能を試してみました! 次回は ALB のアクセスログに記録される、相互認証のログを見てみようと思います。

余談

山の写真(サムネ用)です。
最近はあんまり山に行けてません。
戸狩温泉スキー場から見る越後三山です。

山本 哲也 (記事一覧)

カスタマーサクセス部のエンジニア(一応)

好きなサービス:ECS、ALB

趣味:トレラン、登山(たまに)