Posts by 17martin

    Ich habe jetzt alle sechs Intermediates drin stehen. Die zu denen es ein cross-sign gibt (die vier RSA) habe ich als 2 1 1 (sonst müsste man die zwei mal einfügen), die anderen (beiden) als 2 0 1.

    X3 und X4 kann ich dann wieder rausnehmen, wenn Letsencrypt nur noch mit R3 (bzw R4) unterschreibt. Und die kann ich dann auf 2 0 1 umstellen, wenn das mit dem cross-sign vorbei ist (oder ich mich fest für einen Pfad entschieden habe).


    Wie das beim ausstellen dann funktioniert, ist mir auch noch nicht klar. Ob die CA selbst entscheidet, ob sie mit R3 oder E1 unterschreibt oder man das dann am acme-tool einstellen muss...


    Vermutung (so habe ich das zumindest bei schnellen lesen verstanden): Ob ich die den Cert-Pfad zum ISRG Root X1 oder DTS Root CA X3 (für die RSA Zertifikate) nehme kann ich dann selbst bestimmen. Da beide Intermediates das gleiche Keypaar haben und beide im ausgestellten Zertifikate stehen, kommt es darauf an, was du deinen Server als Intermediate ausliefern lässt. Damit Certbot das für einen erledigt (und das richtige Intermediate in die fullchain.pem bastelt), hat der den Parameter --preferred-chain.


    Wer die Hashes nicht selber berechnen will: https://mail.sys4.de/pipermail…020-September/000584.html Zumindest bei den kurzen bin ich auf die lgeichen Werte gekommen.

    Ich möchte in den nächsten Tagen von meinem alten auf den neuen anderen Server umziehen. Als Vorbereitung stelle ich die TTL in den DNS Einstellungen schon mal auf 1. Den Refresh Wert sollte ich dann auch auf 1 stellen, oder? Beides natürlich nur bis auf dem neuen Server alles läuft.


    Andere Frage: Ich möchte mit Hilfe von dd einfach alles übertragen. Ist ein Snapshot auf dem alten Server ein Problem? Wird der dann auch mit übertragen? Falls ich jetzt dabei (z.B. durch Quelle und Ziel vertauschen o.ä.) die Daten auf meinem alten Server zerstöre, ist dann mein Snapshot noch da?

    Ich habe seit Jahren "Nina" auf dem Smartphone. Man kann einstellen, ab welchem Warnunglevel Push-Nachrichten auslöst werden. Das ist besonders beim Wetter wichtig. Ich erinnere mich jetzt an extermes Wetter, Bombenfunde, Brände. Da habe ich Warnungen bekommen. Das funktioniert eigentlich gut und schnell. (Nur gestern nicht eben.)

    Schade, dass die Hochwassermeldungen immer ganz Bayern zugewiesen und nicht lokalisiert sind. Da bekommen ein kleines bisschen "Spam".

    Man kann sich ja auch bei erfolgreicher Zustellung einer Mail einen DSN vom Empfängerserver anfordern. Microsoft schickt da echt einen ziemlich langen Report zurück. Hat schon mal jemand versucht daraus zu erkennen, ob die Mail auch wirklich zugestellt wurde oder im Schwarzen Loch gelandet ist? Evtl steht da ja sogar drin, ob man im Spamordner landet...

    Also, physische Sicherheit und Ausfallsicherheit, der Schutz vor Fremdzugriffen, der Schutz vor internen Zugriffen, die Verschlüsselung der Kommunikation, die Datensicherung und Updates und Patches.

    Nein, dass kann ich ganz sicher nicht. Dann sollte ich wohl dort bleiben und hoffen, dass meine Datenschutzeinstellungen mich etwas vor dem starken Profiling schützen.

    Warum nicht? Im ersten Beitrag schreibst du, dass du das Webhosting nutzten. Da ist doch sind doch eh fast alle Punkte in Netcup-Hand und nicht bei dir. Und ob du jetzt Netcup oder Google mehr vertrauen kannst...?


    physische Sicherheit: kaum zu bewerten.

    Ausfallsicherheit: Google (vermutlich), da mehr Redundanz

    Fremdzugriff: Netcup, da deine Daten dann nicht weltweit auf irgendwelchen Servern liegen können und Daten von Ausländern meist weniger Schutz (vor Behörden) haben. Risiko: Lücke in Nextcloud, über die auf die Daten zugegriffen werden kann.

    interner Zugriff: unentschieden, wobei bei Netcup+RZ Betreiber die Anzahl der berechtigen Mitarbeiter sicher geringer ist

    Verschlüsselung der Kommunikation: unentschieden beide bieten sichere Cipher

    Datenschutz: sicher Netcup, da deren Geschäftsmodell nicht auf der Nutzung deiner Daten basiert.

    Update Patches: unentschieden, solange du deine Nextcloud Instanz aktuell hältst.

    Man kann auch den sshd nur auf localhost lauschen lassen und den Webserver als Proxy dafür konfigurieren oder den Zugriff per Websocket weiterleiten. Natürlich nur wenn ein Webserver auf dem Server läuft, der das unterstützt und man das auf der Client-Seite geregelt bekommt. Weiterer Vorteil: Damit kommt man auch per ssh auf den Server, wenn der momentane Internetzugang das eigentlich sperren will (.z.B. Fritz Gäste-Wlan in der Standard-Konfig, viele Zwangsproxies). Vorsicht, wenn der Webserver nicht läuft, klappt das auch mit ssh nicht mehr.

    Hallo, ich habe mich vor ein paar Woche (endlich) um ein Backup der Daten meines (privat genutzten) Debian Buster Servers gekümmert. Ich habe mich für duplicity + duply entschieden, da das encrypten, komprimieren, inkrementen kann und Webdav unterstützt. Borg hat ja keine Webdav Unterstützung. kopia scheint noch nicht eine so breite User-Basis zu haben. Momentan schiebe ich das Backup "in die gmx-cloud".

    Nun ist mir aufgefallen, dass ja nicht nur die Nutzerdaten Backup-würdig sind, sondern auch diverse Configs. Das Relevante in /etc zu finden ist leicht. Aber was sollte ich noch mit nehmen? In /var/lib scheint einiges enthalten zu sein, was man nicht verlieren will. Welche anderen typischen Verzeichnisse gibt es, in denen Daten landen?


    Mittlerweile haben viele ACME "Clients" (Certbot, dehydrated,...) auch ohne, dass man selbst einen CSR baut, die Option den Key gleich zu lassen beim Zertifikat erneuern.


    Aber wie mache ich das wenn ich ein RSA und ein ECDSA Zertifikate habe? Zwei Dane Records? Momentan löse ich das durch einen 2 0 1 Dane Record mit dem Hash des Let's Encrypt Intermediate Zertifikate X3. Dadurch umgehe ich auch das Problem mit wechselnden Keys. Aber irgendwie nicht so richtig schön.

    Da hat tatsächlich jemand eine eMail bei mir abgegeben und hat dazu IPv6, TLS1.3, das ECDSA Zertifikat und X25519 zum Schlüsselaustausch genutzt. Wie viele Jahre es wohl noch dauert bis das normal wird...?

    Eventuell für ein paar Leute hier interessant: In Buster-Backports gibt es jetzt ein aktuelles Roundcube. Das aus sid war ja nicht ganz problemlos zu installieren.

    Bin ich eigentlich der einzige, der hier weder in Puncto Leistung, noch in Puncto Preis einen Vorteil zu aktuellen Modellen (G8/G9) erkennen kann? :/ Vielleicht könnte hier ja mal ein bisschen was angepasst werden - könnte verkaufsfördernd wirken. ^^

    Vielleicht so?

    Da gibt es noch eine alte Aktion, die immer noch gültig ist:

    https://www.netcup.de/bestellen/produkt.php?produkt=1715 (G7SE VPS500, 2 vKerne, 2GB RAM, 40GB SAS für 2,99€)

    https://www.netcup.de/bestellen/produkt.php?produkt=1718 (G7SE VPS1000, 4 vKerne, 4GB RAM, 80GB SAS für 3,99€)

    https://www.netcup.de/bestellen/produkt.php?produkt=1721 (G7SE VPS2000, 6 vKerne, 8GB RAM, 160GB SAS für 7,99€)

    Klar nur DDR3 RAMs und keine SSD. Aber manchmal ist ja mehr Platz wichtiger als nur IO-Leistung. Ist halt die Frage, ob sich die virtuellen Kerne der Generationen vergleichen lassen. Mit der Karnevals Aktion können die nicht mit halten, aber mit den Standardpreisen...

    Die ECDSA-Sache sollte ich auch endlich mal angehen… :/


    Bisher nutze ich das nur auf einem neu geplanten System. Alle anderen verwenden ausschließlich RSA mit 4096 Bit.

    Ich wollte immer warten bis Letsencrypt ECDSA Intermediate oder Root-Zertifikate hat. Aber da das wohl doch noch länger dauert, habe ich das dann beim buster update mit gemacht.

    Mit dehydrated (Package in Backports) ist das eigentlich ganz einfach. Alles für RSA konfigurieren und für ECDSA beim Aufruf über die Parameter anderen Algo und Ausgabeverzeichnis festlegen (dehydrated -c && dehydrated -c -a prime256v1 -o /var/lib/dehydrated/certs-ecdsa).