Tomcatの信頼できるストアとしてJava標準キーストア（$JAVA_HOME/jre/lib/security/cacerts）を使用していました。そしてそのTomcatサーバーは他のサーバーと通信します。最近のOS（AIX）のアップグレードでは、ファイルが$JAVA_HOME/jre/lib/security/cacertsに上書きされていたため、証明書が失われ、Tomcatにホストされているアプリケーションで多くの問題が発生しました。Java標準キーストアを使用することは悪い習慣です
$ JAVA_HOME/jre/lib/security/cacertsを中継するのは悪い習慣ですか？ このシナリオに取り組む代替（より良い|標準）方法は何ですか？
cacertsファイルの内容では、OSやブラウザにインストールされているデフォルトのCA証明書に頼るよりも必ずしも悪い習慣ではありませんが、それは素晴らしいことではありません。
日/ Oracleは、どこかJSSE Reference Guide about thisの真ん中に小さな「重要な注意事項」を持っている：
重要：/ libに/セキュリティにおける信頼されたルート証明書 の数が限られているJDKの船/ cacertsファイル。この ファイルをトラストストアとして使用する場合は、keytoolに と記載されているので、このファイルに含まれている証明書を維持する（すなわち、 追加/削除する）のはあなたの責任です。
連絡先のサーバーの証明書の設定によっては、 ルート証明書を追加する必要があります。適切なベンダーから必要な 特定のルート証明書を入手します。コンフィギュレーションの面では
は、私が「ローカル」CA証明書をインストールしなければならなかった、特定の用途のために、私はそれがより安定した（例えば、javax.net.ssl.trustStoreで指定）地元の信頼ストアを使用することを見つけます。
あなたの前提が正しいと仮定して、あなたのキーストアを置く場所に注意してください。私はそれがApacheフォルダの中に置かれることを強く勧めます。それはそれ自身のJVM :)あなたが輸入を繰り返しますビルドプロセスを持っている場合
GlassFishには独自のキーストアとcacertsもあります。 – Hiro2k
それは悪い習慣はありませんをもたらしますので、Websphereの中にデフォルトで
は、キーストアは、このように動作します。
はい、そうするのは悪い習慣です。
ベストプラクティスは、信頼できる証明書を必要なだけ制限することです。
アプリケーションで信頼されている証明書だけを使用して、独自のキーストアを使用する必要があります。
AIXのアップグレードはパッチです。どのパッチもユーザーデータを削除/上書きしてはいけません。この種のデータ損失の影響を受けるユーザーは、IBMにパッチ手順の修正を依頼することをお勧めします。これとは対照的に、httpdサーバのパッチはプログラムディレクトリ内にあっても設定を上書き/削除しません。
java_homeはプラットフォームによって異なる場合があります。私は個人的に別のハイブフォルダを探します。 – Tim