Hi, das SSL-Zertifikat ist ja schon etwas länger abgelaufen, warum wird es nicht erneuert? Class 1 Zertifikate sind ja bei StartSSL.com kostenlos, und in naher Zukunft integriert auch MS das CA-Zertifikat: Eddy Nigg (StartCom Ltd.) wrote: > Third, I'm glad to announce for the first time publicly, that Microsoft > decided to support the StartCom CA root fully starting during the > September-October time-frame this year. Yes, this is great news!
Es gibt seit einigen Tagen erneute Sicherheitswarnungen beim Zugriff auf die Forenseiten.
Habe ich auch manchmal. Konnte aber selber kein Grund dafür finden. Beim Zugriff auf die normale Seite( ohne https ) kommt es im IE manchmal zu der Meldung das ein Zertfikatsproblem besteht. Der Quelltext enhählt auf den ersten blick nichts was mit https zu tun hat. (Vermutlich wird per Javascript etwas von einer https quelle nachgeladen). Aber selbst ein Beobachtung des Proxy hat mit keine https quelle angezeigt. Fand ich etwas misteriös.
Seltsam. Es wäre hilfreich wenn jemand einen Screenshot von den Detailinformationen so einer Meldung posten könnte.
Angehängte Dateien:
-
Zwischenablage-1.jpg
410 KB
Andreas Schwarz schrieb: > Seltsam. Es wäre hilfreich wenn jemand einen Screenshot von den > Detailinformationen so einer Meldung posten könnte. Hier mal bei https, hatte die Meldung heute aber auch schonmal bei http auf dem Schirm.
Das Root-Zertifikat von StartCom ist anscheinend noch nicht in Redmond angekommen.
Rufus t. Firefly schrieb: > Das Root-Zertifikat von StartCom ist anscheinend noch nicht in Redmond > angekommen. Eher in Norwegen :)
Aber in Redmond auch nicht, habs grad mit IE8 ausprobiert > Das Sicherheitszertifikat dieser Website wurde nicht von einer > vertrauenswürdigen Zertifizierungsstelle ausgestellt.
@ Peter: Das ist kein Fehler. Hake "Meine Wahl für dieses Zertifikat merken" an und klicke dann "Zulassen".
Ach, das hatte ich mir gar nicht so genau angesehen, von wem dieser Browser jetzt war. Kam mir unbekannt vor, also tippte ich auf IE ... Und der soll wohl das Root-Zertifikat von StartCom nicht kennen.
Diese meldung meine ich aber nicht, ich kann es hier (Arbeit) auch leider nicht nachvollziehen. Zuhause beim IE8 tritt das Problem regelmässig auf. Wenn man aber direkt auf https geht, geht alles. Es wird scheinbar etwas von https geladen selbst wenn man auf der normalen http seite ist. Und dabei kommt es zu dem Zertifikatsfehler. mal sehen ob ich heute mal zu einer genaueren Analyse komme.
Wobei das vielleicht nicht daran liegt, dass das Zertifikat von StartCom in Redmond und Olso noch nicht angekommen sei. Sondern möglicherweise an fehlendem Vertrauen in diesen Zertifizierer: http://www.php-space.info/51__vorsicht,bei,kostenlosen,ssl,zertifikaten.html.
Peter schrieb: > Diese meldung meine ich aber nicht, ich kann es hier (Arbeit) auch > leider nicht nachvollziehen. Zuhause beim IE8 tritt das Problem > regelmässig auf. Wenn man aber direkt auf https geht, geht alles. Bei mir nicht, da gibts auch bei https://www.mikrocontroller.net den Fehler. Uhu Uhuhu schrieb: > @ Peter: > > Das ist kein Fehler. Hake "Meine Wahl für dieses Zertifikat merken" an > und klicke dann "Zulassen". Ich wage zu behaupten das du mich meintest. Ein Fehler bleibt auch bei Ignorieren dieses Fehlers ein Fehler. Die Frage ist jetzt wer den Fehler gemacht hat. Andreas? StartCom (ein Name bei dem ich eher misstrauisch werden würde)? Opera? Microsoft?
Beim üblichen Weg zu Zertifikaten wird durch den Kunden auf seinem System ein Signing Request erzeugt. Dabei bleibt der Kern des Zertifikats auf diesem System, nur der Request geht an den Zertifizierer. Damit kann der Zertifizierer zwar das Zertifikat signieren, aber selbst nicht in die abgesicherten Übertragungen eingreifen. Bei StartCom wird laut Heise-Artikel das komplette Zertifikat bei StartCom erzeugt, auch der sonst lokal erzeugte Teil davon. Damit ist StartCom prinzipiell in der Lage, nach Belieben in die verschlüsselte Information einzugreifen, da dort die vollständige Information vorliegt. Auf dieser Basis ist es nicht verwunderlich, wenn Microsoft und Opera sich weigern, StartCom als Zertifizierer anzuerkennen. Mozilla tut es jedoch, siehe http://www.heise.de/newsticker/Mozilla-vertraut-kostenlosen-StartCom-Zertifikaten--/meldung/73850/.
Zusammenfassend kann man also sagen, dass das Zertifikat für mikrocontroller.net defakt Schrott ist. Führt aber auch zur Fragen, wozu man für ein Forum https braucht (ich rede nicht vom Shop)?
Das Zertifikat hat m.E. einen nur wenig höheren Sicherheitsstatus als ein selbst ausgestelltes. Die Übertragung erfolg verschlüsselt, aber die Identität des Gegenübers ist kaum abgesichert, zumal die Angaben bei der Ausstellung kaum oder nicht wirkungsvoll überprüft werden. Eine einigermassen ernsthafte Überprüfung kostet eben Geld. Gegen Angriffsversuche Dritter irgendwo zwischendrin in der Leitung ist man damit wohl sicher, ausser wenn das StartCom oder damit verbundene Interessenten sind. Nicht sicher ist jedoch, dass man auch wirklich mit demjenigen kommuniziert, den man an anderen Ende erwartet.
Stimmt, es ist ein kostenloses Domain Validated (DV) Zertifikat. Es stellt sicher das mit der angegebenen Domain kommuniziert wird, gibt aber nicht preis welche Person dahintersteckt. Um das Zertifikat zu erzeugen muss man Zugriff auf den Mailserver bzw. webmaster@ haben. Dagegen sind Class 2-Zertifikate personenvalidiert, ebenfalls kostenlos und ebenfalls in ihrer Anzahl unbegrenzt. [1] Die Validierung kostet jährlich 29,90 USD. [2] Der private Schlüssel muss nicht vom Wizard generiert werden, es kann auch ein Certificate Request CSR erstellt werden. [3] Opera benutzt IMHO den Zertifikatspeicher vom Windows, und in diesen wird im vierten Quartal das Root-Zertifikat von MS eingefügt. Funktioniert per optionalem Windows Update für Vista und 7. [1] http://www.startssl.com/?app=25#27 [2] http://www.startssl.com/?app=34 [3] http://www.startssl.com/?app=25#44
A. K. schrieb: > Das Zertifikat hat m.E. einen nur wenig höheren Sicherheitsstatus als > ein selbst ausgestelltes. Ich halte das selbst ausgestellte Zertifikat für sicherer, da der geheime Schlüssel dazu nicht Dritten bekann wird.
Angehängte Dateien:
-
screen1.png
180 KB
das Problem mit derm Zertifikat kommt beim http zugriff kommt von dem Werbebanner. Ja das Zertifikats-Austeller wird vom IE nicht als Vertrauenswürdig angesehen. Links unten die wird die URL https://www.mikrocontroller.net/images/bn_rakers2.png aufgerufen
Uhu Uhuhu schrieb: > Ich halte das selbst ausgestellte Zertifikat für sicherer, da der > geheime Schlüssel dazu nicht Dritten bekann wird. Das muss er aber nicht, siehe oben. Wer StartCom nicht vertraut kann ja das Root-CA löschen. In ein selbst ausgestelltes Zertifikat kann ich aber beliebige Daten eintragen, und damit kann tatsächlich nicht verifiziert werden, woher es kommt. Meiner Meinung nach sollten im Browser die unterschiedlichen Versionen anders dargestellt werden, ähnlich wie EV- und normale Zertifikate. Aber leider versteht der Großteil der Leute den Unterschied eh nicht, und behandelt alle Arten gleich bzw. ignoriert die Fehlermeldungen eh. Übrigens kann man bei Class 2 Zertifikaten von StartSSL auch mehrere Domains und wildcards vergeben, damit wäre ein Zertifikat möglich, das *.mikrocontroller.net und *.embdev.net enthält. Tom schrieb: > Führt aber auch zur Fragen, wozu > man für ein Forum https braucht (ich rede nicht vom Shop)? Für den Login, falls man nicht Gast ist?
Marco G. schrieb: > Übrigens kann man bei Class 2 Zertifikaten von StartSSL auch mehrere > Domains und wildcards vergeben, damit wäre ein Zertifikat möglich, das > *.mikrocontroller.net und *.embdev.net enthält. Nur ist es völlig wurscht, welche Klasse eines StartSSL Zertifikats man verwendet - solange deren Stammzertifikat in Windows und Opera fehlt.
Zum einen kann man es selbst importieren, zum anderen ist es bei Windows nur noch eine Frage der Zeit. Bei Opera sieht wohl eher schlecht aus.
Es geht um Webserver-Zertifikate. Bei denen jeder das importieren müsste, der auf der Seite landet und dafür kein Mozilla verwendet. Das kann man nur in Einzelfällen mit mehr oder weniger geschlossenem Benutzerkreis machen.
Angehängte Dateien:
Zertikatfehler MC.net wird hiermit weitergegeben. Wenn es andere auch betrifft, hier anmerken, ansonsten haengt es am Providers lokaler Bufferung.
Firefox auf Android meint, die Verbindung sei sicher, trotz abgelaufenen Zertifikat. Oliver
Oliver S. schrieb: > trotz abgelaufenen Zertifikat. Warum? Common Name mikrocontroller.net Validity Not Before Wed, 11 Sep 2024 22:42:44 GMT Not After Tue, 10 Dec 2024 22:42:43 GMT
Marco G. schrieb: > In ein selbst ausgestelltes Zertifikat kann ich aber beliebige Daten > eintragen, und damit kann tatsächlich nicht verifiziert werden, woher es > kommt. Das ist korrekt. Aber: wenn man sich (aus welchen Gründen auch immer) sicher sein kann, dass das Zertifikat authentisch ist, ist es sicherer als jedes Zertifikat, welches durch eine der üblichen CA signiert ist. Denn damit vertraut man im Kern nur darauf, dass die Authentizitäts-Prüfung der CA (oder gar ihres Sub-Zertifizierers) hinreichend gründlich war. Und: es gibt eine ganze Reihe von Beispielen, wo das eben nicht der Fall war. Diese ganze Zertifizierungs-Kacke ist im Wesentlichen nur eine Geldmaschine. Eine typische "nur scheinbar gute" Idee. Die sehr bald von Leuten okkupiert wurden, die sie halt als mögliche Geldquelle erkannt haben. Nunja, die meisten dieser Abzocker bleiben dabei in dem Bereich, der das System wenigstens nicht die eigene Grundlage entzieht. Einige aber halt auch nicht...
Oliver R. schrieb: > Oliver S. schrieb: >> trotz abgelaufenen Zertifikat. > > Warum? Keine Ahnung. Da stand halt „Zertifikat abgelaufen“. Jetzt nicht mehr. Oliver
Ob S. schrieb: > Diese ganze Zertifizierungs-Kacke ist im Wesentlichen nur eine > Geldmaschine. Eine typische "nur scheinbar gute" Idee. Die sehr bald von > Leuten okkupiert wurden, die sie halt als mögliche Geldquelle erkannt > haben. Bei einem Thread lief das Faß am Ende über als noch eine Idee kam, wie das als Geldmaschine zu nutzen wäre. Die Meldung vom abgelaufenen Zertifikat war ungefähr zwei Stunden später ganz weg und kam nicht mehr wieder seit dem.
Dieter D. schrieb: > Die Meldung vom abgelaufenen Zertifikat war ungefähr zwei Stunden später > ganz weg und kam nicht mehr wieder seit dem. Das war kein abgelaufenes Zertifikat, wie man Deinem Screenshot eindeutig entnehmen kann. Da passte das vom Server gelieferte Zertifikat nicht zur aufgerufenen Domain, evtl. ein Bug bei Cloudflare. Dieter D. schrieb: > ansonsten haengt es am Providers lokaler Bufferung. Du hast nicht viel Ahnung von SSL/TLS, oder?
:
Bearbeitet durch User
Beitrag #7752651 wurde vom Autor gelöscht.
Ob S. schrieb: > Diese ganze Zertifizierungs-Kacke ist im Wesentlichen nur eine > Geldmaschine. Ja, die Unsummen, die man monatlich Let's Encrypt in den Rachen werfen muss, die sind schon enorm. Dein Rant wäre vor zehn Jahren passender gewesen.
Harald K. schrieb: > Ja, die Unsummen, die man monatlich Let's Encrypt in den Rachen werfen > muss, die sind schon enorm. Leider ist das nicht in jedem Szenario einsetzbar. Wenn Zertifikate für Server auch in dazwischen befindlichen Firewalls stecken müssen, kann es haarig werden.
:
Bearbeitet durch User
Hmmm schrieb: > Da passte das vom Server gelieferte Zertifikat nicht zur aufgerufenen > Domain, evtl. ein Bug bei Cloudflare. Möglich, aber unterwegs nicht nachvollziehbar ohne den Traffik gescannt zu haben. Die Lite-Version des Browsers unterscheidet da nicht weiter und zeigt keine Details an. "Proceed anyway" riskiert, mehr nicht.
Harald K. schrieb: > Ja, die Unsummen, die man monatlich Let's Encrypt in den Rachen werfen > muss, die sind schon enorm. Du bezahlst das mit deinen Daten. Ich hätte deine Eigenintelligenz als immerhin so weit tragfähig eingeschätzt, dass du das selber erkennst. So kann man sich täuschen...
Ob S. schrieb: > Du bezahlst das mit deinen Daten. Ich hätte deine Eigenintelligenz als > immerhin so weit tragfähig eingeschätzt, dass du das selber erkennst. Ich wusste gar nicht, dass die Let's-Encyrpt-Zertifikate jetzt von Meta ausgegeben werden. Ist glatt an mir vorbeigegangen.
Ob S. schrieb: > Harald K. schrieb: > >> Ja, die Unsummen, die man monatlich Let's Encrypt in den Rachen werfen >> muss, die sind schon enorm. > > Du bezahlst das mit deinen Daten. Welche Daten sollen das sein? Den FQDN bekommt zwangsläufig jede CA mitgeteilt, und dank Certificate Transparency werden die auch generell veröffentlicht. Nicht mit StartCom verwechseln, da war es wohl tatsächlich so. Anders kann ich mir nicht erklären, dass sie darauf bestanden haben, die private (!) Anschrift des Antragstellers zu bekommen.
Ob S. schrieb: > Harald K. schrieb: > >> Ja, die Unsummen, die man monatlich Let's Encrypt in den Rachen werfen >> muss, die sind schon enorm. > > Du bezahlst das mit deinen Daten. Ich hätte deine Eigenintelligenz als > immerhin so weit tragfähig eingeschätzt, dass du das selber erkennst. Welche Daten meinst Du? Da Letsencrypt nur OV-Zertifikate ausgibt (Deine Authentifizierung ist Zugang zum Webserver/Nameserver) ist die Datenspur schon sehr gering.
Thomas W. schrieb: > Letsencrypt nur OV-Zertifikate DV, nicht OV. Deshalb steht auch nur der CN drin.
Hmmm schrieb: > Welche Daten sollen das sein? Den FQDN bekommt zwangsläufig jede CA > mitgeteilt, und dank Certificate Transparency werden die auch generell > veröffentlicht. Eben. Darüber hinaus gibt es noch weitere Punkte, die zwar nicht veröffentlicht, aber gegen Kohle verkauft werden. Mit einer eigenen "CA" (in der der allereinfachsten Form also einem "self signed"-Host-Zertifikat) gibt's weder eine Zwangsveröffentlichung der Domain noch dauerhaft aktelle Informationen über deren Verfügbarkeit. Etwas, dessen schiere Existenz nicht aus einfachen Datenbankabfragen ermittelbar ist, läßt sich naturgemäß nur viel schlechter angreifen. Potentielle Angreifer müssten nämlich erstmal irgendwie ermitteln, dass es dieses mögliche Ziel überhaupt gibt. Über DNS-Abfragen ist (zum Glück) nur der umgekehrte Weg möglich. > Nicht mit StartCom verwechseln, da war es wohl tatsächlich so. Anders > kann ich mir nicht erklären, dass sie darauf bestanden haben, die > private (!) Anschrift des Antragstellers zu bekommen. Nunja, das war natürlich extrem auf's Beutemachen optimiert. Aber der nötige Umweg bei z.B. der Verwendung von "Let's Encrypt" ist auch nicht viel größer.
Ob S. schrieb: > Du bezahlst das mit deinen Daten. Im Datenschutz allgemein und der DSGVO konkret geht es in erster Linie um personenbezogene Daten. Um welche davon geht es bei Let's Encrypt Zertifikaten und inwiefern betrifft das öffentliche Internet-Präsenzen wie µC.net?
:
Bearbeitet durch User
(prx) A. K. schrieb: > Ob S. schrieb: >> Du bezahlst das mit deinen Daten. > > Im Datenschutz allgemein und der DSGVO konkret geht es in erster Linie > um personenbezogene Daten. Um welche davon geht es bei Let's Encrypt > Zertifikaten und inwiefern betrifft das öffentliche Internet-Präsenzen > wie µC.net? Du kannst es dir vielleicht nicht vorstellen, aber es gibt durchaus auch Dienste, die zwar im Internet verfügbar sein sollen und auch authentifiziert und verschlüsselt sein sollen, aber eben möglichst wenig öffentlich. Jeder VPN-Responder, der letztlich in ein privates LAN durchreicht, ist z.B. so ein Dienst. Für den will jeder Normaldenkende so wenig Öffentlichkeit wie irgend möglich.
Ob S. schrieb: > Eben. Darüber hinaus gibt es noch weitere Punkte, die zwar nicht > veröffentlicht, aber gegen Kohle verkauft werden. Und welche sollen das sein? Installiert Let's Encrypt versteckte Software auf den zertfikatsausnutzenden Computern, damit die diese "weiteren Punkte" ausleiten können? Das einzige, was Let's Encrypt bei der Zertifikatserzeugung und -Erneuerung mitbekommt, ist der verwendete FQDN und die dafür genutzte IP-Adresse. Wo kommen Deine "weiteren Punkte" also her? Magie? Fest dran glauben?
Man darf eine Mailadresse abgeben, wenn man an ablaufende Zertifikate erinnert werden will.
Ob S. schrieb: > Du kannst es dir vielleicht nicht vorstellen, aber es gibt durchaus auch > Dienste, die zwar im Internet verfügbar sein sollen und auch > authentifiziert und verschlüsselt sein sollen, aber eben möglichst wenig > öffentlich. > > Jeder VPN-Responder, der letztlich in ein privates LAN durchreicht, ist > z.B. so ein Dienst. Für den will jeder Normaldenkende so wenig > Öffentlichkeit wie irgend möglich. Nun ja, eine falsche Lösung für das falsche Problem ist immer falsch. Das https-Zertifikatsystem hat die Aufgabe, öffentlich zugängliche Server für jedermann sicher identifizierbar zu machen. Für private Server, die möglichst gar nicht sichtbar werden sollen, braucht es andere Lösungen. Klingt komisch, ist aber so. Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > Das https-Zertifikatsystem hat die Aufgabe, öffentlich zugängliche > Server für jedermann sicher identifizierbar zu machen. Diese Einschränkung steht wo genau? Das von dir genannte ist unbestritten die Hauptanwendung, aber eben nicht die einzig mögliche Anwendung. Jedenfalls kenne ich keinen Standard, der eine derartige Enschränkung explizit postuliert. > Für private Server, die möglichst gar nicht sichtbar werden sollen, > braucht es andere Lösungen. Nicht wirklich. Man darf halt nur keine der "vertrauenswürdigen" Root-CAs und die damit verbundenen Zwangs-Veröffentlichungen benutzen und alles ist gut.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.