iCloud Kalender Fehlermeldung

[magiczambo]

Hiho,

habe über die Suche nichts gefunden, bzw. nur "uraltes" Zeugs.

Ich bekomme in der SV2.9 folgende Fehlermeldung:

Read request to "https://caldav.icloud.com/" failed with message "HTTP/1.1 403 Forbidden"

Wenn ich die URL manuell im Browser aufrufe kann ich Sie aufrufen und mich mit dem anwendungsspezifischen PW anmelden ohne Fehlermeldung.

Gibt es hierzu Erfahrungen?

[Bonze]

Kenne jetzt die abfrageart nicht. Da ich selbst letztens so ein problem hatte, kanns sein, das die beim request nen anderen header wollen ?

Wann kam der Fehler denn? Und wie oft?

[wvhn]

Dein Browser hat sicherlich aktuelle Zertifikate. Trifft das auf den Apache- oder nginx-Webserver auch zu? Ich vermute, die https-Verbindung kommt nicht zustande. Jedenfalls war das bei mir so.

Gruß
Wolfram

[magiczambo]

Dein Browser hat sicherlich aktuelle Zertifikate. Trifft das auf den Apache- oder nginx-Webserver auch zu? Ich vermute, die https-Verbindung kommt nicht zustande. Jedenfalls war das bei mir so.

Ok das klingt vielversprechend. Hast du mir einen Ansatz wie du das explizit gelöst hast?

[wvhn]

Schau mal hier:
https://knx-user-forum.de/forum/supp...24#post1526024
Gilt für den Apache-Server.

[magiczambo]

Hat leider nichts geholfen.

Hat jemand mit SV 2.9 iCloud Kalender am laufen?

[Msinn]

1.7.1??? Die smartVISU ist seit Jahren auf Version 2.x.

Meinst Du 2.7, 2.8, 2.9 oder 2.9.2?

[wvhn]

magiczambo Das ist unabhängig von der shNG-Version. Oder meinst Du die Image-Version?
Entscheidend ist, welchen Webserver Dein Raspberry verwendet. Dem bzw. dem zugehörigen PHP musst Du halt mitteilen, wo die Zertifikate liegen. Und aktuell müssen sie natürlich auch sein.

[magiczambo]

1.7.1??? Die smartVISU ist seit Jahren auf Version 2.x.

Meinst Du 2.7, 2.8, 2.9 oder 2.9.2?

Ah sry. SmartVisu ist 2.9 habe Onkel Andys Image 1.7.1

[magiczambo]

magiczambo Das ist unabhängig von der shNG-Version. Oder meinst Du die Image-Version?
Entscheidend ist, welchen Webserver Dein Raspberry verwendet. Dem bzw. dem zugehörigen PHP musst Du halt mitteilen, wo die Zertifikate liegen. Und aktuell müssen sie natürlich auch sein.

Naja ich konnte bisher nich nachvollziehen, dass es tatsächlich am Zertifikat liegt. Deswegen meine Frage ob jemand den iCloud Kalender am laufen hat. Mit dem Image 1.7.1 also SHNG 1.7.1 und SV 2.9, webserver ist nginx

[Msinn]

magiczambo SHNG hat damit nichts zu tun. Der Kalender ist ein reines Visu Thema und wie wvhn schrieb abhängig davon welchen Webserver Du nutzt.

Deine Frage ob jemand das am laufen hat, beantwortet Dir eine Suche hier im Forum. Wenn ich nach den Begriffen ical und icloud suche, bekomme ich diverses angezeigt. Ich weiss allerdings nicht ob Beiträge aus dem September 2020 bei Dir als "uraltes" Zeugs zählen..

[magiczambo]

Ich weiß zwar ned wieso da jetzt so ne Schärfe reingebracht wird? Aber meine Frage war dahin gehend wer den iCloud Kalender auch mit dem 1.7.1 Image am laufen hat.

[Msinn]

Aber meine Frage war dahin gehend wer den iCloud Kalender auch mit dem 1.7.1 Image am laufen hat.

Die Frage hattest Du halt ursprünglich nicht so gestellt. Du fragst immer wieder nach shng bzw. dem Image. Was wichtige ist aber wie Du die installierte Software konfigurierst. Deshalb die Klarstellung. So wie Du die Frage gestellt hast, überlesen vielleicht Anwender Diene Frage, weil sie kein shng oder nicht das Image nutzen.

Mit dem Image kann man übrigens entweder Apache oder Nginx nutzen. Aber das hat nichts mit dem Image zu tun, sondern welche Teile der installierten Software Du nutzt und wie Du diese installierte Software (in diesem Fall den Webserver) konfigurierst und ob Du, wie wvhn schon anmerkte, entsprechend aktuelle Zertifikate installiert hast.

[magiczambo]

Sorry aber ich kann deine Post einfach nicht nachvollziehen. Ich habe von dem Image erst geredet nach meinem Typo in der SV Version. Entweder du versuchst etwas konstruktives bei zu tragen oder lass es sein. Fühle dich nicht verpflichtet dich hier zu beteiligen.

ich habe meine Konstellation angegeben.

SV 2.9 Webserver nginx (zusätzlich habe ich noch erwähnt das ich das 1.7.1 Image verwend) und ich habe jemand gesucht der das so am laufen hat. Ich gehe davon aus du hast das so nicht am laufen?!

[magiczambo]

Um das hier mal nochmals ein bißchen weiter voran zu bekommen.

Also ich gehe jetzt mal schwer davon aus, dass ich kein Problem mit den SSL Zertifikaten habe, denn ein

openssl s_client -connect caldav.icloud.com:443

ergibt:

CONNECTED(00000003)
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
verify return:1
depth=1 CN = Apple IST CA 2 - G1, OU = Certification Authority, O = Apple Inc., C = US
verify return:1
depth=0 CN = caldav.icloud.com, O = Apple Inc., ST = California, C = US
verify return:1
---
Certificate chain
0 s:CN = caldav.icloud.com, O = Apple Inc., ST = California, C = US
i:CN = Apple IST CA 2 - G1, OU = Certification Authority, O = Apple Inc., C = US
1 s:CN = Apple IST CA 2 - G1, OU = Certification Authority, O = Apple Inc., C = US
i:C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
2 s:CN = Apple IST CA 2 - G1, OU = Certification Authority, O = Apple Inc., C = US
i:C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
---
Server certificate
-----BEGIN CERTIFICATE-----

Inhalt entfernt!!!!

-----END CERTIFICATE-----
subject=CN = caldav.icloud.com, O = Apple Inc., ST = California, C = US

issuer=CN = Apple IST CA 2 - G1, OU = Certification Authority, O = Apple Inc., C = US

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 6391 bytes and written 402 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-ECDSA-AES256-GCM-SHA384
Session-ID: 87721A923C2482752A95C5DB24FE004A052B5B53AECF78464D 33BFFF5C26327B
Session-ID-ctx:
Master-Key: 271EF01EB62165DFB6F2FABC6D717B24FAF5F438BB10B97D78 B7F2D18D75ACE59912391EE5A4DB8B8CBE30F45C2311CC
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 600 (seconds)
TLS session ticket:
0000 - 23 e5 e7 c6 26 9b 33 6b-06 11 42 af 5a 16 19 ae #...&.3k..B.Z...
0010 - 9f 2f be d0 60 e1 8e ff-db 67 b2 17 b7 55 2c 42 ./..`....g...U,B
0020 - 1c f3 0f c6 bd a8 2f 7c-62 2d f1 39 5c 18 70 3a ....../|b-.9\.p:
0030 - a7 d4 60 f8 88 10 03 41-56 41 f4 bb b9 19 d2 9b ..`....AVA......
0040 - 56 20 6c 87 81 95 d5 df-a5 2d a0 4b cf 60 86 c5 V l......-.K.`..
0050 - 92 34 7d 53 f7 ca 2f d0-d9 d0 36 12 74 71 e5 b3 .4}S../...6.tq..
0060 - b2 91 1f 20 44 f4 5e 8a-99 de a8 56 8a 13 8b 8d ... D.^....V....
0070 - ec 43 70 1f e9 f0 a3 dc-51 12 e1 a2 88 4e c2 97 .Cp.....Q....N..
0080 - 25 c2 ec 46 fd c9 66 12-fd c5 a0 a8 7a ed f0 5d %..F..f.....z..]
0090 - cf f5 68 4f 65 01 2b 35-5d 55 5e 8e de bb 62 f1 ..hOe.+5]U^...b.
00a0 - 0c a5 6c e7 7b 7c 66 ef-c3 e0 b8 cc 7b 41 5a a7 ..l.{|f.....{AZ.
00b0 - c9 7b da 6a a7 69 40 24-7b 0c 08 d9 9c eb 12 50 .{.j.i@${......P
00c0 - f4 f5 75 88 78 28 03 97-d0 22 5b 0e 91 16 9e c8 ..u.x(..."[.....

Start Time: 1611096403
Timeout : 7200 (sec)
[MARKIEREN]Verify return code: 0 (ok)[/MARKIEREN]
Extended master secret: yes
---
closed

Hinter der Fehlermeldung

HTTP/1.1 403 Forbidden

hätte ich jetzt auch kein Zertifikatsfehler vermutet.

Was mich wundert ist, dass ich im nginx log keine Einträge hierzu finde. Jemand noch einen Ansatzpunkt?