123788
15.08.2016
3306
3
0
SSL-Zertifikat: IP statt FQDN
Hallo,
ich betreibe hier auf einer statischen IP eine Nextcloud-Installation.
Diese soll nur über https erreichbar sein. Leider befindet sich auf dessen Standard-Port bereits ein (physikalisch anderer, in anderer DMZ befindlicher) HTTPS-Server, welcher auch über einen FQDN erreichbar ist.
Daher möchte ich einen anderen Port nutzen, z.B. 9101.
Es ist leider aufgrund mancher Clients nötig, die Cloud per externer IP anzusteuern. Dies stellt aber kein Problem dar, sämtliche Clients werden einmal händisch von mir konfiguriert und werden die nächsten Jahre nicht angefasst.
Mein Problem ist nun: Ich habe ein SSL-Zertifikat erstellt. Dessen CN ist die externe IP meiner Firewall.
Nun lässt sich die Cloud in allen möglichen Browsern und CalDAV-Programmen problemlos nutzen. Natürlich erscheint kurz eine Abfrage, ob man das selbst signierte Zertifikat als sicher ansehen wolle.
Funktioniert alles problemlos... AUßER bei Apple-CalDav-Clients. Diese lehnen das Zertifikat ab. Ich werde das Gefühl nicht los, dass es am CN liegt.
Leider finde ich im Netz keine Anleitung, wie man eine IP als CN eines Zertifikats nutzen kann.
Ich habe alles mögliche probiert, aber nichts funktioniert... es bleibt immer bei den Apple-Clients hängen...
Habt ihr eine Idee?
ich betreibe hier auf einer statischen IP eine Nextcloud-Installation.
Diese soll nur über https erreichbar sein. Leider befindet sich auf dessen Standard-Port bereits ein (physikalisch anderer, in anderer DMZ befindlicher) HTTPS-Server, welcher auch über einen FQDN erreichbar ist.
Daher möchte ich einen anderen Port nutzen, z.B. 9101.
Es ist leider aufgrund mancher Clients nötig, die Cloud per externer IP anzusteuern. Dies stellt aber kein Problem dar, sämtliche Clients werden einmal händisch von mir konfiguriert und werden die nächsten Jahre nicht angefasst.
Mein Problem ist nun: Ich habe ein SSL-Zertifikat erstellt. Dessen CN ist die externe IP meiner Firewall.
Nun lässt sich die Cloud in allen möglichen Browsern und CalDAV-Programmen problemlos nutzen. Natürlich erscheint kurz eine Abfrage, ob man das selbst signierte Zertifikat als sicher ansehen wolle.
Funktioniert alles problemlos... AUßER bei Apple-CalDav-Clients. Diese lehnen das Zertifikat ab. Ich werde das Gefühl nicht los, dass es am CN liegt.
Leider finde ich im Netz keine Anleitung, wie man eine IP als CN eines Zertifikats nutzen kann.
Ich habe alles mögliche probiert, aber nichts funktioniert... es bleibt immer bei den Apple-Clients hängen...
Habt ihr eine Idee?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 312704
Url: https://administrator.de/forum/ssl-zertifikat-ip-statt-fqdn-312704.html
Ausgedruckt am: 22.04.2025 um 10:04 Uhr
3 Kommentare
Neuester Kommentar
Hallo,
Du wirst keinen Anbieter finden der Dir öffentzliche IP-Zertifikate ausstellt.
Auch .localhost gibt es ja nicht mehr.
Du könntest probieren eine eigene Root-CA zu erstellen und diese in den Apple-Clients zu installieren.
Dann wären alle davon erstellen Zertifikate gültig.
Stefan
Du wirst keinen Anbieter finden der Dir öffentzliche IP-Zertifikate ausstellt.
Auch .localhost gibt es ja nicht mehr.
Du könntest probieren eine eigene Root-CA zu erstellen und diese in den Apple-Clients zu installieren.
Dann wären alle davon erstellen Zertifikate gültig.
Stefan
Zitat von @StefanKittel:
Du wirst keinen Anbieter finden der Dir öffentzliche IP-Zertifikate ausstellt.
Die gibt es schon, die lassen sich das aber fürstlich bezahlen: https://www.telesec.de/de/serverpass/produkte/serverpass-standardDu wirst keinen Anbieter finden der Dir öffentzliche IP-Zertifikate ausstellt.
Wäre es nicht unterm Strich einfacher, wenn da einfach eine Subdomain für den Cloud-Dienst erstellt und ein Zertifikat für eben genau diesen Hostname ausgestellt wird?
Schon alleine, falls das Cloud-System mal umziehen muss und dann eine neue IP bekommt...
Ihr habt recht mit euren Kommentaren, ich finde die Situation auch nicht optimal.
Wir haben herausgefunden: Die Kalender-App in der aktuellen OS X-Version hat offenbar einen Bug.
Auf den iPhones läuft es nun auf wundersame Weise, auf allen anderen Geräten ging es ja ohnehin von Anfang an.
Die Option der Subdomain werde ich tatsächlich auch noch einmal in Betracht ziehen.
Danke euch erstmal!
Wir haben herausgefunden: Die Kalender-App in der aktuellen OS X-Version hat offenbar einen Bug.
Auf den iPhones läuft es nun auf wundersame Weise, auf allen anderen Geräten ging es ja ohnehin von Anfang an.
Die Option der Subdomain werde ich tatsächlich auch noch einmal in Betracht ziehen.
Danke euch erstmal!
