今日になって問題のサービスプロバイダのサポートから電話があり、
「サーバー証明書の変更作業は事前にアナウンスができない。
TLS接続障害が出たら都度Thunderbird側で証明書をインポートし
復旧させる判断をして欲しい」
とのこと。万一偽サーバーに誘導されてたらどう判断すればいいんだか…。
偶然的通行人 さんが書きました:
OS の種類など使用環境についての最低限の情報を書き添えることをお勧めします。
ご指摘ありがとうございます。OS非依存と思い込んで記載を忘れてました。
プラットフォームは Windows7 Professional SP1 で、数台での運用の
ためドメイン・ActiveDirectoryは使用していません。
偶然的通行人 さんが書きました:
・Firefox 52以降でのルート証明書の自動インポート機能でできること、できないこと - ククログ(2017-06-01)
http://www.clear-code.com/blog/2017/6/1.htmlWindows では OS が標準で持つ証明書の自動アップデートが可能です。Microsoft 社が管理・提供するこれらのルート証明書を信頼するのであれば、半ば自動的に最新の証明書を Thunderbird 52.x 系で利用できる可能性はあると思います
参照してみましたが、Windowsが持つ証明書ストアを全て参照する
のではなく、ActiveDirectoryなどを使用したエンタープライズ運用において、
組織内向けに付加した証明書だけThunderbird(52以降)側にマージできるという
機能のようです。マイクロソフト側で更新している主要な証明書部分は対象外でした。
リンク先の方が書いておられるように
「ユーザー側の期待と実際の挙動との間に若干の齟齬が見られる」
という状況です(残念)
メール不通の復旧を急ぐため、とりあえず問題のサーバー証明書の
発行元になっている認証局証明書をFirefox52.5.2ESRから抽出し、
個別のThunderbirdにインポートしました。
さて、今更気が付いたのですが、本体のバージョンアップに附帯して
証明書が更新されているFirefox52ESRと、共通基盤を持ちながらも
証明書更新が止まっているThunderbird52の間で、証明書ストアで
あるプロファイル内のcert8.dbは共有ないし転用ができないもの
でしょうか?
そもそも共通基盤を持つMozillaのプロダクトなのに、
開発部隊が分かれた結果、一方の cert8.db が凍結されているのが
今回の問題の遠因ですね。