macOS Monterey selbst erstelltem Zertifikat wird nicht vertraut

[SabineSW]

Wir haben einen nicht aus dem Internet erreichbaren Nextcloud-Server mit selbst erstelltem Zertifikat.

Beim Eintrag in den Systemeinstellungen für den CardDAV-Zugriff auf die Nextcloud sieht auch zunächst alles gut aus (Screenshot 1-4).
Aber es erscheinen in der Kontakte-App keine Kontakte (Screenshot 5).

 

[SabineSW]

In der Schlüsselbundverwaltung sehe ich aber, dass dem Zertifikat nicht vertraut wird (Screenshot 6). Auch wenn ich die Einstellung ändere und mit dem Passwort bestätige (Screenshot7), wird dem Zertifikat nicht vertraut, d.h. die Änderungen werden nicht durchgeführt (sieht danach wieder wie Screenshot 6 aus).

Ich vermute, dass an dem Zertifikat irgendwas nicht stimmt, aber kann ich ihm nicht trotzdem irgendwie vertrauen?

 

[SabineSW]

P.S.: Beim iPhone funktioniert der Zugriff.

 

[jvoss]

Was sagt denn Safari zu dem Server-Zertifikat wenn Du mit dem Safari auf den Nextcloud Server zugreifst?

Interessant wäre einmal ein Screenshot des Fensters wenn Du die Nextcloud-URL mit dem Safari aufruft und dann in der URL-Zeile auf das Schloss klickst und in Folge auf Zertifikat einblenden. Dort wird dann die sogenannte Certificate-Chain eingeblendet.

In dieser wird erkennbar wer Aussteller ist und wer ggf. als Zwischenzertifizierer dient, wie viele Stellen also insgesamt beteiligt sind am Zertifikat.

Vermutlich wird es bei Euch nur ein Zertifikat sein, eben Euer selbst erstelltes. Eben dieses Zertifikat ist dann eben das "Root" Certificate, welches natürlich auf den abrufenden Rechnern bekannt sein muss im lokalen Certificate-Store, da diesem Zertifikat-Aussteller ansonsten nicht vertraut wird.

Das ist auch in der Regel das Problem mit selbsterstellten Zertifikaten. Man muss sie selber an die abrufenden Benutzer verteilen und dort in den Certificate-Store (oder Truststore genannt) einbauen.

 

[lisanet]

Das mit selbstsignierten Zerts ist bei vielen Anleitungen im Netz zwischenzeitlich nicht mehr so ganz passend für die Anforderungen in iOS. Derartige Zerts dürfen z.Bsp. nur eine max. Gültigkeitsdauer von 825 Tagen haben und vorallem müssen die SAN-Extensions nutzen. Mehr dazu hier: https://support.apple.com/de-de/HT210176

Zudem musst du dann diese Zerts nicht nur in iOS importieren, sondern diese auch als Root-Zert akzeptieren.

Einfacher ist es da letztendlich wenn du dir mit der Schlüsselbund.app eine eingne Root CA erstellst und damit dann die benötigten Zerts erzeugst. So musst du nur das Root Zert auf die Geräte bringen und kannst soviele andere Zerts erstellen wie du möchstest. Zudem kannst du das Root Zert deutlich länger gültig schreiben, was die Verwaltung weiter vereinfacht.

Hier zwei Links dazu:

einmal zu den Anforderungen für iOS: -> https://blog.nashcom.de/nashcomblog...-ios-13-macos-10.15.htm?opendocument&comments

und einmal zur einer eigenen CA. Auch wenn das etwas veraltet aussieht, es ist weiterhin gültig und enthält unheimlich viele nützliche Infos. Mit dieser Anleitung habe ich meine eigene CA erstellt: -> https://siber-sonic.com/mac/MailSMIME/CA.html

 

[SabineSW]

@jvoss :
In einem normalen Fenster vom Safari komme ich gar nicht so weit (Screenshots 1 und 2), nur in einem privaten Fenster kann ich die Webseite öffnen.
Es ist, wie erwartet, nur ein Zertifikat (Screenshots 3 und 4).

Ich habe mir auch vom Debian-Server, der die Nextcloud betreibt, mit scp die entsprechende PEM-Datei geholt und mit "Objekte importieren" in die Schlüsselbundverwaltung geholt. Das Ergebnis ist aber das gleiche (siehe Post #2), dem Zertifikat wird nicht vertraut und das kann ich auch nicht ändern.

Das ist auch in der Regel das Problem mit selbsterstellten Zertifikaten. Man muss sie selber an die abrufenden Benutzer verteilen und dort in den Certificate-Store (oder Truststore genannt) einbauen.

Welche Datei muß ich mir besorgen und wie und wo muß ich die einbauen? Hast Du evtl. einen Link für mich?

 

[SabineSW]

@lisanet :
Danke für Deine Links. Das muß ich jetzt erst in Ruhe studieren, ich bin aber etwas verwirrt:

• Du sprichst von iOS, es geht aber um MacOS.
• Ich weiß auch nicht, ob ich meinen Mann überzeigen kann, dass ich jetzt für seine Linux-Server Zertifikate erstelle.
• Im letzten Link geht es um S/MIME secure email certificates, ich brauche aber Zertifikate für einen Apache-Server unter Linux.

 

[lisanet]

@lisanet :
Danke für Deine Links. Das muß ich jetzt erst in Ruhe studieren, ich bin aber etwas verwirrt:

• Du sprichst von iOS, es geht aber um MacOS.
• Ich weiß auch nicht, ob ich meinen Mann überzeigen kann, dass ich jetzt für seine Linux-Server Zertifikate erstelle.
• Im letzten Link geht es um S/MIME secure email certificates, ich brauche aber Zertifikate für einen Apache-Server unter Linux.

iOS hbe ich erwähnt, weil wenn du die als Clients verwendest, die besonders "picky" sind, was Zerts betrifft. Du greifst ja auch mit einem iPhone zu. Die erstellten Zerts kannst du aber natürlich auch exakt genauso auf macOS importieren oder auf jeden anderen Client mit jedem anderen Betriebssystem.

Wenn ihr eh schon mehr als einen Server habt der Zerts verwendet, ist eine eigene CA erst recht von Vorteil

Da wird halt zustätzlich zur Erstellung einer eigenen CA auch noch das Besipiel gebracht wie man dann mit dieser CA ein Zert für S/MIME "herausgibt". Du kannst natürlich auch ebenso dann mit deiner CA Zerts für SSL-Verschlüsselungen herausgeben. Wenn du das Tutorial durch hast, dann kommst du eh an der Stelle vorbei, wo du zwischen S/MIME und ServerZert entscheiden musst. Ja ich weiß, das ist viel input, aber wenn man das mal durchmacht, ist es eigentlich einfacher als man denkt. Der Zertifikatsassistent in der Schlüsselbundverwaltung ist da schon recht brauchbar und gut gestaltet. Ich finde den Weg über die Schlüsselbund.app jedenfalls deutlich einfacher, als das via Terminal mit openssl zu machen.

 

[jvoss]

Hallo Sabine,

im Prinzip hat es Lisanet schon beschrieben wie es von Anfang an gemacht wird, bzw. den Link geliefert.

Grundlegend wäre es vernünftig wenn Ihr Euch eine CA (Certificate Authority) für Eure Domain aufbaut, wie Lisanet auch schon erwähnte.
Ich vermute, dass das Server Zertifikat Eures Apache Servers entweder defekt ist oder der Verwendungszweck des Zertifikates nicht passt, oder eben das neue Zertifikat noch nicht in den Trust-Store importiert ist.

Leider sind die Zwecke des Zertifikates bei Deinem letzten Screenshot ausgeblendet, da könnte man es vermutlich erkennen. Das vorhandene Zertifikat wurde vermutlich mit openSSL auf dem Debian Server erzeugt oder? Und das Originalzertifikat müsste somit (theoretisch) direkt im Configverzeichnis des Apache irgendwo abgelegt sein.

Ehrlich gestanden verwirrt mich das mit dem Schlüsselbund im Moment auch noch ein wenig. Ich komme da eher aus der Windowswelt was die Verwaltung von Zertifikaten angeht. Aber grundsätzlich sollte das mehr oder weniger identisch sein. Sind wohl nur andere Begrifflichkeiten.

 

[SabineSW]

So, einen Schritt bin ich jetzt weiter: Ich habe eine CA angelegt und damit schon einmal 2 Serverzertifikate erstellt.

Was mich noch nicht klar ist, ob diese den Anforderung von Apple (laut https://support.apple.com/de-de/HT210176) genügen:

1. Ich konnte nirgends etwas mit SHA-2 auswählen.
2. Was ist mit dem "id-kp-serverAuth OID" gemeint?

Passen die Zertifikate Eurer Meinung nach (siehe Screenshots)?

 

[lisanet]

... sieht gut aus. Du hast das doch über die Schlüsselbundverwaltung gemacht, dann kannst du da recht wenig falsch machen.
Die "extended key usage" ist die "erweiterte Schlüsselverwendung" und SHA256 gehört zur geforderten SHA2-family.

Aber warum hast du die CA nur bis 2024 ausgestellt? Die CA kannst du duchaus 10 Jahre austellen. Die Dauer von 825 Tagen betrifft nicht das Cert der CA, sondern die von der CA herausgegebenen Server-Zerts, also deines für das wiki. So musst du nun in 2024 sowohl das Server-Zert als auch das der CA erneuern, was ja genau nicht Sinn und Zwekc des Ganzen sein sollte. Stelle die CA auf 10 Jahre aus. Wenn du dann das Zert der CA auf die Clients bringst, hast du dort für die nächsten 10 Jahre Ruhe und musst nur nach 825 Tagen die Zerts auf dem Server erneueren und kannst die Clients unangetastet lassen.

Noch was:
Du musst jetzt aber auch dafür sorgen, dass der Server über https://wiki.intern.lan aufgerufen werden kann (und muss). Persönlich hätte ich da nicht noch erst eine subdomain dazwischen geschaltet, mir hätte wiki.lan gereicht. Aber das ist Geschmackssache.

 

[SabineSW]

Aber warum hast du die CA nur bis 2024 ausgestellt? Die CA kannst du duchaus 10 Jahre austellen.

Das war mir nicht klar, dass sich das nicht auf die CA bezog. Dann lösche ich sie halt nochmal und fange von vorne an.

Wenn du dann das Zert der CA auf die Clients bringst, ...

Da ist das nächste, auzuknobeln, was ich wie wohin bei den verschiedenen Betriebssystemen bringe. Ich habe schon gesehen, dass beim Export p12-Dateien erzeugt werden, weiß aber noch nicht, was genau in welchem Format drin ist. Wenn ich das richtig verstanden habe, brauche ich bei den Servern sowohl den privaten als auch den öffentlichen Schlüssel des jeweiligen Servers (bisher stehen die unter /etc/ssl/local) und bei allen den öffentlichen Schlüssel der CA.

Du musst jetzt aber auch dafür sorgen, dass der Server über https://wiki.intern.lan aufgerufen werden kann (und muss).

Das ist schon seit Jahren so, dass man bei den Domains über die verschiedenen Namen auf den entsprechenden Seiten landet.

 

[mj]

Das mit selbstsignierten Zerts ist bei vielen Anleitungen im Netz zwischenzeitlich nicht mehr so ganz passend für die Anforderungen in iOS. Derartige Zerts dürfen z.Bsp. nur eine max. Gültigkeitsdauer von 825 Tagen haben und vorallem müssen die SAN-Extensions nutzen. Mehr dazu hier: https://support.apple.com/de-de/HT210176

Das Dokument hat mich zugegebenermaßen überrascht, denn nur drei Tage nachdem es veröffentilcht wurde hat Apple am 03.03.2020 angekündigt, die Gültigkeit für ab dem 01.09.2020 ausgestellte Zertifikate auf nurmehr 398 Tage zu verkürzen: https://support.apple.com/en-us/HT211025. Entweder, hier ist von zwei verschiedenen Zertifikaten mit verschiedenen Limits die Rede oder Apple hat vergessen das Dokument anzupassen. Früher waren es nämlich tatsächlich mal 825 Tage.

 

[SabineSW]

Das Dokument hat mich zugegebenermaßen überrascht, denn nur drei Tage nachdem es veröffentilcht wurde hat Apple am 03.03.2020 angekündigt, die Gültigkeit für ab dem 01.09.2020 ausgestellte Zertifikate auf nurmehr 398 Tage zu verkürzen: https://support.apple.com/en-us/HT211025. Entweder, hier ist von zwei verschiedenen Zertifikaten mit verschiedenen Limits die Rede oder Apple hat vergessen das Dokument anzupassen. Früher waren es nämlich tatsächlich mal 825 Tage.

Ganz unten steht auch drin, dass das nicht selbsterstellte CAs betrifft, um die es hier geht.

 

[mj]

Hmm... interessant. Ich kann das nicht bestätigen. Ich verwalte eine firmeninterne Corporate CA die auf allen unseren Systemen hinzugefügt wird und Safari meckert grundsätzlich bei jedem Zertifikat älter als 398 Tage (sofern es nach dem 01.09.2020 ausgestellt wurde). Ebenso wie alle Chromium-basierten Browser (Chromium, Chrome, Edge) und Firefox.

Sehr komisch das ganze.

 

[lisanet]

Das Dokument hat mich zugegebenermaßen überrascht, denn nur drei Tage nachdem es veröffentilcht wurde hat Apple am 03.03.2020 angekündigt, die Gültigkeit für ab dem 01.09.2020 ausgestellte Zertifikate auf nurmehr 398 Tage zu verkürzen: https://support.apple.com/en-us/HT211025. Entweder, hier ist von zwei verschiedenen Zertifikaten mit verschiedenen Limits die Rede oder Apple hat vergessen das Dokument anzupassen. Früher waren es nämlich tatsächlich mal 825 Tage.

Dieses Dokument kannte ich bislang nicht. Ich verstehe es aber auch so, dass es nicht für selbst installierte Zerts gilt, sondern nur für diejenigen, die von den von Apple vorinstallierten CA herausgegeben werden.

Ich habe auch gerade nochmals meinen VS-Code-Server aufgerufen. Der hat ein Zert das ich erst am 14.01. erneut erzeugt habe und bis April 2024 gültig ist, also eben definitv länger als die 398 Tage. Sowohl Safari auf macOS als auch auf iPadOS haben damit keinerlei Probleme.

 

[mj]

Danke. Ich werde das auch nochmal testen, irgendwie hatte ich genau damit nämlich Probleme.