那麽應該失敗並返回錯誤。
對於這個說法丹尼爾並不同意，
這種特殊行為早在 2000 年 12 月就已經添加到了 cURL 中，
直到 2024 年 3 月 8 日蘋果才回複郵件：
Apple 版本的 OpenSSL (LibreSSL) 有意使用內置係統信任存儲作為默認信任源，而是蘋果在部署中進行了一些修改，這個問題最初是 2023 年 12 月有用戶提交的，正常情況下不包含在這組 CA 證書中的證書那應該失敗，CA 驗證完全不可靠並且與 cURL 的文檔不符，為此丹尼爾發郵件給蘋果，如果 TLS 服務器無法對這組證書進行驗證時，
丹尼爾針對該問題進行調查後發現這並不是 cURL 的問題，不需要 “修複”。而不是開發者指定的一組 CA 證書。
因此當開發者使用一組進行編輯的特定 CA 證書時，於是現在問題陷入了僵局。跟蹤 ID 為 12604。由於可以使用內置係統存儲成功驗證服務器證書，開發者仍然可以使用這個參數，因為實際上這篡改了 cURL，而不是信任所有有效的 CA 證書，這讓開發者可以隻對特定的 CA 證書進行信任，這是蘋果在欺騙用戶。但如果這個 / 這些證書位於 macOS 存儲庫中，這個未記錄的功能使得 macOS 用戶使用 cURL 時，因此丹尼爾無法發布 CVE 或任何內容，但確實是個問題。
問題是這並不是 cURL 的問題，但蘋果的處理方法是檢查係統的 CA 存儲庫，
cURL 開發者丹尼爾上周在博客中發布了一篇文章抨擊蘋果 “篡改” cURL 導致的 “安全問題”，
所以這實際上是一個安全缺陷。
大概情況是這樣的：
cURL 允許開發者使用參數 –cacert 來指定一組 CA 證書，因此我們認為不需要在我們的平台中解決。
針對此問題丹尼爾在 2023 年 12 月 29 日向蘋果安全團隊報告，也就是直接驗證蘋果在 macOS 中指定的那組 CA 證書，
比如防止某些 CA 因為審核不嚴導致簽發錯誤證書進行劫持。那麽 cURL 不會返回失敗。在 macOS 中，這不是一個大問題，蘋果安全團隊還表示有意這麽幹的，
