【ITニュース解説】certificate authority ( ca ) config for fedora distro

インターネットでの安全なやり取りには、通信相手が本物であることを確認する仕組みが不可欠だ。この確認を行うのが「認証局（CA）」であり、CAが発行する「デジタル証明書」がその信頼の証となる。ウェブサイトがこの証明書を持っていることで、ユーザーはそのサイトが偽物でなく、通信が暗号化されていることを信頼できる。特に、ウェブサイトとブラウザ間の暗号化通信に使う技術はTLS/SSLと呼ばれ、デジタル証明書はこの技術の根幹をなしている。

Linuxディストリビューションの一つであるFedoraも、これらのデジタル証明書をシステム全体で管理する仕組みを持っている。近年では、ca-bundle.trust.p11-kitというツールを使ってシステムが信頼するCA証明書が一元的に管理されており、以前とは異なる方法で証明書が更新されるようになった。

今回解説する記事の筆者は、このシステムが信頼する証明書の中から、一部のサードパーティ製、特に特定の国が発行する証明書（記事では中国のCNNICが例に挙げられている）を削除するという、非常に個人的な設定変更を行った。筆者は、オープンソースの証明書、例えばLet's Encryptのようなものだけを信頼する形にしたのだ。この変更の背景には、特定のCAに対する信頼性の懸念があったと推測される。

しかし、この変更には大きな影響が伴った。多くのウェブサイト、例えばGitHubのような著名なサービスも、削除された証明書に依存していたため、筆者の環境からはアクセスできなくなってしまった。これは、インターネット上の多くのサービスが、広範なCAの証明書を信頼する前提で成り立っていることを示している。自身のセキュリティポリシーを厳格に適用することは重要だが、それが利便性やアクセシビリティとのトレードオフになることを理解する必要がある。

システム内で証明書を利用する環境は大きく二つある。一つはcurlのようなコマンドラインツールや、システムサービスが利用する「アプリケーションベースの環境」だ。もう一つはFirefoxやTor Browserのような「ブラウザベースの環境」である。これらは通常、異なる設定ファイルや場所を参照して証明書を管理している。アプリケーションベースの環境では、/etc/pki/ca-trust/sourceや/usr/share/pki/ca-trust-sourceといったディレクトリが使われ、それぞれ優先度が異なる。ブラウザは独自の証明書ストアを持つことが多い。

筆者は、これら異なる環境すべてで自身の選んだ証明書設定を使いたいと考えたが、そのためにはそれぞれの環境で個別に設定が必要だった。当初、Fedoraに用意されているtrust cliというコマンドラインツールを使って証明書を設定しようとしたが、標準で含まれるMozillaのCAバンドルは読み取り専用で、このコマンドでは変更できなかった。そこで筆者は、直接設定ファイルを編集するという、より踏み込んだ方法をとった。

具体的には、システムの信頼する証明書が格納されている元の設定ファイルの各行の先頭に#を付けてコメントアウトするか、行自体を削除した。コメントアウトは、その行を無効にするものの、元の内容を保持する方法である。また、念のため元のファイルのバックアップを作成し、設定ディレクトリの外に移動させた。この操作により、システムが信頼する証明書のリストから不要なものが除外された状態を作ったわけだ。その後、sudo update-ca-trustというコマンドを実行することで、システム全体のCA証明書リストが筆者の意図通りに更新された。このコマンドは、設定ディレクトリ内の変更を読み込み、システム全体に新しい信頼リストを適用する役割を担う。

このようなシステムレベルでのCAルート証明書の変更は、広範囲に影響を及ぼす。例えば、XMPPやWebSocketsといった、証明書に依存する様々な通信プロトコルが影響を受ける。これらのプロトコルは通信相手の身元確認に証明書を使うため、信頼リストから外れたCAが発行した証明書を持つ相手とは通信できなくなる。また、TLS/SSL、Java、EDK2といったセキュリティ技術を利用するアプリケーション、具体的にはFedoraのソフトウェアミラーサイトやRPMパッケージのリポジトリなども、変更された証明書リストに基づいて通信相手を信頼するかどうかを判断するため、アクセスできなくなる可能性が生じる。システム上のあらゆる信頼関係が再構築されるため、関連する他の設定も適切に変更する必要があるのだ。

最終的に筆者は、インターネット上の公開鍵基盤（PKI）において、自身で証明書、特にルート証明書を管理することが最善の選択肢であると述べている。これは、外部のCAに依存せず、自分自身で信頼の鎖の根元をコントロールすることで、セキュリティや信頼性を完全に自己責任で管理するという考え方だ。OpenXPKIのような個人向けのソリューションや、Hyperledger Fabricのような企業向けのソリューションが、自己管理CAの実現手段として挙げられている。

この方法は、確かに究極のコントロールと信頼性をもたらす可能性があるが、一方で証明書の管理や更新、セキュリティの維持といった大きな責任を負うことになる。システムエンジニアにとって、このようにシステムレベルでセキュリティの根幹を理解し、必要に応じてカスタマイズする能力は非常に重要であり、今回の記事は、その一例として学ぶべき示唆に富んでいると言えるだろう。システムの設定変更を行う際には、その影響範囲を十分に理解し、慎重に進めることが求められる。