通常，通過檢查簽名層次來驗證證書。 MyCert 由 IntermediateCert 簽名，而IntermediateCert 由 RootCert 簽名，並且RootCert列在計算機的“信任證書”存儲中。

證書固定是您忽略整個事情的地方，並說僅信任此證書，或者僅信任此證書籤名的證書，而忽略了所有其他根CA否則可能成為信任錨。它通常也稱為“密鑰固定”，因為實際上是保存了公共密鑰哈希。

但是實際上，“密鑰固定”導致的問題多於解決的問題。站點所有者經常對其進行錯誤配置，並且如果站點受到破壞，攻擊者可能會惡意地鎖定站點所有者無法控制的證書。 Key Pinning在2017年已棄用，並於2019年11月從Chrome和Firefox中完全刪除。IE和Safari從未支持它。

建議的替代方法是使用 Expect -CT標頭，告訴瀏覽器要求證書顯示在“證書透明性”日誌中。

這是模棱兩可的，但是它指的是SSL證書鏈驗證中的問題的解決方案。本質上，對SSL的信任可以歸結為根證書，即係統信任的證書是真實的。那些隨操作系統或瀏覽器一起提供。如果其中之一遭到破壞，則此簽名和可傳遞簽名的證書的所有證書都將被視為受到破壞。

• TACK或公共密鑰固定擴展（顯然是被chrome稱為cert固定）允許服務器的管理員將證書頒發機構（CA）的公鑰簽名“固定”到證書，該證書由客戶端驗證（通過SSL擴展提供）。如果在檢索證書鏈時CA證書的密鑰不同，則可能會損害CA證書。源

• 證書固定也可以參考在您的信任庫中導入主機的證書，而不是信任CA證書。這樣可以減輕CA證書被洩露的風險，但是如果證書手動失效，則會強制您更新證書。源

SSL服務器證書來自 X.509世界。客戶端通過驗證證書頒發機構中的許多加密簽名來驗證服務器證書的有效性。該方案的優點在於它是無狀態的：給定的服務器可以每五分鐘更改一次證書，並且仍然可以與客戶端一起使用。

有人認為，儘管支持快速旋轉的證書非常棒，但卻沒有用，因為實際上，給定的服務器每年每 更改一次證書；的確，儘早進行證書轉換錶明某些漁業活動正在進行。 證書固定是服務器聲明這種情況不應在正常情況下發生的一種方法，並且如果發生意外的證書切換，客戶端應該引起隱喻的注意。這是協議擴展，建議但尚未得到廣泛支持。實際上，似乎有一些相對相似的競爭性提議。

另請參閱融合，這是又一個協議擴展，可以看作是“受信任的第三方的證書固定”。融合和證書固定提案都圍繞著相同的核心思想，即在客戶端（或至少在某個地方）具有一些 state ，並在證書更改得太頻繁或過早時觸發安全警告。這些提議中的任何一項是否會被廣泛接受（即IE，Firefox，Chrome和Safari將以兼容的方式實現，大多數SSL服務器系統管理員將使用和）。 / p>

通常，HTTPS連接中發生的情況是，客戶端從其通過https與之通信的SSL兼容服務器請求SSL證書。服務器將從其密鑰庫中提供證書。客戶端收到此證書後，它將根據

• 主機名是否與所請求的主機名相同
• 具有可驗證的信任鏈回到受信任的（根）證書來驗證其憑據。客戶端信任存儲]

現在，如果代理已建立連接，並且您可以使設備信任您的（惡意）根CA證書，則可以攔截安全連接。這本質上是中間人攻擊。現在，這裡發生了SSL固定，這可能會增加中間人攻擊的額外安全層-

App會將已知的服務器證書與自身捆綁在一起。當應用嘗試與服務器建立安全連接時，它會使用捆綁的證書來驗證服務器收到的證書。因此，即使OS根據（可能是惡意的）根CA驗證了接收到的證書鏈，該應用程序也會拒絕顯示網絡錯誤的連接。

注意：我已經嘗試從SSL固定的角度回答此問題。在Android Apps中。在此類應用程序中，很容易實現SSL固定，因為該應用程序已經知道它將要連接的服務器（主機名）。但是，可能難以在瀏覽器中實現相同的功能。我認為Chrome瀏覽器已經實現了此功能。

我還編寫了一個示例代碼，演示了Android中的證書固定。您可以在 github上找到它。您還可以在 playstore上找到同一應用。

更多信息：

• http://nickfishman.com/post/ 50557873036 / reverse-engineering-native-apps-by-intercepting-networking
• http://blog.lumberlabs.com/2012/04/why-app-developers-should -care-about.html

證書固定可繞過標准證書頒發機構鏈，以減輕向犯罪分子簽發有效證書的風險。

尋求新解決方案的動機...

SSL / TLS證書由其他證書籤名。當在此簽名鏈的某個位置找到可信實體時，瀏覽器通常會認為證書有效。受信任實體的簽名來自操作系統和瀏覽器的基本安裝。它是大約100個實體的嵌入式列表。

如果其中一個受信任的證書頒發機構遭到破壞，或者證書頒發機構是欺詐行為的受害者，則他們可以向犯罪分子頒發有效證書。犯罪分子會以您的名義擁有完善的SSL / TLS證書。犯罪分子將能夠進行成功且可信的“中間人”攻擊。用戶將在您的網站上看到有效的證書信息。

而且，說服用戶安裝新的可信證書頒發機構也不難。例如，在巴西，主流瀏覽器無法識別官方證書頒發機構，因此每個人都必須安裝其他證書頒發機構。瀏覽器對此非常擅長：僅單擊鏈接並回答是。為了達到這種可用性，我相信這是全球範圍內的常見任務。

不能完全信任證書頒發機構。獲得證書的過程絕不是安全的。我已經在一家公司買了一個，只花了一點錢。當然總比沒有好。但是需要改進。

固定是什麼？

在首次訪問網站secure.example.com時，網站向客戶端瀏覽器發送了一條隱藏消息，該消息大致翻譯為：

”在接下來的N天內，secure.example.com網站將使用證書CECECECE。在此期間，即使證書頒發機構聲稱該證書對本網站有效，也不接受其他證書。在 http://100.200.100.200/callbacks/warn_pinning.php“ 通知我。

固定解決了問題嗎？

這不能解決證書頒發機構證書籤名過程的弱點。 但要最小化犯罪分子與中間襲擊者相處的機會之窗。只有讓用戶首次訪問該網站，該攻擊才會起作用。

它類似於SSH安全性。首次訪問時，將保存服務器密鑰的簽名。如果將來訪問該標識不匹配，則係統將生成警告。該警告非常重要，因為只有在您進行真正的更改時才會發生。

對於大公司而言，最好的辦法是通過客戶投訴通知某人已以犯罪者的名義發布了真實的TLS / SSL證書。據我了解，固定機制是由Google提出的。

應用程序級固定

固定也可以在瀏覽器外部進行，方法是在應用中編譯真實的證書指紋。

我認為，對Web用戶進行MITM sslstrip攻擊時，保留瀏覽器客戶端的SSL證書只是HSTS的實現