好的高級SSL gals和傢伙 - 我會在兩天後爲此添加獎金,因爲我認爲這是一個複雜的主題,值得任何想法答案。高級SSL:中級證書頒發機構和部署嵌入式盒子
這裏的一些假設只是:假設,或者更精確的有希望的猜測。想想這是一個腦筋急轉彎,簡單地說'這不可能'就是沒有意義。
替代和部分解決方案是值得歡迎的,如果你做了一些「類似」的個人經驗。即使我的整個計劃有缺陷,我也想從中學到一些東西。
這裏的情景:
我一個嵌入式Linux系統的開發,並想其Web服務器能夠服務外的開箱,沒有爭議的SSL。這裏的設計標準,我的目標:
必備品:
- 我不能讓用戶加我的自產自銷的CA證書,以他們的瀏覽器
- 我不能有用戶添加一個靜態生成的(在製造時間)自簽名證書到他們的瀏覽器
- 我不能讓用戶在他們的瀏覽器中添加一個動態生成的(在引導時間)自簽名證書。
- 我無法默認使用HTTP併爲SSL啓用/禁用切換。它必須是SSL。
- 嵌入式盒子和網絡瀏覽器客戶端都可能有或沒有互聯網接入,因此必須假設沒有互聯網接入才能正常工作。我們唯一可以依賴的根CA是與操作系統或瀏覽器一起提供的。讓我們假設這個列表在整個瀏覽器和操作系統中基本上是相同的 - 即如果我們依賴它們,我們將有〜90%的成功率。
- 我不能使用即時通訊操作,即'Fast Eddie的SSL證書清算中心 - 價格低至我們的服務器必須被黑客入侵!「
很高興富人:
- 我不希望警告用戶該證書的主機名不匹配的瀏覽器的主機名。我認爲這是一件好事,因爲這可能是不可能的。
不想:
- 我不想出貨同一組每盒靜態鍵。 '不能'列表暗示的那種,但我知道風險。
是的是的,我知道..
- 我可以做爲用戶提供一種機制來上傳自己的CERT /關鍵,但我認爲這是「高級模式」和超出範圍這個問題。如果用戶足夠先進,擁有自己的內部CA或購買密鑰,那麼它們非常棒,我喜歡它們。
思想帽時間
我與SSL的經驗已經生成的證書/密鑰由「真正的」根,以及加緊我的比賽被簽署使我自己的內部CA一點點,在內部分發'自簽名'證書。我知道你可以鏈接證書,但我不確定操作的順序是什麼。即瀏覽器是否「走上」鏈條看到一個有效的根CA並將其視爲有效的證書 - 或者您是否需要在每個級別進行驗證?
我碰到了intermediate certificate authority的描述,這讓我想到了潛在的解決方案。我可能已經從「簡單的解決方案」到「噩夢模式」走了,但它是可能的:
瘋狂的想法#1
- 找一個「真正的簽署中間證書頒發機構的證書'CA. (ICA-1)
- ROOT_CA - > ICA-1
- 此證書將在製造時用於產生每一個框唯一密碼的子中間證書授權機構對。
- ICA-1 - > ICA-2
- 使用ICA-2來生成一個唯一服務器證書/密鑰。這裏需要注意的是,你可以爲IP(而不是DNS名稱)生成密鑰/對嗎?即一個潛在的用例就是用戶最初通過http連接到該框,然後使用重定向URL中的IP將客戶端重定向到SSL服務(這樣瀏覽器就不會抱怨不匹配)。這可能是使房子失靈的卡。由於SSL連接必須在任何重定向發生之前建立,我可以看到這也是一個問題。但是,如果這一切都神奇地運作
- 我可以使用ICA-2在盒子更改IP時隨時生成新的證書/密鑰對,這樣當Web服務器恢復時,它總是有一個「有效的」鑰匙鏈。
- ICA-2 - > SP-1
好吧,你這麼聰明
最有可能的,我複雜的解決方案是行不通的 - 但它會是如果是的話,那很好。你有類似的問題嗎?你做了什麼?什麼是折衷?
也許你仍然可以使用普通的HTTP將私有根CA或服務器自簽名證書上傳到用戶的瀏覽器?它可以在服務器安裝時以「一鍵式」方式完成(確定,不是一個但非常簡單)。 「沒有HTTP,沒有證書安裝」真的必須? – blaze
不幸的是,'必須擁有'是基於對當前使用自簽名證書進行點擊的解決方案的否定迴應。但在與我們的幾位客戶支持者交談後,顯然與拍攝客戶的狗一樣糟糕。這對於屁股來說是一種痛苦,而且對於Firefox對於自簽名證書的日益增長的胡思亂想的態度沒有幫助。這有點讓我爲明星拍攝,必須有更好的方式。 auth_digest沒有解決它,SRP-TLS在某些方面更加接近,但在支持方面它仍然是前衛。 – synthesizerpatel