技術 · 實用指南
curl 錯誤 60？使用 --insecure 前先稽核憑證鏈與信任庫
「unable to get local issuer certificate」不是單一修法。先記錄 TLS 後端、CAfile、CApath 與代理路徑，再修正伺服器鏈、客戶端信任輸入或檢查代理。
curl 錯誤 60 是驗證失敗，不是關閉驗證的指令。缺口可能在伺服器提供的鏈、curl 選用的信任輸入、應用程式專用憑證包或 TLS 檢查代理。
依序稽核端點、憑證鏈、後端、信任輸入與修復；證據決定要修伺服器、安裝已核驗的私有 CA、選用原生/檔案信任庫或修正代理信任。
凍結失敗端點與 curl 建置資訊
變更信任前記錄完整 URL、主機、連接埠、使用者環境、代理變數和錯誤。用 curl -V 記錄版本與 TLS 後端，再以 curl -v 保存 CAfile、CApath、連線目標及 CONNECT 代理。瀏覽器成功只證明瀏覽器找到可信鏈。
在真正失敗的 shell、容器或服務帳號重現。root、桌面使用者、PHP、Git 與 Composer 可能讀取不同設定。若 -k 成功，只能證明驗證是邊界；立即移除。
檢查端點實際提供的憑證鏈
針對準確主機與連接埠（含 SNI）檢查鏈，記錄葉憑證主體、頒發者與伺服器傳送的中繼憑證。公共站點漏送中繼憑證時應修復服務端鏈，不要把葉憑證當成根。
若安全設備終止 TLS，頒發者可能屬於組織。結合 curl -v、環境變數和頒發者證明路徑；curl 的 HTTPS 代理信任與來源站信任分開。
證明此 curl 建置使用哪個信任輸入
Schannel 通常使用 Windows 原生 CA 庫；許多其他後端使用檔案庫。檢查 CURL_CA_BUNDLE、SSL_CERT_FILE、SSL_CERT_DIR、應用設定與容器掛載，再考慮更換系統憑證包。
--cacert 僅指向已核驗的 PEM CA，--capath 必須正確準備；建置支援且策略要求時使用 --ca-native。Apple 平台可組合原生信任與自訂檔案。
套用最小且可驗證的修復
伺服器漏鏈就修服務端。確需私有或企業 CA 時，透過已驗證通道核對指紋與所有者，再於最小範圍信任。Ubuntu 以 .crt 加入指定目錄並執行 update-ca-certificates；Red Hat 使用 anchors 與 update-ca-trust。
只有一個應用失敗就修該應用的 CA 路徑；只有 HTTPS 代理失敗就用代理專用 CA 控制。頒發者意外時應停止並升級處理。
重測驗證、範圍與回復
不帶 -k 或臨時覆寫重測，確認主機名、頒發者、後端與 CA 來源，再測真實應用與乾淨環境。一次 --cacert 成功不保證其他執行環境讀取同一檔案。
記錄失敗證據、信任變更、CA 所有者、到期日和回復命令。服務端修復跨多個乾淨用戶端驗證；私有錨點也要驗證移除。
