使用Java標準密鑰存儲庫是不好的做法

我們一直在使用java標準密鑰存儲庫（$JAVA_HOME/jre/lib/security/cacerts）作爲tomcat的可信存儲區。那個tomcat服務器會和其他服務器通信。最近的一次操作系統（AIX）升級顯然覆蓋了文件$JAVA_HOME/jre/lib/security/cacerts，導致丟失的證書以及tomcat中託管的應用程序的許多問題。使用Java標準密鑰存儲庫是不好的做法

看着這是在$ JAVA_HOME/jre/lib/security/cacerts上轉發的壞習慣嗎？什麼是替代（更好|標準）的方法來解決這種情況？

來源

2011-10-25 ring bearer

java_home可能會因平臺而異，您將需要注意這一點。我個人會搜索不同的配置單元文件夾。 – Tim

對於cacerts文件中的內容，與使用安裝在操作系統或瀏覽器中的默認CA證書相比，這不一定是糟糕的做法，但這並不意味着它很好。

太陽/ Oracle的有一點點的「重要提示」中的JSSE Reference Guide about this中間的某個位置：

重要說明：JDK附帶受信任的根證書的/ lib/security中的有限數量/ cacerts文件。由於keytool中記錄了，因此如果您將此文件用作信任庫，則您有責任維護（即，添加/刪除）此文件中包含的證書。

根據您聯繫的服務器的證書配置，您可能需要添加其他根證書。從相應的供應商處獲取所需的特定根證書。

在配置方面，對於我已經安裝的「本地」 CA證書的具體應用，我覺得它更穩定，使用本地信任存儲（例如，與javax.net.ssl.trustStore指定）。

來源

2012-01-18 02:32:57 Bruno

不確定，但假設您的假設是正確的，請注意放置密鑰庫的位置。我強烈建議將它放在Apache文件夾中。

默認情況下，在WebSphere密鑰庫以這種方式工作，因爲它帶來了它自己的JVM :)

來源

2011-10-25 20:31:29

GlassFish也擁有自己的密鑰倉庫和cacerts。 – Hiro2k

如果你有一個構建過程將重複進口這不是一個不好的做法。

來源

2011-10-25 23:13:28 EJP

是的，這樣做是不好的做法。

最好的做法是必須根據需要限制您的可信證書。
所以你應該使用你自己的密鑰庫，只有你的應用程序信任的證書。

來源

2011-10-28 20:05:40 Cratylus

這違反了PKI的全部目的。這個想法是，信任根的存在允許形成一個信任鏈，以便您可以信任由受信任的CA簽名的任何證書。您正在認證中，這是PKI和證書的用途，授權是一個應用程序域問題。將這兩個單獨的功能結合起來基本上被打破了。 – EJP

@EJP：當你有一個端點僅與網絡中的特定實體進行通信時，爲什麼我會允許被我係統中配置的任何* CA信任的證書信任（無論是linux，java的ca證書，Windows證書等等）？ – Cratylus

AIX升級是一個補丁。任何補丁都不得刪除/覆蓋用戶數據。我建議受此類數據丟失影響的用戶請IBM修復修補程序。相比之下，httpd服務器的補丁即使在程序目錄中也不會覆蓋/刪除配置。

來源

2016-02-21 23:09:00 user250343

使用Java標準密鑰存儲庫是不好的做法

回答

相關問題