[Problem] Curl error 60

Fridolin12

Neuer User
Mitglied seit
22 Jun 2020
Beiträge
7
Punkte für Reaktionen
0
Punkte
1
Hallo bin relativ ahnungslos was Programmieren angeht, aber ich frag halt mal:
vor einiger Zeit habe ich carddav2fb neu installiert wie in
von UsefulVid beschrieben.
Nach Installation finde ich allerdings keine Möglichkeit Curl von meinem Zertifikaten zu überzeugen.
Die Fehlermeldung lautet: In CurlFactory.php line 201
"Curl error 60: SSL certificate Problem: self signed certificate (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)"
Ich muss zugeben mit der Fehlermeldung komme ich auf keinen grünen Zweig
Probiert habe ich schon das Zertifikat aus der Fritzbox und mit Openssl
Zertifizierung mit x.pem und x.cert
Ich habe Eintragungen in der PHP.ini bzw config.php (carddav2fb) überprüft.
Jetzt, wenn mir jemand helfen kann?
 
Hallo,
lade dir mal die "CA certificates extracted from Mozilla" herunter: [ cacert-2020-01-01.pem ].
Und dann musst du curl die Option zur Verwendung dieser Zertifikat-Datei übergeben:
curl ... --cacert cacert-2020-01-01.pem ...

Wie das genau bei dir möglich ist, weiß ich nicht. Vielleicht gibt es auch einen Eintrag dafür in der php-Konfigurationsdatei. Ich habe einfach mal schnell gesucht und das [ hier ] gefunden, vielleicht hilft das weiter.

FischersFreetz
 
Zuletzt bearbeitet:
vielen Dank - das Mozilla Zert habe ich noch nicht ausprobiert. Ich mache mich mal dran. Nur das Wie ist so die Frage.
Übrigens da noch nicht hinterlegt: ich arbeite mit FileZilla und Putty auf einem Rasperry.
 
... bin relativ ahnungslos was Programmieren angeht...
... ich arbeite ... auf einem Rasperry ...
Wie geht das zusammen? Egal...


Zeig doch mal als Anhang die Dateien "php.ini" und "CurlFactory.php"
 
Zuletzt bearbeitet:
sodetle hier die zwei Dateien wobei die Curlfactory "home/pi/carddav2fb/vendor/guzzlehttp/guzzle/src/Handler" nochmals auf dem Pfad: "var/www/cloud/3rdparty/guzzlehttp/guzzle/src/Handler" und auf "var/www/cloud/3rdparty/guzzlehttp/rinphp/src/Client" zu finden ist.
 

Anhänge

  • phpini.pdf
    153.1 KB · Aufrufe: 5
  • CurlFactory.pdf
    85.1 KB · Aufrufe: 2
Ich würde mal folgendes versuchen:
  1. [ cacert-2020-01-01.pem ] herunterladen und in einem sinvollen Verzeichnis abspeichern.
  2. Suche in der " php.ini " den Eintrag "curl.cainfo=" (wahrscheinlich Zeile 1641) und gib dahinter den absoluten Pfad zur Datei "cacert-2020-01-01.pem" an:
Rich (BBCode):
...
[curl]
; A default value for the CURLOPT_CAINFO option. This is required to be an
; absolute path.
curl.cainfo="/absoluter/pfad/zur/cacert-2020-01-01.pem"
...
3. Den Prozess irgendwie neustarten und dabei Däumchen drücken...​
 
das rüberkopieren macht nicht automatisch ein Zertikat daraus, oder? Es bleibt eine x.txt Formatierung
Hab dann diese Seite gefunden: https://thomas-leister.de/ca-zertifikat-importieren-linux-windows/
das klappt auch, die Datei wird ein Zertifikat auch im richtigen Ordner aber mit Endung x.crt
ich hab irgendwann mal gelesen die x.crt gehören auch zur "PEM"
Hab dann den ganzen Pfad wie angeraten in die php.ini reingeschieben - Neustart des Raspberry, aber es geht nede :(
 
das rüberkopieren macht nicht automatisch ein Zertikat daraus, oder?
Lass die Datei mal so wie sie ist. curl kommt damit klar.
Bist du dir sicher, dass das Beschriebe deine Situation betrifft???
...das klappt auch, die Datei wird ein Zertifikat auch im richtigen Ordner aber mit Endung x.crt...
Was klappt auch? Hast du jetzt eine " x.cert " im Pfad angegeben? Wenn ja, probiere es mit der unveränderten " cacert-2020-01-01.pem ".
...aber es geht nede...
Das sagt nicht viel - konkrete Fehlermelungen wären vorteilhafter. Gibt es eine Fehlermedung? Ist es die gleiche?


Hast du auch die Däumchen gedrückt? ;)
 
Eintrag im php.ini:
curl.cainfo="/home/pi/cacert-2020-01-01.pem"

1592840722852.png

mit den Daumen bin ich immer unsicher ob der Rechte oder der L
inke wirksam ist :)
 

Anhänge

  • 1592837307270.png
    1592837307270.png
    10 KB · Aufrufe: 9
Zuletzt bearbeitet:
Ich habe einen vergleichbaren [ Beitrag ] gefunden.
Von wo werden die Infos den runtergeladen? Hat der Server eigene Zertifikate zur Authentifizierung?
Wie beginnt die url? Mit "https" ?

Dann probieren doch mal die url ohne das "s", also "http://..."
oder
weiter [ unten ] im Beitrag wird beschrieben, wie die Konfiguration angepasst werden müsste.

Deshalb drücke ich immer beide Daumen. Probier' das auch mal.
 
  • Like
Reaktionen: Fridolin12
Aha: beide Damen waren richtig: es geht die Adressen sind korrekt im Telefon - vielen lieben Dank
Ich nehme an für interne Nutzung ist die Zertifizierung unproblemmatisch diese zu entfernen?

Bevor man hier auf eine unverschlüsselte Übertragung (http ohne "s") "zurückfällt", würde ich empfehlen, die entsprechenden Optionen in config.php zu setzen.
Seit einigen commits kann man nämlich die Überprüfung der Zertifikate "ausschalten".
'verify' => false, // uncomment to disable certificate check
Genau für den Fall von selbstsignierten Zertifikaten, denen das dem Skript letztendlich zugrunde liegende cURL nicht vertraut.
Für den Zugriff auf den CardDav-Account mit:

Code:
'server' => [
[
'url' => 'https://...',
'user' => '',
'password' => '',
'http' => [ // http client options are directly passed to Guzzle http client
'verify' => false, // uncomment to disable certificate check
// 'auth' => 'digest', // uncomment for digest auth
]
],
 
Ich nehme an für interne Nutzung ist die Zertifizierung unproblemmatisch diese zu entfernen?
Was heißt denn interne Nutzung?
Aber ja, denn du "übergehst" sie ja bewußt, damit du die Daten bekommst.
Wenn du der Datenquelle bzw. dem Übertragungskanal nicht vertraust, ist das schon etwas anderes.
Aber wie wahrscheinlich / realistisch ist es, dass dir jemand auf diesem Weg gefälschte Kontaktdaten unterjubelt? Und welche Gefahr könnte sich daraus für Dich ergeben?
Wenn du darauf Antworten findest, könntest du ja noch weiter versuchen, curl mit dem Zertifikat des Servers vertraut zu machen. Dazu habe ich aber keine Idee.
 
Intern heisst doch einfach hinter dem Router ohne externen Zugriff - insofern eigene Hardware eben der Raspberyy dem man ja vertrauen sollte.
 
Na dann viel Spaß bei der Kontaktdatenpflege...
 
@Fridolin12

Deine Überlegungen sind richtig. Auf dem Pi brauchst für carddav2fb kein Zertifikat.

Empfehlung: wenn Du einen Beitrag eröffnest, dann hilft eine prägnante Überschrift:
"carddav2fb: Fehler mit Zertfikat" o.ä. ist auf alle Fälle besser als "Curl error 60" da weiß ja keiner worum es geht...
 
Hallo zusammen,

bei der Synchronisation von CardDav2FB erhalte ich beim Download der VCards folgende FM:

Code:
"Downloading vCard(s) from account Martin
    0 [>---------------------------]*   Trying 192.168.178.30:8008...
* TCP_NODELAY set
* Connected to 192.168.178.30 (192.168.178.30) port 8008 (#0)
> REPORT /addressbooks/users/Martin/addressbook/ HTTP/1.1
Host: 192.168.178.30:8008
Depth: 1
User-Agent: GuzzleHttp/6.5.5 curl/7.68.0 PHP/7.4.3
Authorization: Basic TWFydGluOjAxMkJsdW1lbg==
Content-Type: application/xml
Content-Length: 239

* upload completely sent off: 239 out of 239 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 400 Bad Request
< Server: Twisted/13.0.0 TwistedWeb/9.0.0
< Content-Length: 115
< Content-Type: text/html;charset=utf-8
< Date: Wed, 05 Aug 2020 14:27:09 GMT
< DAV: 1, access-control, addressbook, extended-mkcol, calendarserver-principal-property-search, calendarserver-principal-search, calendarserver-home-sync
< Connection: close
<
* Closing connection 0

In RequestException.php line 113:
                                                                                        
  Client error: `REPORT http://192.168.178.30:8008/addressbooks/users/Martin/addressboo 
  k/` resulted in a `400 Bad Request` response:                                         
  <html><head><title>Bad Request</title></head><body><h1>Bad Request</h1><p>CARDDAV:fil 
  ter required</p></body></html>"                                                        
                                                                                        
Ich nutze Ubuntu, 20.04.1 LTS, Firefox und ein Synology-NAS DS211j , DSM-Version 6.2.3-25426 Update 2, Carddav-Server 6.0.9.-0087.

Auszug aus der config.php:
    'server' => [
        [
            'url' => 'http://192.168.178.30:8008/addressbooks/users/Martin/addressbook/',
            'user' => '#username#',
            'password' => '#userpw#',
            'http' => [          
                 'verify' => false,
                 'debug' => true,
           //      'auth' => 'digest',
            ],
           //  'method' => 'PROPFIND',
        ],
    ],

Über Firefox komme ich mit der Server-URL + #username# + #userpw# auf die vcf-Seite rauf. Die Synchronisation der Kontakte zu Evolution bzw. über DAVx5 zu Android funktioniert auch einwandfrei.

Hat jemand eine Idee, warum CardDav2FB hier einen "400 Bad Request" zurück gibt?

Liebe Grüße
Martin
 
Hallo Martin,

ich kann so spontan aus der Fehlermeldung nichts herauslesen.
Bitte mach doch Bitte dazu auf GitHub ein Issue auf: kurze knackige Beschreibung (keine ellenlangen Fehlermeldungen); auf was für einem System läuft carddav2fb? was für einen CardDAV-Server sprichst du an?

Mit freundlichen Grüßen

Black Senator
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.