在Akka,SSL和證書管理方面,有幾個關於stackoverflow的問題來實現Akka actors之間的安全(加密)點對點通信。簡單的Akka ssl加密
有關遠程處理的Akka文檔(http://doc.akka.io/docs/akka/current/scala/remoting.html) 指示讀者將此資源作爲如何生成X.509證書的示例。
http://typesafehub.github.io/ssl-config/CertificateGeneration.html#generating-a-server-ca
由於演員都在內部服務器上運行,服務器CA爲example.com
(或任何真正的DNS名稱)的一代人似乎無關。 大多數服務器(有關Amazon Web服務運行例如EC2實例)將在VPC運行和初始阿卡遙控器就會像
remote = "akka.tcp://[email protected]:2553"
我的理解私有IP地址,是它應該是可能的創建一個自簽名證書並生成所有同行共享的信任存儲。
隨着更多的Akka節點聯機,它們應該(我假設)能夠使用所有其他節點使用的相同的自簽名證書和信任存儲。我還假設,即使您沒有CA,也不需要信任所有擁有不斷增長的證書列表的同行,因爲信任存儲會驗證該證書,並避免中間人受到攻擊。
理想的解決方案和希望 - 可以在沒有CA步驟的情況下生成一個自簽名證書,一個信任存儲文件,並在任意Akka遠程組合中共享/遙控器和遙控器,即所有的同行)
必須有一個簡單的按照流程來生成簡單的內部加密和客戶認證證書(只相信所有的同齡人一樣)
問:可以將這些全部是每個對等體上的相同文件,這將確保他們正在與受信任的客戶端通話,並啓用加密功能?
key-store = "/example/path/to/mykeystore.jks"
trust-store = "/example/path/to/mytruststore.jks"
問題:是X.509連接說明上述矯枉過正 - 有一個簡單的自簽名/信任存儲的方式,而不CA步驟是什麼?特別是僅針對內部IP地址(無DNS),並且證書中沒有不斷增加的IP地址網絡,因爲服務器可以自動擴展和縮減。
這似乎是一個security.stackexchange.com問題 – bob0the0mighty