接收方如何處理簽名算法 ID 未知的 X.509 自證書？
據我所知，X.509 自證書是主機生成公鑰和私鑰的一種機制，公鑰將插入到證書中，私鑰將用於簽署證書。接收方將使用帶有證書的公鑰來驗證證書。
如果接收方沒有用於簽署證書的算法，接收方如何驗證證書？
X.509 是否有預設算法來簽署認證？
在最新的 X.509 RFC中，您可以閱讀：
signatureAlgorithm 欄位包含 CA 用於簽署此證書的加密算法的標識符。
$$ RFC3279 $$,$$ RFC4055 $$， 和$$ RFC4491 $$列出支持的簽名算法，但也可能支持其他簽名算法。
但是來自RFC 3279，第 2 節：
符合標準的 CA 和應用程序必須至少支持指定算法之一的數字簽名和公鑰。當使用本規範中確定的任何算法時，符合標準的 CA 和應用程序必須按照描述支持它們。
但更重要的是，在驗證證書鏈時，驗證證書鏈時無需執行驗證證書。需要事先信任此證書。
因此，如果您通過適當的“帶外”程序收到證書，您可以在那時驗證證書。之後，您只需要驗證動態值，例如證書的結束日期以及 - 可能 - 證書的狀態 - 是否已被撤銷。
這意味著對於容量有限的設備，您可以事先驗證和驗證證書，使用設備/儲存的受信任路徑將其放入設備中，然後“僅”檢查現場日期。
這可以在 X.509 RFC 的第 6.1 節中閱讀：
當以自簽名證書的形式提供信任錨時，該自簽名證書不包含在預期證書路徑中。有關信任錨的資訊作為證書路徑驗證算法的輸入提供（第 6.1.1 節）。
太好了，這樣就解決了問題，對吧？並不真地。證書的公鑰通常也用於加密或驗證應用程序中發送的簽名——這就是證書存在的原因。因此，現在您已經獲得了一個證書的受信任“鏈”，您被一個無法使用的公鑰困住了，因為它與對證書本身執行簽名驗證的公鑰相同。
當簽名驗證算法不可用時，接收者當然可以使用公鑰加密或執行密鑰協商。
此問題特定於自簽名證書，因為公鑰通常僅用於單一目的，而它必須至少簽名並可能執行另一種操作。
筆記：
- 協議可能會對支持哪些算法提出額外的要求，例如，儘管 TLS 沒有明確要求 RSA 簽名/加密，但如果沒有它，許多網站將無法執行。
- “證書”與“證書”具有不同的含義。後者意味著產品經過 FIPS 或通用標準認證。因此，“認證”通常用於更模擬的、紙質的意義上。
- “just” 放在引號內，因為在受限設備上從受信任的時間源獲取時間可能非常棘手。