Tag zusammen. Ich muss mir grade, völlig ohne Vorwissen, Webentwicklung reindrücken und hab ein Problem mit der Konfiguration von SSL. Ein selbsterstelltes Serverzertifikat hab ich mir ausgestellt, komplett mit eigener CA, Host-key, CSR, und CSR signatur. Funktioniert auch soweit, der Server akzeptiert das Zertifikat, und die Webbrowser (FF und Chromium) bauen eine verschlüsselte Verbindung auf - allerdings nur unter Protest und mit Warnung (der Aussteller konnte nicht ermittelt werden). Den Server Key in den Browsern zu integrieren bringt nichts - wird zwar akzeptiert, verhindert aber nicht die obige Warnung. Wie wird das von Leuten mit mehr Ahnung gemacht? Per LetsEncrypt (so das OCSP funktioniert)? Geht das auch für nicht im Internet stehende Webserver, so wie auch meinem Entwickler-PC? Oder hab ich bei der Erstellung des self signed Zertifikats was falsch gemacht und es sollte eigentlich auch so funktionieren?
Welche Art der Validierung hast du benutzt, Domain-Validation? Check Mal noch mit dem Online Tool: https://www.ssllabs.com/ssltest/analyze.html
A. F. schrieb: > Welche Art der Validierung hast du benutzt, Domain-Validation? > Check Mal noch mit dem Online Tool: > https://www.ssllabs.com/ssltest/analyze.html Gar keine. Wie ich bereits schrieb ist der Webserver aus dem Internet nicht erreichbar. Es handelt sich um einen Webserver zur Entwicklung, auf meinem Rechner.
Der mit dem Brecheisen schrieb: > Dann musst du dein CA Cert im Browser importieren genau. Und zwar wirklich das Deiner CA, nicht den öffentlichen Schlüssel des Webservers.
Christobal M. schrieb: > Geht das auch für nicht im Internet stehende Webserver, so wie auch > meinem Entwickler-PC? Dann habe ich es falsch verstanden :) In dem Fall ist die Warnung vom Browser legitim, weil solche Verschlüßelung nicht sicher wäre. Könnte ja jeder selbst die Daten sonst ver- und entschlüßeln auf eigenen Servern. Der mit dem Brecheisen schrieb: > Dann musst du dein CA Cert im Browser importieren Das sollte gehen.
Geht auch OS-Weit, eventuell will man es ja nicht nur in dem einen Browser nutzen: https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate
DPA schrieb: > Geht auch OS-Weit, eventuell will man es ja nicht nur in dem einen > Browser nutzen: Aber aufgepaßt mit Firefox für Windows, der standardmäßig nicht den Zertifikatsspeicher des OS verwendet - außer, man stellt in about_config den Parameter security.enterprise_roots.enabled auf true.
Christobal M. schrieb: > Wie wird das von Leuten mit mehr Ahnung gemacht? Easy-RSA. Gibt es sogar unter Windows. Das CA Zertifikat muss Du aber selbst im Browser/OS importieren. Self-signed wird seit einiger Zeit nicht mehr akzeptiert, weil nicht wirklich sicherer als unverschlüsselt.
Jim M. schrieb: > Self-signed wird seit einiger Zeit nicht mehr akzeptiert, weil nicht > wirklich sicherer als unverschlüsselt. So ein Schwachsinn. Ich traue natürlich einem von mir selber ausgestellten Zertifikat weit mehr als irgendeinem von irgendeiner anderen CA ausgestellten.
Angehängte Dateien:
-
ssl-self-signed-cert.png
30 KB
Jim M. schrieb: > Christobal M. schrieb: >> Wie wird das von Leuten mit mehr Ahnung gemacht? > > Easy-RSA. Gibt es sogar unter Windows. Werde ich mir anschauen, danke für eure Hilfe. Unter FF funktioniert das selbst signierte Zertifikat nun, Chromium spackt noch rum (ERR_CERT_COMMON_NAME_INVALID) weil er ein paar extra Felder im Zertifikat haben will. Mal sehen, vielleicht kann ich mir tipperei sparen wenn Easy-RSA das auf die Reihe bekommt. Jim M. schrieb: > Self-signed wird seit einiger Zeit nicht mehr akzeptiert, weil nicht > wirklich sicherer als unverschlüsselt. Ist eine ziemliche Unverschämtheit von den Browser Herstellern - verschlüsselt ist verschlüsselt, auch wenn das Zertifikat nicht von irgendeiner halbseidenen "offiziellen" CA bestätigt wurde. Das Problem das ich als angehender Webentwickler habe ist, das manche sachen - hier aktuell WebRTC - nicht funktionieren wenn der Server kein gültiges Zertifikat/SSL hat. Die Browser weigern sich dann schlicht Geräte wie Webcam/Mikrofon anzusprechen. Und was mich nervt ist generell das man sich als Entwickler erstmal damit rumschlagen muss das die Tools die einem eigentlich helfen sollen funktionieren, anstatt das man sich auf die eigentliche Aufgabe konzentrieren kann. Aber das ist OT :)
Als Webentwickler brauchst du eh einen richtigen Server, nicht die Desktop Spielzeuge. Viele Funktionen gehen tatsächlich nur mit einem richtigen Server. zB - Kreditkartenzahlungen - Mails versenden Mittels config files steuerst du welche Funktionen nicht aktiv sind.
> .. verschlüsselt ist verschlüsselt, auch wenn das Zertifikat nicht von
irgendeiner halbseidenen "offiziellen" CA bestätigt wurde.
Du bist dir aber schon klar worum's geht ? Schon mal gesehen wie das bei
einer abgehoerten Verbindung tut ?
Tun tut es so : Das Zertifikat wurde ersetzt, bitte neu Laden, bitte
hier clicken. Dann kann der in der Mitte mithoeren. Verschluesselung
aufgehebelt.
Du musst immer damit rechnen, dass eine Funktionalitaet nicht tut. Also
keine Webcam, kein Mikrophon kommt.
Christobal M. schrieb: > Unter FF funktioniert das selbst signierte Zertifikat nun, Chromium > spackt noch rum (ERR_CERT_COMMON_NAME_INVALID) weil er ein paar extra > Felder im Zertifikat haben will. > Mal sehen, vielleicht kann ich mir tipperei sparen wenn Easy-RSA das auf > die Reihe bekommt. Dann ist ein CN Eintrag im Zertifikat nicht orin.local
Der mit dem Brecheisen schrieb: > Christobal M. schrieb: >> Unter FF funktioniert das selbst signierte Zertifikat nun, Chromium >> spackt noch rum (ERR_CERT_COMMON_NAME_INVALID) weil er ein paar extra >> Felder im Zertifikat haben will. >> Mal sehen, vielleicht kann ich mir tipperei sparen wenn Easy-RSA das auf >> die Reihe bekommt. > > Dann ist ein CN Eintrag im Zertifikat nicht orin.local Doch, schon:
1 | openssl x509 --noout -text -in server-pub.pem |
2 | Certificate: |
3 | Data: |
4 | Version: 3 (0x2) |
5 | Serial Number: |
6 | 30:...:f3 |
7 | Signature Algorithm: sha256WithRSAEncryption |
8 | Issuer: C = de, ST = asd, L = asd, O = asd, OU = asd, CN = asdasd, emailAddress = asd@asd.asd |
9 | Validity |
10 | Not Before: Aug 6 08:22:44 2019 GMT |
11 | Not After : Mar 27 08:22:44 2044 GMT |
12 | Subject: C = DE, ST = Bundesland, L = Stadt, O = Einrichtung, OU = Abteilung, OU = Team, CN = orin.local |
13 | Subject Public Key Info: |
14 | Public Key Algorithm: rsaEncryption |
15 | RSA Public-Key: (2048 bit) |
16 | Modulus: |
17 | 00:d8:e2:3e:b8:19:b1:09:4e:77:fa:57:50:b4:1b: |
18 | ... |
19 | e2:9a:93:6d:54:6e:73:f3:ab:31:b5:b5:b2:38:d1: |
20 | 92:db |
21 | Exponent: 65537 (0x10001) |
22 | X509v3 extensions: |
23 | X509v3 Basic Constraints: |
24 | CA:FALSE |
25 | X509v3 Key Usage: |
26 | Digital Signature, Non Repudiation, Key Encipherment |
27 | Signature Algorithm: sha256WithRSAEncryption |
28 | ae:cd:86:a3:41:09:5f:c7:2b:26:79:e7:01:54:bb:78:74:64: |
29 | ... |
30 | db:87:9d:b8 |
Googles Chrome/Chromium will nur ein zusätzliches Feld "subjectAlternativeName" haben. Wenn das Fehlt - bumm. Ist sogar in meinem CSR enthalten gewesen, aber beim signieren wohl nicht übernommen worden. Ich gehe mal davon aus das es in der openssl.cnf auskommentiert ist, unverifiziert.
1 | openssl req -text -noout -verify -in server.csr |
2 | verify OK |
3 | Certificate Request: |
4 | Data: |
5 | Version: 1 (0x0) |
6 | Subject: C = DE, ST = Bundesland, L = Stadt, O = Einrichtung, OU = Abteilung, OU = Team, CN = orin.local |
7 | Subject Public Key Info: |
8 | Public Key Algorithm: rsaEncryption |
9 | RSA Public-Key: (2048 bit) |
10 | Modulus: |
11 | 00:d8:e2:3e:b8:19:b1:09:4e:77:fa:57:50:b4:1b: |
12 | ... |
13 | 92:db |
14 | Exponent: 65537 (0x10001) |
15 | Attributes: |
16 | Requested Extensions: |
17 | X509v3 Subject Alternative Name: |
18 | DNS:orin.local, DNS:orin |
19 | Signature Algorithm: sha256WithRSAEncryption |
20 | 61:7a:89:0b:85:dd:f0:df:0c:5b:53:c8:60:92:59:84:75:ca: |
21 | ... |
22 | d6:89:a1:6d |
Christobal M. schrieb: > Ist eine ziemliche Unverschämtheit von den Browser Herstellern - > verschlüsselt ist verschlüsselt, auch wenn das Zertifikat nicht von > irgendeiner halbseidenen "offiziellen" CA bestätigt wurde. Nö ist es nicht. Das war ja kürzlich die große Diskussion in Kasachstan. Der Stand wollte eigenen Zertifikat allen Internet-Nutzern aufzwingen, somit bei Bedarf alles entschlüßeln können....Die Idee wurde wegen dem großen Widerstand und Kritik aus dem Ausland vorerst aufs Eis gelegt.
Christobal M. schrieb: > Ich muss mir grade, völlig ohne Vorwissen, Webentwicklung reindrücken > und hab ein Problem mit der Konfiguration von SSL SSL sollest Du generell überall deaktiveren, weil es schon seit Jahren unsicher ist und von jedem halbwegs tauglichen Securityscan angemault wird. Was Du meinst, ist TLS. Doppelnepp schrieb: > - Mails versenden > Mittels config files steuerst du welche Funktionen nicht aktiv sind. <Loriot>Ach</Loriot> War mir neu, daß man Mails nicht von einem Desktop aus versenden kann. Und ich steuere was aktiv ist indem ich nur installiere was ich brauche... A. F. schrieb: > Nö ist es nicht. Doch ist es. Der Browser hat sich nicht über den User hinwegzusetzen. Mainstream CA's müssen drin sein, das ist schon klar. Aber dem User zu verweigern, eigene CA's zu importieren geht gar nicht. Ich maintaine unsere firmeninterne CA (und nein LE geht nicht für alles); da wird die CA auf den Rechnern mitinstalliert und gut is. Wenn ein Staat so eine Nummer abziehen will, geht es ja um MITM. Und dafür gibt es schon seit Jahren HPKP; da braucht's kein Gängeln durch den Browserhersteller.
Ein Webserver hat einen Domainnamen, und der kann mails von der eigenen Domain versenden. Mit einem normalen Desktop, resp NAS Server wirst du keine Mails so versenden koennen. Frueher ging das noch, ist aber eine weile her, aber mittlerweile eben nicht mehr. Ja, du kannst au ein NAS einen SMTP server aufsetzen, den selbst signieren, das war's dann aber auch schon. Andere Empfaenger-Mail Server akzeptieren keine Mails von solchen Servern mehr.
Weg mit dem Troll ! schrieb: > Ein Webserver hat einen Domainnamen, und der kann mails von der eigenen > Domain versenden. > > Mit einem normalen Desktop, resp NAS Server wirst du keine Mails so > versenden koennen. Eure scheiß Mails interessieren niemanden in diesem Thread. Es geht um SSL Zertifikate auf einem Entwicklerrechner.
Am einfachsten ist es den Service Provider nach ner Authentifizierungsstelle zu fragen. (Du hast ja die Domain irgendwo gehostet) Die meisten bieten dir eine Lösung an; vermutlich hast Du im HostingPaket auch ein oder zwei solche Zerifikate inklusive. Du kannst auch externe Zertifizierungsstellen nutzen, das kostet dann halt n paar Euro im Jahr. Selfsigned wird immer Warnungen ausspucken (der Browser kann sich aber dein Vertrauen darin merken wenn Du ihn drum bittest (häkchen setzen bei "merken" und auf "dieser stelle vertrauen" klicken reicht gewöhnlich) Das kann aber immer nur der User, das kann nicht der SiteAdmin für den User.. hilft also nur begrenzt. 'sid
c.m. schrieb: > Es geht um SSL Zertifikate auf einem Entwicklerrechner. für einen rein lokalen entwicklungsrechner? spar dir das ganze ssl gedöns und fertig. konsequenz bei der einbindung von resourcen vorausgesetzt gibt es dann selten noch ein problem in der produktivumgebung.
woas i nit schrieb: > für einen rein lokalen entwicklungsrechner? > spar dir das ganze ssl gedöns und fertig. HTTP/2 z.B. will SSL sehen, sonst is nich. Und das ist jetzt nur ein Beispiel. Und man will das SSL Gedöns mal auf dem abgeschotteten Entwicklungsrechner ausprobieren, bevor man es in die freie Wildbahn loslässt. sid schrieb: > Selfsigned wird immer Warnungen ausspucken [...] > häkchen setzen bei > "merken" und auf "dieser stelle vertrauen" klicken reicht gewöhnlich) > Das kann aber immer nur der User, Genau DIESES Verhalten will man seinen User NICHT antrainieren. Denn wenn sie das dann bei $Bankseite genau so machen, sind die Kontozugangsdaten weg. Das ist der Sinn hinter den vielen fiesen Verrenkungen die man für self-singend heutzutage machen muss. Und bei einer CA kann der Firmen Admin die selbstverständlich auch zentral installieren. Übrigens ist das mit eigener CA gar nicht soviel komplexer als mit self-signed. In beiden Fällen nimmt man entweder fertige Software oder tippt OpenSSL Kommandozeilen Befehle aus dem Internet ab...
Jim M. schrieb: > Und man will das SSL Gedöns mal auf dem abgeschotteten > Entwicklungsrechner ausprobieren, bevor man es in die freie Wildbahn > loslässt. Jim M. schrieb: > sid schrieb: >> Selfsigned wird immer Warnungen ausspucken [...] >> häkchen setzen bei >> "merken" und auf "dieser stelle vertrauen" klicken reicht gewöhnlich) >> Das kann aber immer nur der User, > > Genau DIESES Verhalten will man seinen User NICHT antrainieren. Denn > wenn sie das dann bei $Bankseite genau so machen, sind die > Kontozugangsdaten weg. was jetzt bitte? user zum testen oder lokaler entwicklungsrechner?
Weg mit dem Troll ! schrieb: > Ein Webserver hat einen Domainnamen, und der kann mails von der eigenen > Domain versenden. > > Mit einem normalen Desktop, resp NAS Server wirst du keine Mails so > versenden koennen. Frueher ging das noch, ist aber eine weile her, aber > mittlerweile eben nicht mehr. Ja, du kannst au ein NAS einen SMTP server > aufsetzen, den selbst signieren, das war's dann aber auch schon. Andere > Empfaenger-Mail Server akzeptieren keine Mails von solchen Servern mehr. Du laberst nur irgendein blabla, weil Du offensichtlich keine Ahnung hast. Da bleibt wirklich nur das Zitat von Nuhr. Ein Webserver muß keinen Domainnamen haben; der funktioniert einwandfrei nur mit IP Adressen; und im LAN kann man davon Millionen nutzen. Dir ist vielleicht garnicht bewußt, daß im Hintergrund nur mit IP gearbeitet wird. Wenn Du also irgendeine Domain eintippst, dann geht der Request an die IP des Servers, zusammen mit dem Host Header. Und komm jetzt bitte nicht mit der dummen Vermutung, daß man für TLS eine Domain braucht. Glaubste nicht? Guckst Du auf https://1.1.1.1/. So nutze ich zB eine eigene CA für IP-TLS zur gesicherten DB Replikation. Komisch, ich kann sehr wohl mit SMTP Mails von meinem Rechner und meinen Servern verschicken; und die kommen auch überall an. Ach Gottchen, wieso nur? Weil es geht wenn man es richtig macht.
Beitrag #5943320 wurde vom Autor gelöscht.
Jim M. schrieb: > HTTP/2 z.B. will SSL sehen, sonst is nich. Und das ist jetzt nur ein > Beispiel. HTTP/2 ist auch inheränt unsicherer Schrott, weil viel zu komplex. Jim M. schrieb: > Und man will das SSL Gedöns mal auf dem abgeschotteten > Entwicklungsrechner ausprobieren, bevor man es in die freie Wildbahn > loslässt. SSL kann ich lokal eh nicht vernünftig testen. Auf dem Server laufend heißt nicht automatisch in freier Wildbahn.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.