11
Selbstsignierte Zertifikate unter iOS 15 nutzen
Hallo liebe community,
Ich habe mir ein Heimnetzwerk aufgebaut inklusive einiger Server und habe mir ebenfalls Zertifikate mithilfe der opnsense erstellt.
Soweit funktioniert das ganze auch gut, die Zertifikate kann ich auf Desktop Rechner und teilweise auch auf iOS benutzen, da die Sicherheitsabfrage übersprungen werden kann und dennoch eine SSL Verbindung genutzt werden kann.
Als Beispiel kann hier die Nextcloud iOS App genannt werden, hier bekomme ich zwar eine Warnung dass das Zertifikat nicht valide ist, aber ich kann dennoch vertrauen, sodass mein Ziel SSL zu nutzen erreicht ist.
Was bisher nicht geht ist zum Beispiel die App Bitwarden oder auch Nextcloud Deck. Hier wird mir als User keine Möglichkeit gegeben dem Zertifikat Manuel zu vertrauen, die Apps werden somit unbrauchbar.
Ich habe bisher noch keinen Weg gefunden wie ich iOS 15 dazu bringen kann selbst signierte der Zertifikate zu akzeptieren. Über den Apple Configurator Manager kann ich es nicht machen, da mein iPhone bereits über ein anderes MDM verwaltet (nicht unter meiner Kontrolle oder Einfluss ) wird und zusätzlich habe ich auch kein Account für den Konfigurator Manager.
Gibt es eine Möglichkeit mit der ich mir zum Beispiel mittels open SSL mit erforderlichen Parametern ein Zertifikat erstellen kann welches von iOS akzeptiert wird? Oder gibt es eventuell noch andere Wege selbst signiert Zertifikate zu akzeptieren?
Die bekannten Wege mit Zertifikate inklusive CA und Intermediate CA per Mail zu empfangen, auf dem Gerät zu installieren und Manuel zu trusten habe ich bereits ausgeführt. Das Ergebnis ist oben beschrieben. iOS akzeptiert das Zertifikat nicht ich bekomme auch weiterhin eine Zertifikats Meldung im Safari oder Brave, was ich ebenfalls gerne abstellen möchte.
Vielen Dank für euer Feedback!
Ich habe mir ein Heimnetzwerk aufgebaut inklusive einiger Server und habe mir ebenfalls Zertifikate mithilfe der opnsense erstellt.
Soweit funktioniert das ganze auch gut, die Zertifikate kann ich auf Desktop Rechner und teilweise auch auf iOS benutzen, da die Sicherheitsabfrage übersprungen werden kann und dennoch eine SSL Verbindung genutzt werden kann.
Als Beispiel kann hier die Nextcloud iOS App genannt werden, hier bekomme ich zwar eine Warnung dass das Zertifikat nicht valide ist, aber ich kann dennoch vertrauen, sodass mein Ziel SSL zu nutzen erreicht ist.
Was bisher nicht geht ist zum Beispiel die App Bitwarden oder auch Nextcloud Deck. Hier wird mir als User keine Möglichkeit gegeben dem Zertifikat Manuel zu vertrauen, die Apps werden somit unbrauchbar.
Ich habe bisher noch keinen Weg gefunden wie ich iOS 15 dazu bringen kann selbst signierte der Zertifikate zu akzeptieren. Über den Apple Configurator Manager kann ich es nicht machen, da mein iPhone bereits über ein anderes MDM verwaltet (nicht unter meiner Kontrolle oder Einfluss ) wird und zusätzlich habe ich auch kein Account für den Konfigurator Manager.
Gibt es eine Möglichkeit mit der ich mir zum Beispiel mittels open SSL mit erforderlichen Parametern ein Zertifikat erstellen kann welches von iOS akzeptiert wird? Oder gibt es eventuell noch andere Wege selbst signiert Zertifikate zu akzeptieren?
Die bekannten Wege mit Zertifikate inklusive CA und Intermediate CA per Mail zu empfangen, auf dem Gerät zu installieren und Manuel zu trusten habe ich bereits ausgeführt. Das Ergebnis ist oben beschrieben. iOS akzeptiert das Zertifikat nicht ich bekomme auch weiterhin eine Zertifikats Meldung im Safari oder Brave, was ich ebenfalls gerne abstellen möchte.
Vielen Dank für euer Feedback!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 3802779875
Url: https://administrator.de/contentid/3802779875
Printed on: April 26, 2024 at 10:04 o'clock
11 Comments
Latest comment
Moin.
Als erstes musst folgenden minimalen Bedingungen von Apple für die Zertifikate erfüllen:
Requirements for trusted certificates in iOS
Erfüllt das Zertifikat nicht sämtliche Mindestanforderungen kannst du noch so viel versuchen, es wird niemals vertrauenswürdig! Gerne gemachter Fehler ist die Gültigkeit des Zertifikates zu groß zu definieren (> 825 Tage befindet Apple als ungültig).
Apps können aber natürlich auch ihre eigenen Prüfmechnismen für die CA Zertifikatsprüfung verwenden anstatt dem Truststore von Apple. Tun sie das, hast du keine Chance und du musst dir ein Zertifikat einer offiziellen Zertifizierungsstelle z.B. kostenlos von Let's Encrypt ausstellen lassen. Würde ich sowieso empfehlen, da dann das manuelle anfassen der Clients entfällt.
Cheers
certguy
Als erstes musst folgenden minimalen Bedingungen von Apple für die Zertifikate erfüllen:
Requirements for trusted certificates in iOS
Erfüllt das Zertifikat nicht sämtliche Mindestanforderungen kannst du noch so viel versuchen, es wird niemals vertrauenswürdig! Gerne gemachter Fehler ist die Gültigkeit des Zertifikates zu groß zu definieren (> 825 Tage befindet Apple als ungültig).
Apps können aber natürlich auch ihre eigenen Prüfmechnismen für die CA Zertifikatsprüfung verwenden anstatt dem Truststore von Apple. Tun sie das, hast du keine Chance und du musst dir ein Zertifikat einer offiziellen Zertifizierungsstelle z.B. kostenlos von Let's Encrypt ausstellen lassen. Würde ich sowieso empfehlen, da dann das manuelle anfassen der Clients entfällt.
Cheers
certguy
Hallo,
du sagst du hast selbst signierte Zertifikate erstellt bzw. in verwendung ?
Was waren das denn für Zertifikate und was kam auf dem iPhone als Fehlermeldung
Ebenfalls hast du geschreiben das dass Gerät über MDM verwaltet wird. Eventuell
ist das MDM so konfiguriert das du keine "non trusted" Zertifikate und/oder selbst
signierte Zertifikate installieren bzw. verwenden kannst.
Was ich mal hatte war folgendes ( ist schon länger her ):
Ich glaube das dass iPhone nur Zertifikate akzeptiert welche von einer "Master "CA
ausgestellt wurde. Hier glaube ich musst du auf die Zertifizierungskette achten. ?
Die CA kann auch eine Private CA sein, was sie ja meistens in Unternehmen ist.
Soweit ich mich erinner musste ich das CA Cert. einspielen damit der austellenden CA
vertraut wird und dann habe ich das Server Cert hinzugefügt und dann hat alles funktioniert.
Ich hatte als erstes nur versucht das Server Cert. hinzuzufügen ( war ein Exchange in einer Testumgebung ) und das hat nicht funktioniert.
Bevor ich hier eine Sicherheitsdiskussion starte...... es war eine Testumgebung mit MDM und diese war auch nur lokale erreichbar und somit nicht mit dem Internet verbunden
du sagst du hast selbst signierte Zertifikate erstellt bzw. in verwendung ?
Was waren das denn für Zertifikate und was kam auf dem iPhone als Fehlermeldung
Ebenfalls hast du geschreiben das dass Gerät über MDM verwaltet wird. Eventuell
ist das MDM so konfiguriert das du keine "non trusted" Zertifikate und/oder selbst
signierte Zertifikate installieren bzw. verwenden kannst.
Was ich mal hatte war folgendes ( ist schon länger her ):
Ich glaube das dass iPhone nur Zertifikate akzeptiert welche von einer "Master "CA
ausgestellt wurde. Hier glaube ich musst du auf die Zertifizierungskette achten. ?
Die CA kann auch eine Private CA sein, was sie ja meistens in Unternehmen ist.
Soweit ich mich erinner musste ich das CA Cert. einspielen damit der austellenden CA
vertraut wird und dann habe ich das Server Cert hinzugefügt und dann hat alles funktioniert.
Ich hatte als erstes nur versucht das Server Cert. hinzuzufügen ( war ein Exchange in einer Testumgebung ) und das hat nicht funktioniert.
Bevor ich hier eine Sicherheitsdiskussion starte...... es war eine Testumgebung mit MDM und diese war auch nur lokale erreichbar und somit nicht mit dem Internet verbunden
Bisher habe ich das auch so gmeacht. Also root CA, inter, eigentliche cert auf IOS installiert, getrustet an den beiden stellen. Sieht auch in den Settings alles gut aus, grüne Haken, validated. Aber bringt nichts scheinbar.
Ob das MDM irgendwas verbietet ist mir nicht bekannt, wenn dann nicht sichtbar. Wie gesagt, die Settings scheinen ja alle korrekt. Auf meinem anderen iPhone ist allerdings das idetische "Fehlerbild". Die von Apple geforderten dinge allerdings nicht ganz:
Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines:
Gelten die Settings auch für das root CA und inter?
Hat jemand vielleicht einen fertigen opnssl befehl den man etwas anpassen kann der aber alle punkte enthält? GLaub die Anforderungen kann ich bei OPNsense nicht alle einstellen.
Ob das MDM irgendwas verbietet ist mir nicht bekannt, wenn dann nicht sichtbar. Wie gesagt, die Settings scheinen ja alle korrekt. Auf meinem anderen iPhone ist allerdings das idetische "Fehlerbild". Die von Apple geforderten dinge allerdings nicht ganz:
- TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS. - CHECK
- TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm. SHA-1 signed certificates are no longer trusted for TLS. - Ist SHA-512 nach meinem Wissen aus der SHA-2 Familie
- TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted. - Verstehe ich nicht ganz. Ein Wildcard wird hier nicht funktionieren. Ich habe einen Servernamen auf dem laufen aber mehrere Services, ich muss doch den Service Namen eintragen? Konkret was trage ich für einen service z:B. vaultwarden als CN und SAN ein?
Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines:
- TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID. - Da habe ich scheinbar im standard was generiertes, woher weiß ich das diese korrekt ist?
- TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate). - liege ich gerade def. drüber.
Gelten die Settings auch für das root CA und inter?
Hat jemand vielleicht einen fertigen opnssl befehl den man etwas anpassen kann der aber alle punkte enthält? GLaub die Anforderungen kann ich bei OPNsense nicht alle einstellen.
Zitat von @netzer2021:
SAN bedeutet nicht automatisch Wildcard. Das SAN Feld kann eine beliebige Anzahl an DNS Namen IP Adressen etc. beinhalten und wird mittlerweile von fast allen Implementierungen zwingend vorausgesetzt und anstelle des CN verarbeitet!- TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted. -
Wenn das dein Zertifikat nicht gesetzt hat (halte ich für unwahrscheinlich, aber wenn du es vergessen hast musst du den Domainnamen dort zwingend nachtragen!)
Ich habe einen Servernamen auf dem laufen aber mehrere Services, ich muss doch den Service Namen eintragen? Konkret was trage ich für einen service z:B. vaultwarden als CN und SAN ein?
Den Domain-Nameń unter dem du ihn ansprichst. Dieser kommt sowohl in den CN als auch in die SANs* TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID. - Da habe ich scheinbar im standard was generiertes, woher weiß ich das diese korrekt ist?
- TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate). - liege ich gerade def. drüber.
Gelten die Settings auch für das root CA und inter?
Die Gültigkeitsdauer nur für Endinstanz-Zertifikate, alles andere auch für CAsHat jemand vielleicht einen fertigen opnssl befehl den man etwas anpassen kann der aber alle punkte enthält? GLaub die Anforderungen kann ich bei OPNsense nicht alle einstellen. Doch kann man
Hier mal ein Beispiel nicht für ne CA aber für ein selbsigniertes Zertifikat mit den o.g. Settings (aktuelle OpenSSL-Version vorausgesetzt!)
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -nodes -sha256 -days 365 -subj "/C=DE/CN=demo.tld" -addext "subjectAltName = DNS:demo.tld,DNS:sub.demo.tld" -addext "extendedKeyUsage = serverAuth,clientAuth" -addext "keyUsage = critical,keyEncipherment,dataEncipherment" Du siehst jetzt selbst wie kritisch eine perfekte Planung einer Zertifizierungsstelle ist welche man nicht mal so neben bei macht, du solltest dich also eingehender mit der Materie befassen, sonst baust du dir selbst eine Einbahnstraße und fängst immer wieder von Vorne an!!
danke für das feedback. ich lese mich mal weiter ein. Ich weiß, dass es hundertfache tutoruals zu self-signed certs gibt, hast du da vielleicht ein brauchbares an der hand? Insb. das erstellen einer gültigen chain bereitet mir rätsel.
Andere Frage in deinem Beispiel nimmst du eine tld. Unter tld verstehe ich z.b.: publicdomain.de oder publicdomain.com. demo.publicdomain.de wäre dann z.b.: der von mir erwähnte vaultwarden service?
Andere Frage in deinem Beispiel nimmst du eine tld. Unter tld verstehe ich z.b.: publicdomain.de oder publicdomain.com. demo.publicdomain.de wäre dann z.b.: der von mir erwähnte vaultwarden service?
Zitat von @netzer2021:
danke für das feedback. ich lese mich mal weiter ein. Ich weiß, dass es hundertfache tutoruals zu self-signed certs gibt, hast du da vielleicht ein brauchbares an der hand? Insb. das erstellen einer gültigen chain bereitet mir rätsel.
Lerne es am besten von der Pike auf. Die Tut's lassen vielfach wichtige Informationen weg.danke für das feedback. ich lese mich mal weiter ein. Ich weiß, dass es hundertfache tutoruals zu self-signed certs gibt, hast du da vielleicht ein brauchbares an der hand? Insb. das erstellen einer gültigen chain bereitet mir rätsel.
https://docs.microsoft.com/en-us/windows/win32/seccrypto/certificate-ser ...
Andere Frage in deinem Beispiel nimmst du eine tld. Unter tld verstehe ich z.b.: publicdomain.de oder publicdomain.com. demo.publicdomain.de wäre dann z.b.: der von mir erwähnte vaultwarden service?
Eine TLD ist eine TOP LEVEL DOMAIN, also alles was von rechts aus gesehen vor dem ersten Punkt steht, de / com / info / fr / nl usw. Im Beispiel ist das "TLD" wie alles andere also nur ein Platzhalter.
Ein FQDN (Fully Qualified Domain Name) ist dann der komplette Domain Name unter dem du deine Services ansprichst, und der gehört natürlich ins Zertifikat denn diesen verwendest du ja beim Zugriff auf deine Dienste. Denn der FQDN der verwendet wird wird am Ende am Client immer mit den hinterlegten Namen im Zertifikat verglichen.
Ist hier kein Match gegeben, ist das Zertifikat für diesen Namen ungültig.
Danke für das weitere Feedback.
Ich denke so tief brauche ich mich erst mal nicht damit auseinandersetzen, auch wenn es natürlich sinnvoll wäre, aber:
Ich habe noch mal etwas mit den Settings in der OPNsende bei der Zertifikat Erstellung herum probiert:
So funktioniert alles wie ich mir das gedacht habe. iOS akzeptiert das Zertifikat ohne weitere Probleme. Alle genutzten iOS Apps funktionieren bisher.
Einziger Nachteil, den ich momentan sehe ist: kommt ein neuer Server müsste ich ein neues Zertifikat erstellen und verteilen. Bei der Anzahl an Geräten, ist das allerdings überschaubar und für die nächste Zeit sind alle Services vorhanden.
So far….
Ich denke so tief brauche ich mich erst mal nicht damit auseinandersetzen, auch wenn es natürlich sinnvoll wäre, aber:
Ich habe noch mal etwas mit den Settings in der OPNsende bei der Zertifikat Erstellung herum probiert:
- Aus reinem Server Zertifikat ein Server/Client Zertifikat gemacht
- Gültigkeit auf 820 Tage begrenzt
- CN auf meine interne .home gesetzt
- Alle aktuellen Services als SAN eingetragen
So funktioniert alles wie ich mir das gedacht habe. iOS akzeptiert das Zertifikat ohne weitere Probleme. Alle genutzten iOS Apps funktionieren bisher.
Einziger Nachteil, den ich momentan sehe ist: kommt ein neuer Server müsste ich ein neues Zertifikat erstellen und verteilen. Bei der Anzahl an Geräten, ist das allerdings überschaubar und für die nächste Zeit sind alle Services vorhanden.
So far….
Einziger Nachteil, den ich momentan sehe ist: kommt ein neuer Server müsste ich ein neues Zertifikat erstellen
Tja genau dafür gibt's Wildcards ...
So wie ich das verstanden habe, lässt iOS keine Wildcards mehr zu, da doch der DNS Name in dem SAN enthalten sein muss.
Zitat von @netzer2021:
So wie ich das verstanden habe, lässt iOS keine Wildcards mehr zu, da doch der DNS Name in dem SAN enthalten sein muss.
Doch das tut es, nutze ich ja selbst auch, denn wenn iOS keine Wildcard Zertifikate supporten würde hättest du im Web auf den Geräten dauernd Falschmeldungen über ungültige Zertifikate, das würde selbst Apple sich nicht antun.So wie ich das verstanden habe, lässt iOS keine Wildcards mehr zu, da doch der DNS Name in dem SAN enthalten sein muss.
Der Wildcard Eintrag (*.deinedomain.de) muss nur immer auch als SAN enthalten sein, das ist kein Problem, das nutzen tausende Unternehmen.
du hast mal wieder recht ;) funktioniert ohne Probleme, wenn man es denn richtig macht.