Chrome: Self-Signed-Certificate installieren

[rudolfkoenig]

Heute ist mir aufgefallen, dass unter Android die vom Desktop gestartete Version des mobilen Frontends, wenn der Zugriff ueber HTTPS/Apache mit Self-Signed-Certificate passiert, eine haessliche URL-Leiste anzeigt. Unter Chrome ist eine "akzeptierte" HTTPS Verbindung auch fuer Service-Worker notwendig, auch wenn FHEMWEB davon (noch?) keinen Gebrauch macht.
Da ich etwas laenger gebraucht habe im Internet eine Loesung zusammenzusuchen, wollte ich das Ergebnis hier dokumentieren. Dass apache fuer SSL aufgesetzt ist, wird vorausgesetzt. Auch FHEMWEB selbst koennte diese Zertifikate ausliefern, wenn man sie ins .pem Format konvertiert, das habe ich aber nicht mehr getestet.

Hypothesen:
- Chrome akzeptiert ein Zertifikat dann, wenn es dem System bekannt ist, und den Zusatzfeld "Subject Alternative Name" enthaelt.
- Im Android kann man nur Zertifikate einspielen, die den Flag "CA:TRUE" (aka Certificate Authority) haben.

Im Folgenden werden zwei Zertifikate erstellt (CA und Apache), mit dem Ersten wird der Zweite signiert, anschliessend der Erste dem Client (OSX und Android) bekanntgemacht, und der Zweite apache auf einem Linux Server. example.org muss ueberall mit dem von aussen verwendeten Hostnamen ersetzt werden.

- eine Datei openssl2.cfg erstellen mit dem Inhalt:

Code Auswählen Erweitern

[ req ]
default_bits = 2048
default_days = 3650
default_keyfile = example.org.key
default_md = sha256
distinguished_name = dn
encrypt_key = no
prompt = no
req_extensions = ext

[ dn ]
CN = example.org

[ ext ]
basicConstraints=CA:FALSE
subjectAltName=@san

[ san ]
DNS.1 = example.org


CA Zertifikat erstellen und pruefen:

Code Auswählen Erweitern

openssl genrsa -out ca.key 2048
openssl req -new -x509 -sha256 -days 3650\
      -subj /CN=example.org -key ca.key -out ca.crt
openssl x509 -in ca.crt -text
# Check for: CA:TRUE


Server CSR erstellen:

Code Auswählen Erweitern

openssl req -new -out example.org.csr -config openssl2.cfg
openssl req -in example.org.csr -text


CSR signieren:

Code Auswählen Erweitern

openssl x509 -req -sha256 -days 3650\
      -CA ca.crt -CAkey ca.key -CAcreateserial \
      -extfile openssl2.cfg -extensions ext\
      -in example.org.csr -out example.org.crt
openssl x509 -in example.org.crt -text
# Check for: X509v3 Subject Alternative Name


Apache Zertifikat austauschen

Code Auswählen Erweitern

  mkdir /etc/apache2/cert
  cp example.org.* /etc/apache2/cert
  vi /etc/apache2/sites-enabled/example.org-ssl, modify:
    SSLCertificateFile    /etc/apache2/cert/example.org.crt
    SSLCertificateKeyFile /etc/apache2/cert/example.org.key
  apachectl graceful


Zertifikat in OSX installieren: ca.crt ins System-Keychain aufnehmen, Chrome neu starten.

Zertifikat in Android aufnehmen:

Code Auswählen Erweitern

- adb push ca.crt /sdcard/Download (oder anderweitig auf dem Geraet kopieren)
- Geraet rebooten
- Einstellungen
    Geraetesicherheit
      Andere Sicherheitseinstellungen
        Vom USB-Speicher installieren
          ca.crt aus der Liste auswaehlen, Fertig


Firefox@Desktop zeigt weiterhin einen gelben Dreieck neben https an, wenn jemand eine Idee hat, wie man das repariert, der moege sich melden.

[Thorsten Pferdekaemper]

Hi,
...mal sehen, ob hier noch jemand mitliest.

Für https://forum.fhem.de/index.php/topic,118845.0.html habe ich mich jetzt auch mal wieder mit dem HTTPS-Thema befasst. Tatsächlich ist das notwendig, da ansonsten der Browser sich weigert, den Service-Worker zu starten. Im Prinzip habe ich das mit dem beschriebenen Vorgehen geschafft (siehe auch hier: https://wiki.fhem.de/wiki/FHEM_mit_HTTPS_SSL-Zertifikat_und_eine_eigene_Zertifizierungsstelle).

Allerdings kann man inzwischen über letsencrypt.org "richtige" Zertifikate erstellen, wenn man eine Domain verwendet, die von außen zugreifbar ist. Das will ich aber eigentlich gar nicht. (Es gibt dafür im Prinzip eine Lösung mit einem Zertifikat für *.example.org, aber das ist auch gar nicht so ganz einfach.) Außerdem scheint mir, dass der Browser dazu auch "heraustelefonieren" dürfen muss.

(Das ganze Konzept erscheint mir ein bisschen seltsam. Es ist ein ziemlich großer Aufwand, mein internes Netz gegen sich selbst abzusichern bzw. meine eigene Geräte zu überzeugen, dass das interne Netz sicher ist. Dagegen kann jeder Depp mit irgendeinem Webspace mir so ziemlich jedes Device zumüllen, wenn ich nur einmal aus versehen falsch geklickt habe.)

Was mich eigentlich am Web-Push (also die Sache mit den Service-Workern) interessiert (hat?) war, dass man seine Installation nicht wirklich nach außen bekannt machen muss (außer gegenüber dem Push Notification Provider, aber da geht sowieso alles verschlüsselt und authentifiziert, soweit ich das verstehe). Leider scheitert das im Endeffekt an der Sache mit den Zertifikation. ...ok, man kann das irgendwie machen, aber es ist doch schon ziemlicher Aufwand.

...vielleicht hat dazu jemand eine Idee, Anmerkungen oder weitere Anregungen.

Gruß,
    Thorsten

[rudolfkoenig]

[...] dass man seine Installation nicht wirklich nach außen bekannt machen muss (außer gegenüber dem Push Notification Provider [...]

In der Beschreibungen, die ich gesehen habe, kommt kein Notification Provider vor.
Kannst Du mir eine bessere Doku zeigen?

...vielleicht hat dazu jemand eine Idee, Anmerkungen oder weitere Anregungen.

Ich habe das zwar jetzt ein paarmal durchgelesen, weiss aber immer noch nicht, was die Frage ist

Chrome ist auf dem Weg, alle APIs auf Seiten mit "richtigen" HTTPS zu beschraenken, was fuer alle mit einem nicht oeffentlichen Server Aerger bedeutet. Die sind aber nicht die Zielgruppe von Chrome.

[Thorsten Pferdekaemper]

Hi,

tatsächlich habe ich gar keine Frage gestellt. Ich habe nur angefangen, mich (mal wieder) mit dem Thema zu befassen und bin dabei auf ein paar Schwierigkeiten gestoßen. Konkrete Fragen habe ich dazu nicht (oder eigentlich eher zu viele), freue mich aber trotzdem über Anmerkungen und Ideen dazu.

Mit "Push Notification Provider" meine ich den "Push Service", der z.B. hier beschrieben ist: https://www.phpclasses.org/blog/package/11632/post/1-How-to-Use-PHP-to-Send-Web-Push-Notifications-for-Your-Web-Site-in-2020.html. (Ein bisschen runterscrollen, dann kommt ein Bild.)
Vielleicht hätte ich besser "Push Service Provider" schreiben sollen. Im Endeffekt ist das normalerweise (?) der Browser-Hersteller.

Das ganze funktioniert in etwa so:

• Der Client (also das Javascript-Coding im Browser) ruft das Push-API auf und bekommt (u.A.) eine URL zurück. Die sieht bei Chrome z.B. so aus:
  https://fcm.googleapis.com/fcm/send/dmgsgarble:APA91bFxgarblegarbleKVBXwFlsWbjMqgDa1obegarblegarbleHV5peCSFDhl3Z-lcw7cNIjgarblegarblegarbleNEm82garbleVuK.
• Diese URL schickt man dann an den eigenen Server (also im Endeffekt vielleicht irgendwann mal an FHEM), der das ganze dann speichert. D.h. unser eigener Server kennt damit die "Subscriber" der Nachrichten.
• Wenn der Server feststellt, dass es etwas zum "Pushen" gibt (ich habe das mit einem Notify gemacht), dann wird die gespeicherte URL mit der zu sendenden Nachricht aufgerufen. D.h. man ruft (im Fall von Chrome) irgendeinen Server von Google auf und der weiß anhand der URL, an welches Frontend das ganze ausgeliefert werden muss.

Gruß,
   Thorsten

[frober]

Hi,

aktuell akzeptiert der aktuelle Chrom auf Android noch mein selbstsigniertes CA.
Ich habe kein Apache installiert.

Wir, Syrex-o und ich, haben jedoch festgestellt, dass die aktuelle Android-Entwicklungsumgebung standardmäßig selbstsigniertes CAs nicht mehr akzeptiert. Man muss es in der App beim Programmieren explizit erlauben.

Warum ich schreibe, die aktuelle Fhemnativ-App ist davon betroffen.
Da anscheinend ich der einzige bin, der die App so verwendet, hat mich Syrex-o gebeten mir letsencrypt.org anzuschauen.
Dafür muss der (ein) Server über Port 80 von aussen erreichbar sein um ein Wildcard-CA zu erstellen. Mein Fhem hängt geschlossen in einer SUB mit VLan. Nur VPN kann bei Bedarf aktiviert werden.
Sind selbstsignierte CAs so unsicher, dass es Sinn macht diesen Weg zu gehen?
Andererseits kann in der App SSL und die Authentifizierung abgeschaltet werden ( für mich ein Widerspruch).

Wie ist eure Meinung dazu?

Grüße Bernd

[rudolfkoenig]

Wie ist eure Meinung dazu?

Mir geht dieser HTTPS Wahn von Google gehoerig auf dem Keks.
Z.Bsp. funktioniert ServiceWorker unter Chrome nur ueber HTTPS, was einen "localhost-Server" ausschliesst.
Wenn jetzt als Naechstes die selbstsignierten Zertifikate dran sind, dann muss man den betroffenen Server aus dem Internet erreichbar machen. Das duerfte auch im privaten Firmennetzwerk mit eigenen Schluessel ein Problem sein, insofern hoffe ich noch auf irgendwelche Workarounds.

[frober]

Wenn ich dich richtig verstehe, hast du keine Probleme damit, wenn die Fhemnativ-App weiterhin selbstsignierte CAs akzeptiert?

Syrex-o und ich suchen eine Lösung, wie wir weiterhin damit umgehen, um die Sicherheit nicht zu gefährden.

[Syrex-o]

Wenn ich dich richtig verstehe, hast du keine Probleme damit, wenn die Fhemnativ-App weiterhin selbstsignierte CAs akzeptiert?

Syrex-o und ich suchen eine Lösung, wie wir weiterhin damit umgehen, um die Sicherheit nicht zu gefährden.

Für FhemNative werde ich das über einen Workaround versuchen zu erlauben.

[betateilchen]

gebeten mir letsencrypt.org anzuschauen.
Dafür muss der (ein) Server über Port 80 von aussen erreichbar sein um ein Wildcard-CA zu erstellen.

Was ist denn eine Wildcard-CA?
Kann es sein, dass Du CA mit Zertifikat verwechselst?
CA ist doch letsencypt selbst, die signieren als CA die angeforderten Zertifikate.

Das Signieren von Zertifikaten funktioniert bei letsencrypt auch problemlos mit anderen challenges als einem http Zugriff auf den Server, der das Zertifikat bekommen soll.
Sicherlich ist aber HTTP-01 als challenge das bei einzelnen Anwendern am häufigsten (weil am einfachsten umzusetzende) verwendete Verfahren.

Aber für die Erstellung von Wildcard-Zertifikaten läßt letsencrypt die challenge über http (HTTP-01) ohnehin nicht zu.

[frober]

Was ist denn eine Wildcard-CA?
Kann es sein, dass Du CA mit Zertifikat verwechselst?
CA ist doch letsencypt selbst, die signieren als CA die angeforderten Zertifikate.

Das Signieren von Zertifikaten funktioniert bei letsencrypt auch problemlos mit anderen challenges als einem http Zugriff auf den Server, der das Zertifikat bekommen soll.
Sicherlich ist aber HTTP-01 als challenge das bei einzelnen Anwendern am häufigsten (weil am einfachsten umzusetzende) verwendete Verfahren.

Aber für die Erstellung von Wildcard-Zertifikaten läßt letsencrypt die challenge über http (HTTP-01) ohnehin nicht zu.

Ja, ich meine ein Wildcard-Zertifikat. Sorry, ich bin in der Materie nicht so tief drin, ich habe mich nur etwas belesen wg. Fhemnativ.
Was ich gefunden habe, war hauptsächlich auf http gemünzt, auch das Wildcat. Evtl. waren die Beiträge schon etwas älter und es funktioniert nun nicht mehr.
Mir ist auch bekannt,  dass es auch andere Wege gibt, so weit ich mich gerade erinnere ssh!?
Auf jeden Fall braucht Letsencrypt Zugriff auf meinen Server.
Solange es User gibt, die Fhem ohne Sicherheitsgedanken nach außen öffnen, bin ich nicht bereit mein System für ein Zertifikat zu öffnen, das ich eigentlich nicht brauche (bei Bedarf von "innen" aktivierbares VPN).
Und ja, ich weiß, dass ich es auch automatisiert bei Bedarf temporär öffnen kann.
Ich benutze selbstsignierte Zertifikate, die aktuell noch einwandfrei von Android, Windows, Linux (unterschiedliche Browser) akzeptiert werden.

[betateilchen]

Auf jeden Fall braucht Letsencrypt Zugriff auf meinen Server.

Nein. Bei keinem meiner eingesetzten letsencrypt Zertifikate musste Zugriff auf irgendeinen meiner Server (unterschiedlichster Typen - web, mqtt, etc.) gewährt werden.
Diese Zertifikate wurden alle über DNS-challenges verifiziert, ausgestellt und sie werden auch regelmäßig auf gleichem Wege automatisch erneuert.

Solange es User gibt, die Fhem ohne Sicherheitsgedanken nach außen öffnen,

Zumindest sind wir uns darüber einig, dass das ein Zustand ist, der eigentlich nicht tragbar ist
Aber es gibt ja auch immer noch Menschen, die ohne Sicherheitsgurt autofahren oder im Auto mit dem Handy am Ohr auf der Fahrerseite sitzen...

[frober]

Nein. Bei keinem meiner eingesetzten letsencrypt Zertifikate musste Zugriff auf irgendeinen meiner Server (unterschiedlichster Typen - web, mqtt, etc.) gewährt werden.
Diese Zertifikate wurden alle über DNS-challenges verifiziert, ausgestellt und sie werden auch regelmäßig auf gleichem Wege automatisch erneuert.

OK, dann war es nicht ssh sondern DNS.
Gut zu wissen, dass diese Möglichkeit ohne Zugriff auf den Server funktioniert. Ich werde darauf zurückgreifen, wenn selbstsignierte Zertifikate nicht mehr akzeptiert werden.
Aktuell ist meine To-Do zu lange....

Zumindest sind wir uns darüber einig, dass das ein Zustand ist, der eigentlich nicht tragbar ist

Wir werden noch einen gemeinsamen Nenner finden.