Jak naprawić curl: (60) certyfikat SSL: nieprawidłowy łańcuch certyfikatów podczas korzystania z sudo

Odkąd curl aktualizacji Mavericks ma więcej problemów z certyfikatami.

Podczas próby zwinięcia pliku z mojego serwera internetowego za pomocą certyfikatu z podpisem własnym pojawia się błąd „Certyfikat SSL: nieprawidłowy łańcuch certyfikatów”.

Zostało to poprawione poprzez dodanie certyfikatu do mojego pęku kluczy systemu i ustawienie go tak, aby zawsze zezwalał na SSL, informacje, które znalazłem tu i tutaj .

Działa to dobrze, a kiedy zwijam plik, jest on pobierany poprawnie.

Jeśli jednak wcześniej uruchamiam curl za pomocą sudo (np. Mam skrypt, który należy uruchomić za pomocą sudo i robi w nim curl), wrócę do tego samego komunikatu o błędzie.

Zgaduję, że root nie może odczytać z systemowego pęku kluczy?

Czy ktoś wie, jak to naprawić?

Jeśli przechowujesz swoje certyfikaty CA w systemie plików (w formacie PEM), możesz powiedzieć curl, aby ich używał

sudo curl --cacert /path/to/cacert.pem ...

Możesz także wyłączyć weryfikację certyfikatu za pomocą

sudo curl --insecure ...

Edycja: Zaktualizowano w odniesieniu do opinii

Jeśli chcesz ustawić to na stałe, powinieneś utworzyć .curlrcpliki i umieścić je w swoim katalogu domowym. sudopolecenia mogą wymagać tego pliku w /var/rootpliku Plik ma te same opcje co wiersz poleceń, ale bez myślników. Jedna opcja na linię:

cacert=/path/to/my/certs.pem

Root nie odczytuje z bieżących ustawień zaufania użytkownika, ale istnieją zarówno ustawienia zaufania administratora, jak i ustawienia zaufania specyficzne dla użytkownika root. (Są one również różne od ustawień zaufania systemu .) Należy również pamiętać, że ustawienia zaufania certyfikatów różnią się nieco od dodania certyfikatu do pęku kluczy; możesz oznaczyć certyfikat jako zaufany bez pełnego dodawania. (Dokładna sytuacja tutaj nie jest dla mnie jasna, a dokumenty, które widziałem, są niejasne.)

Możesz oznaczyć certyfikat jako zaufany dla bieżącego użytkownika jako

$ security add-trusted-cert /path/to/cert.pem

ale to nie pomaga w rootowaniu. Rozwiązanie, jak można się teraz domyślać, odnosi się do sudopowyższego, co oznacza, że ​​jest to szczególnie zaufane dla użytkownika root:

$ sudo security add-trusted-cert /path/to/cert.pem

lub użyć -dflagi, aby dodać ją do ustawień zaufania administratora:

$ security add-trusted-cert -d /path/to/cert.pem

(OS X wyświetli okno dialogowe hasła, aby je potwierdzić).

Każdy z dwóch ostatnich wydaje się wystarczający sudo curl.

Odniesienie: https://developer.apple.com/library/mac/Documentation/Darwin/Reference/ManPages/man1/security.1.html

To jest tak naprawdę w podpowiedzi wyjściowej:

echo insecure >> ~/.curlrc

Zaletą zastosowania powyższego rozwiązania jest to, że działa ono dla wszystkich curlpoleceń, ale nie jest zalecane, ponieważ może wprowadzać ataki MITM , łącząc się z niepewnymi i niezaufanymi hostami.

Jeśli używasz MacPorts (a wspomniany skrypt innej firmy nie usuwa go $PATHani nie wywołuje /usr/bin/curl), możesz zainstalować porty certsynci curlw tej kolejności.

certsyncjest narzędziem i odpowiednią listą uruchomieniową, która wyeksportuje breloczek do systemu $prefix/etc/openssl/cert.pemi zainstaluje dowiązanie symboliczne, $prefix/share/curl/curl-ca-bundle.crt -> $prefix/etc/openssl/cert.pemdzięki czemu curl MacPorts automatycznie odbierze certyfikaty. certsyncautomatycznie zaktualizuje również wygenerowane pliki po zmianie pęku kluczy systemu.

Dokumentacja, której szukasz, znajduje się tutaj. Wyjaśnia, jak używać cURL na Mavericks i jak dostarczać certyfikaty: http://curl.haxx.se/mail/archive-2013-10/0036.html

Aby sudo curldziałać (w OSX Sierra), musieliśmy zaimportować certyfikat do System.keychaini tam zaufać. Można to zrobić ręcznie w aplikacji pęku kluczy lub za pomocą tego polecenia:

sudo security add-trusted-cert -d -k /Library/Keychains/System.keychain /path/to/cert.pem

Ważne było zarówno określenie, jak -di ręczne ustawienie ścieżki do pęku kluczy Systemu, -kaby upewnić się, że certyfikat rzeczywiście zostanie tam zaimportowany, jeśli jeszcze tego nie zrobił.

Polecenie działa bez sudo, ale następnie poprosi o hasło w oknie dialogowym interfejsu użytkownika, co może być przeszkodą dla skryptów.