トラブルシューティング
by Canonical on 15 April 2026
アップストリームの変更でスマートカードのFIPS認証が機能しなくなったときの対処方法
ある行政機関が組織内で運用しているUbuntuデバイスすべてにスマートカード認証を義務付けました。ところがコンプライアンス要件を満たすためにFIPSモードを有効にすると、スマートカード認証の機能が停止してしまい、1,000台近いシステムがFIPS認証への対応を待つことになりました。
Canonicalのサポートチームは、まずOpenSCのアップストリームでの変更が意図せずFIPSとの互換性を損なっていることを突き止めました。次に、すべてのディストリビューションのアップストリームの開発者と連携し、緊急用のホットフィックスと正式な修正の両方を提供しました。このときの対応を以下にご紹介しましょう。
はじめに：原因を突き止める
当初のエラーメッセージは一般的な認証失敗と同じでした。根本的な原因を示すものはありません。
Canonicalのサポートエンジニアはまず、Noble（24.04 LTS）テストシステムで問題を再現しました。pkcs11ツールはNobleのFIPS環境でセグメンテーションフォールトを起こしましたが、Jammy（22.04 LTS）では問題なく動作しました。この行政機関は、OpenSC、つまり各種のオペレーティングシステムで暗号用スマートカードを利用するためのオープンソースのソフトウェアツールキットを認証に使用していました。Ubuntu 22.04 LTSと24.04 LTSの間で、このOpenSCパッケージに何かの変更があったに違いありません。でも何でしょう？
問題の原因がFIPS対応の実装ではなく、アップストリームのOpenSCコードベースの変更にあると突き止めるまでに、数日もかかりませんでした。OpenSCのプロバイダー初期化におけるアップストリームの変更が、FIPSモードのOpenSSLとぶつかって障害を起こしていたのです。
調査：根本原因の確認
Canonicalは、OpenSSLとOpenSCの両方にアップストリームのバグを報告し、情報を求めました。そしてさらにデバッグを継続しました。
まもなく、FIPSに対応するOpenSSLプロバイダーの初期化に誤りがあることがわかりました。OpenSCがバックエンドでOpenSSLプロバイダーをFIPSプロバイダーではなくデフォルトのプロバイダーに設定していたため、スマートカード認証に必要なハッシュ処理がブロックされていたのです。
Canonicalは、これが根本原因であることを確認するテストを作成しました。そして依頼者の環境でテストしたところ、間違いはありませんでした。
この問題の原因は、エンタープライズLinuxにおけるアップストリーム依存の管理にありました。OpenSCが新しいリリースでプロバイダーの処理に変更を加えた結果、FIPSとの互換性を損なう動作が生じたのです。アップストリームにおける開発上の判断が、意図せず特定のコンプライアンス環境に影響を与えたということです。
このような場合に、アップストリームのどの変更が不具合を引き起こしたのかを特定し、理由を特定して最終的な修正を行うのがエンタープライズ向けのバグ修正サポートです。
修正：今すぐ対処、後で完全に解決
Canonicalは、OpenSCのメンテナンス担当者と協力し、最終的な診断に至りました。つまりアップストリームの変更により、OpenSCがFIPSポリシーに許可されないアルゴリズムをロードしようとしたことが問題の原因でした。OpenSSLは正しくNULLポインタを返しましたが、OpenSCはそれを有効なオブジェクトとして扱おうとしていました。しかも別の暗号オプションを試したり利用できる機能を確認したりすべきところを、エラーで終わっていました。
Canonicalのエンタープライズ向けバグ修正サポートは、機能を復旧する一般的な対策としてホットフィックスを共有しました。顧客のブロック状態を解消し、FIPSの導入を進めてもらうためです。
しかしホットフィックスは包括的な修正ではありません。この問題にはアップストリームでの対処が必要でした。つまり特定のディストリビューション向けのパッチではなく、OpenSC自体を修正し、UbuntuだけでなくFIPS環境でOpenSCを使用するあらゆるディストリビューションに対処する必要がありました。
今週、Canonicalは最終的な修正について合意しました。アップストリームのPRは現在マージ待ちです。マージが終わり次第、Ubuntuにバックポートします。これにより、同じ根本原因による3件の問題が解決される見込みです。
重要な要素：エコシステム全体での協力
この事例に対応したサポートチームのDariusz Gadomskiは、うまくいった理由を次のように振り返っています。
今回のケースでは、複数のグループによる協力が功を奏しました。みんな経歴は異なりますが、ユーザーの問題を解決するという目標は同じです。これがオープンソースの真の力です。多くの人が力を合わせ、みんなのために良いソフトウェアを作ります。
このバグの修正には、サポートエンジニアリング、Canonicalのセキュリティチーム、OpenSCのアップストリームコミュニティの協力が必要でした。最初は認証エラーに見えましたが、実際にはプロバイダー初期化に関するアップストリームの変更がFIPSとの互換性を損なっていました。診断には、OpenSC、OpenSSL、FIPSモードの相互作用を理解する必要があり、さらにアップストリームのメンテナンス担当者と協力して最終的な解決策を開発する必要がありました。
Ubuntu Pro +サポートによるバグ修正サポートについて
ニュースレターのサインアップ
関連記事
Ubuntu ProをNutanixのベアメタルKubernetesで提供
NutanixとCanonicalのパートナーシップ拡大によりコンテナ化されたワークロードの選択肢が増加 Enterprise Kubernetes®は、柔軟性の高いマルチアーキテクチャモデルへと進化しつつあります。AI/MLやデータ集約型のワークロードが膨大なハードウェアスループットを必要とする近年、組織はクラウドプラットフォームの安定性を維持しながら、ベアメタルのパフォーマンスを求めています。 このためNutanixとCanonicalは、このたび発表されたNKP Metalソリューションも含め、ベアメタルで実行するNKP（Nutanix Kubernetes Platform）インスタンスでもUbuntu Proを利用可能にしました。もともと2025年に発表されたパ […]
Ubuntu 26.04 LTSのセキュリティ最新情報
Ubuntu 26.04 LTSは、Canonicalにとって最もセキュリティを重視したLTSリリースです。単に機能を追加しただけでなく、システムのあらゆる層で同時にセキュリティの基準を引き上げ、全体的に強化しました。しかも既存の環境を壊したり、手動での介入が増えたりすることはありません。セキュリティの心臓部、つまりデフォルト設定に注力することで、CanonicalはUbuntuのセキュリティを新しい形で強化しました。この記事では、Ubuntu 26.04 LTSの新しいセキュリティ機能について概説します。 Ubuntu 26.04 LTS は、デスクトップ、サーバー、コンフィデンシャルVM、クラウドイメージ、エッジシステムでLinuxを運用する上で、今後10年間にわたっ […]
JammyからResoluteまで：Ubuntuのツールチェーンの進化
新しいツールチェーンのバージョン、devpack、開発体験を改善するワークフローをご紹介します。 Ubuntuのツールチェーンの進化は、単にGCC、LLVM、Pythonを提供することではありません。明確な目的を持つOpenJDKのバリアント、タスクに特化したdevpack、FIPS適合のツールチェーン、そしてsnap（新しい.NET snapやSnapcraftプラグインなど）の開発も含みます。このような改善により、これまで半日かかっていたセットアップが1〜2個のコマンドで済みます。これは、Ubuntu上でフレームワークやアプリケーションを開発する者にとって、まさに「摩擦のない」開発体験です。 このブログでは、Ubuntuの過去4年間のLTSリリースにおける変更点と今後 […]
