SSL Probleme nach TSL 1.0/1.1 auf 1.3

affefreebsd

affefreebsd

Well-Known Member
Moin,
mir ist aufgefallen, dass nachdem meine Email Provider auf TLS 1.3 gewechselt hat mein openBSD Server (6.6) die Emails (via cron-Skript) nicht mehr abholt, bzw auswertet.

Error:
Certificate failure for imap.one.com: certificate has expired: /O=Digital Signature Trust Co./CN=DST Root CA X3PHP Notice: Unknown: Certificate failure for imap.one.com: certificate has expired: /O=Digital Signature Trust Co./CN=DST Root CA X3 (errflg=2) in Unknown on line 0

Wie kann ich meine Zertifikate updaten? TLS 1.3 sollte ja bei 6.6 dabei sein ...

Gruss
ape
 
Auf der einen Seite muss ich hier natürlich einmal auf das Sicherheitsproblem hinweisen das sich durch so alte Versionen ergibt - selbst dann wenn das System nicht direkt erreichbar ist gibt es da ja durchaus ein paar Punkte.

Auf der anderen Seite wollte ich hier zumindest mal kurz "meine" Updatestrategie einwerfen - unabhängig vom OS versuche ich immer recht aktuell zu bleiben. Natürlich auch wg. möglicher Sicherheitsprobleme, aber auch weil dann die chance groß ist das es nur "kleinere" oder zumindest "weniger" Änderungen gibt um die ich mich dann evtl. kümmern muss.

Zieh ich dagegen von viele Jahre Versionen bei ja oft komplexen abhängikeiten "auf einen schlag" alles auf den einen neueren Stand wird es imho enorm schwer noch nachzuvollziehen wo denn jetzt uu der Fehler liegt, welche Konfigurationen sich alle geändert haben und auch wie die sich alle bedingen. Himmel, manchmal hat sich die Software sogar zwischendrinn umbenannt.

Ein weiterer Punkt ist das ich mich direkt nach dem Update nicht Stunden, evtl. Tagelang um Probleme kümmern muss, sondern nur um 1-3 die sich aus dem kleinen Versionssprung ergeben.

Manche kombinationsfehler lassen sich auch garnicht bei so großen Sprüngen mit etwas pech lösen.

Deshalb meine Strategie: Evolution statt alle paar Jahre revolution.

Und gerade OpenBSD hab ich da als sehr angenehmen Partner kennengelernt mit eher weniger distruptiven Änderungen "pro release".
Eigentlich immer kann man bedenkenlos sysupgrade rund 2-10 Minuten laufen lassen und muss dann "ganz selten" mal kleinigkeiten anfassen. Ganz "grobe" / "wichtige" sachen werden auch immer sauber in der upgradeinfos in der faq kommuniziert - selten das man da ne überraschung erlebt und wenn sinds meist dinge die upstream aus den Packages kommen.
 
CommanderZed schrieb:
Deshalb meine Strategie: Evolution statt alle paar Jahre revolution.
Zum Vergrößern anklicken....

Privat handhabe ich das auch so.

Im Unternehmensumfeld leider nicht immer so durchführbar. Wenn ich mit einer Firma eigene Zeitfenster langwierig vereinbaren muss, in denen ich ein Update machen kann/darf, und dazu noch mit dem RZ verhandeln muss, wann sie jemand dafür vor Ort (für den Fall) abstellen, und das Monitoring in diesem Zeitpunkt abgeschaltet werden muss... Das mach ich nicht bei jeden Update sondern nur einmal im Jahr oder wenn es halt wirklich sein muss :D
 
Die Chance das dann mal was ist ist bei selteneren Update-Durchführungen natürlich viel größer. Abgesehen von den ganzen Sicherheitslücken die man in der Zeit vor sich her schiebt. Wenns gut geht, dann ist ja auch nicht weiter dramatisch. Wenn mal was ist, dann wird das Ganze aber sehr viel teurer als wenn man regelmäßig updaten würde.
Gerade in der heutigen Zeit sollten Updates eigentlich immer und jederzeit zeitnah machbar sein.
Klar gibt es schwierige Fälle. Und nicht immer sind die Lücken für einen selbst auch relevant. Trotzdem sollte die Schwelle fürs Updaten relativ niedrig sein. Schließlich muss man als Admin ja auch den Kopf für hinhalten wenn was passiert. Wenn ich die Verantwortung tragen soll, dann muss es mir aber auch möglich sein meinen Job zu machen.
 
Als Admin und Verantwortlicher lese ich natürlich für die Systeme die Security MLs und sehe mir auch jedes Update im Detail an. Aber oft betrifft es das System eben auch nicht.

Beim anderen Punkt geb ich dir natürlich recht, die Chance dass dann beim Update irgend ein Mist passiert ist größer.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben