Beiträge von m_ueberall

Hallo mainziman,

Zitat von mainziman

m_ueberall ich lese in Deinen Links aber etwas anderes ...

und 2 TXT Records mit dem selben Key sind EIN TXT-Record; wir reden aber von 2 TXT-Records mit unterschiedlichen Keys;

einer f. example.com und einer f. *.example.com und das ist eben nicht erlaubt;

dies wurde auch in der c't bei der Vorstellung von acme.sh geschrieben;

Damit wir nicht aneinander vorbeireden: Aus DNS-Sicht ist der Schlüsselcode von LetsEncrypt der Wert, der Schlüssel wäre hier das "_acme-challenge."-Präfix gefolgt von der Domäne, bspw. "example.com" (analog zu den Schlüsseln "_adsp._domainkey", "_dmarc").

Ich habe das acme.sh-Projekt gerade geclont und einen Beispiellauf mit "./acme.sh --test --issue -d mydomain.de -d '*.mydomain.de' --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please" gestartet, woraufhin ich aufgetragen bekam zwei TXT-Einträge unter "_acme-challenge.mydomain.de" (CCP-Spalte "Host") mit abweichenden Werten (LetsEncrypt-Schlüsseln, CCP-Spalte "Destination") anzulegen.

Und das Eintragen funktionierte testweise mit Pseudo-Werten auch genau so im CCP (analog zu anderen Beispielen wie TLSA-/CAA-Einträgen). Durchgeführt habe ich die Registrierung nach diesem Lauf nicht (weil ich explizit keine Wildcard-Zertifikate danach widerrufen mag), aber die Erfolgsmeldungen im LetsEncrypt-Forum sind bestimmt nicht geflunkert.

Hallo @mainziman/@margau,

Zitat von mainziman

margau: Anmerkung zu Deiner Anleitung; der Grund wieso man bei LE kein Wildcard so bekommt, wie man bei anderen CAs, d.h. der CN=*.example.com und

die x509v3 SAN Erweiterung enthält: example.com und *.example.com, liegt daran, daß hier die notwendigen TXT DNS-Records kollidieren;

um example.com zu validieren braucht es den selben DNS-Record wie die Domain selbst zu valideren, nämlich: _acme-challenge.example.com

und diese sind aber unterschiedlich f. example.com und *.example.com ...

irgendwie ein Design-Fehler ...

Kein Designfehler; es liegt nicht wirklich eine "Kollision" vor, da zwei TXT-Einträge mit demselben Schlüssel erlaubt sind: https://community.letsencrypt.org/t/wildcard-iss…me-name/54528/2 (Erfolgsmeldung in separater Diskussion: https://community.letsencrypt.org/t/wildcard-names-incomplete/54525)

Hallo Hecke29,

Zitat von Hecke29

Trotz neuer Schnittstelle, trat der Fehler eben erneut auf. Eine FailOver war (oder ist?) scheinbar mehreren Servern zugewiesen.

Leicht hilfloses herumklicken im SCP (um diese IP von einem Server ent-zuzuweisen - Button fehlte), brachte nichts. Ich hab jetzt absichtlich einen Node heruntergefahren, um einen erneuten FailOver API-Call zu forcieren. Das SCP ist jetzt auch etwas... unentschlossen welchem Server die IP jetzt gehört (zumindest verhält es sich inkonsistent). Werde dazu ein Ticket eröffnen.

Gab es hierzu eine Rückmeldung? Im Wiki ist zu lesen, dass man eine Zuordnung unter Verwendung der MAC-Adresse 00:...:00 löschen könnte.

Ist es "best practice", dies vor einer Neuzuordnung vorzunehmen?

Hallo Dracoform,

Zitat von Dracoform

Und was machen die Leute die pünktlich zu Ostern die Verwandten besuchen dürfen?

Da ist der Chrome auf dem Handy die einzige Möglichkeit mitzusuchen.

Das alte System zu Weihnachten war da wesentlich besser als diese Ausgrenzung

Hinterher ist man zwar immer schlauer, aber: Alles grundsätzlich eine Frage der Planung/Einstellung.

• Auf einem (getestet: Samsung-)Tablet funktioniert die Suche problemlos
• Wenn man via VNC o.ä. eine Verbindung zu einem entfernten Desktop-Rechner mit graphischer Oberfläche/Browser aufmacht, ist das Problem auch umgangen
• Ein Besuch bei den geliebten Verwandten sollte mehr wert sein als die Ersparnis für ein (halbes) Jahr durch ein Schnäppchen zu Ostern (sprich: positiv denken!), denn es gibt ja zu Weihnachten auch immer Sonderaktionen...

Hallo VVV,

Zitat von VVV

Hallo, wie funktioniert das Whois bei Domains über netcup? [...] meine Wohnadresse sowie Telefonnummer [...]

Lässt sich das irgendwie abstellen? Ändert sich daran vielleicht was nach dem Inkrafftreten der DSGVO?

Laut Denic-Geschäftsführer J. Schweiger wird sich hier in der Tat etwas ändern, siehe das Interview mit heise online: https://heise.de/-3977667

Hallo A:H,

Der Einsatz bzw. die Konfiguration der Verschlüsselung ist in der Tat bei den verschiedenen Anwendungen eine Qual, zumal sich die Einstellungen regelmäßig voneinander unterscheiden. Der "einfachste" Weg führt IMHO wie oben erwähnt (SSH-Tunnel) über spezialisierte Werkzeuge, so dass den Anwendungen selbst nicht bewusst ist, dass die Verbindung verschlüsselt wird; ich selbst verwende hierfür https://www.stunnel.org/ zwischen allen verteilten/verknüpften Applikationen.

(Wichtiger Nebeneffekt: Die Nutzerbasis ist hier insgesamt deutlich größer als diejenige, welche applikationseigene Verschlüsselungsansätze verwendet... sehr hilfreich bei Nachfragen!)

Hallo Kodon,

Zunächst eine Anmerkung zur Verwendung eines Servers mit dynamischer IP-Adresse als MX: Auch wenn das Risiko, dass E-Mails eintrudeln, während die originäre Adresse schon einem anderen Nutzer zugeteilt wurde, während die eigene Reregistrierung mit neuer Adresse noch nicht "durch" ist, ggf. individuell als gering eingeschätzt wird, würde ich dies grundsätzlich nicht machen, auch nicht zu "Versuchszwecken". Da vernünftige Absender bei Übertragungsproblemen i.d.R. mehrere Versuche unternehmen, Mails zuzustellen, und ein als MX eingesetzter Rootserver i.d.R. über eine ebenfalls akzeptable Uptime verfügt/verfügen sollte, geht ja nichts verloren. Auch SPF-Einträge sind für dynamische Adressen nicht sinnvoll nutzbar.

Was die Konfiguration der heimischen Postfix-Instanz anbelangt, wenn es um die Weiterleitung geht: Hier wird man unter den Stichworten "relay[ ]host", "smart[ ]host", "satellite system" fündig. (exemplarische Kurzanleitung: https://medium.com/@federicopanin…st-ad6ef39a1239)

Zuletzt der Punkt Synchronisation/Duplizierung/Backup: Hier ist von der Beschreibung her nicht ganz klar, ob es um eine Instanz geht, die alles archivieren soll ("WORM"/Nur-Lese-Zugriff) oder ob es (neben einem sinnvollen Offline-Backup) um eine redundante, *synchronisierte* Ablage von Mails an zwei Orten (auf zwei Rechnern) geht, was alle Zusatzinformationen (Mail (un)gelesen/(un)markiert/dupliziert/verschoben/...) beinhaltet. Im letzten Fall würde ich keinen Abgleich via Postfix vornehmen/definieren, sondern über zwei via "dsync" verbundene Dovecot-Instanzen (lies: ich mache es so).

Zu den beiden letzten Punkten gibt es einige Videos/Folienpräsentationen (einfach einmal online im Umfeld der FOSDEM/Linux-Tage suchen).

Zitat von ThomasChr

Wenn man nun die Server stundenweiße mieten kann, wird es zum Server bestellen noch einen schnellen, einfachen Weg mit API geben? [...]

Ein Zusatzwunsch mittelfristig, wenn die API verfügbar ist, wäre zudem das Initialisieren eines solchen Servers mit einem eigenen Image – was bei dem vorgenannten Mitbewerber derzeit *nicht* möglich ist (wäre ein echter Wettbewerbsvorteil!) ...

Realisieren ließe sich dies, indem statt Aufspielen eines "Standardimages" etwa via PXE-Einstellungen ein vom Anwender betriebener Server die weitere Konfektionierung übernimmt. (Ein einfacherer Ansatz bestünde darin, daß der Anwender ein entsprechendes Image in den zugehörigen FTP-Bereich lädt und dieses gestartet wird.)

Zitat von [netcup] Johannes

[...]

Zudem sind nun auch Report-URL Einträge möglich. ( m_ueberall)

[...]

Unsere Tests mit diesem Update waren erfolgreich, können Sie das bestätigen?

Ja, die erneute Eingabe von @ CAA [0] 0 iodef "https://meinedom%c3%a4ne.tld/caa-report" wurde nun wie erwartet akzeptiert, herzlichen Dank!

mfg M. Ueberall

Zitat von [netcup] Felix

[E]s ist vollbracht. Ab sofort liefern unsere DNS-Server auch CAA-Records aus[.]

Hallo Herr Preuß,

Ich erhalte folgenden Fehler bei versuchter "Report-URL"-Eintragung:

Fehler: Eintrag ungültig: @ CAA 0 0 iodef "http://meinedomäne.tld/caa-report" Destination des CAA Eintrags ist im falschen Format. Bitte verwenden Sie das Format 0-256 issue/issuewild/iodef "domain.tld"

RFC6844 spricht in diesem Zusammenhang lediglich von einem "URL". Auch wenn viele Beispiele keinen Pfad (der hier analog zu üblichen PKP-/CSP-Report-URLs verwendet werden soll) enthalten, wird er nicht explizit ausgeschlossen. Auch (bekanntere) Generatoren wie https://sslmate.com/caa/ nehmen hieran keinen Anstoß.

Es wäre schön, wenn sich die entsprechende Überprüfung im CCP noch anpassen ließe.

Hallo [gelöschtem Individum],

Ich würde vorschlagen, Deine Fragen vom Forum in einen IRC-Kanal zu verlegen, um (deutlich!) schnellere Rückmeldungen zu erhalten.

Daneben gibt es z.B. auf serverfault.com einige Diskussionen, was die Nutzung von ifup/ifdown anbelangt – versuche es ggf. einmal mit "ifconfig ens3 down|up".

Dank SCP kannst Du ja problemlos mit den Netzwerkeinstellungen herumspielen. Ich würde in Anbetracht der Zeit, die Du bereits damit verbracht hast, auch ins Auge fassen, einmal die IPv4-Netzwerkeinstellungen zu löschen und allein mit IPv6-Definitionen zu arbeiten oder letztere auf "ens3:1" zu verlagern; auch das Booten eines Ubuntu/Knoppix-Live-Images (im Optimalfall mit einer menügeführten Einrichtung von IPv4-/IPv6-Konnektivität; wenn das auch nicht funktioniert, wäre es zumindest ein Anhaltspunkt dafür, daß ggf. der Fehler außerhalb der KVM liegen könnte) und/oder das nachträgliche manuelle Hinzufügen einer IPv6-Adresse/Default-IPv6-Route mittels ip sollte explizit durchprobiert werden.

Zitat von [gelöschtem Individum]

Achso, okay. Aber sollte die IPv6 Adresse nicht trotzdem gelistet werden? Lokal am Rechner/Laptop kann ich die jeweilige Adresse ja auch einsehen?!

Eine IP-Adresse wird nur dann gelistet, wenn sie auch an eine Schnittstelle gebunden wurde; wie oben ausgeführt, fehlt offensichtlich der zugehörige Block (Du hast aber oben etwas diesbezügliches bereits zitiert) oder er wird in Deinem Fall nicht korrekt geparst. (Wenn das im Netcup-Wiki nicht erwähnt ist, wäre eine Übernahme eines gemeinsamen [gelöschtem Individum]s für IPv4 und IPv6 ggf. sinnvoll.)

Ich verwende folgende Einträge (habe die o.g. Adressen substituiert):

auto ens3
iface ens3 inet static
        address 46.38.240.223
        netmask 255.255.252.0
        broadcast 46.38.243.255
        gateway 46.38.240.1
        ##Folgende Zeile nutzen, wenn kein lokaler DNS-Nameserver (bind, unbound, ...) zum Einsatz kommt:
        #dns-nameservers 46.38.225.230 46.38.252.230
        ##Bei Einsatz eines lokalen DNS-Nameservers:
        dns-nameservers 127.0.0.1

iface ens3 inet6 static
        address 2a03:4000:7:c6::1
        netmask 64
        ##Ursprünglich verwendet, wie im Wiki angegeben; nach Warnungen auf einem VServer aber durch 2. Zeile ersetzt:
        #gateway fe80::1
        post-up /sbin/ip -6 route add default via fe80::1 dev ens3
        #dns-nameservers 2a03:4000:0:1::e1e6 2a03:4000:8000::fce6
        dns-nameservers ::1

Zitat von A:H

Vielleicht kann mir jemand von euch bei der Beschleunigung meines ersten richtigen ZFS Systems helfen. Die Lese/Schreibwerte bewegen sich derzeit im data-Pool bei rund 50MB/s und im rpoom bei ca. 100MB/s.

Hallo,

Welches Betriebssystem/welche ZFS-Version wird denn verwendet? (Für Linux empfiehlt sich, falls noch nicht geschehen, ein Blick auf https://github.com/zfsonlinux/zfs/wiki/Getting-Started)

Ein potentieller Grund wäre, daß der Speicherplatz temporär(!) einmal bis zur Neige ausgenutzt wurde, was m.W. bei ZFS unabhängig vom Pool-Aufbau nur durch ein Neuaufsetzen heilbar ist. Um dies vom Anfang an zu verhindern, kann man entweder an bestimmten Einstellungen "schrauben" oder man erstellt sich einfach ein dataset wie folgt ("xx" sollte hierbei 15-20% des Gesamtplatzes einnehmen):

zfs create -o canmount=off -o setuid=off -o exec=off tank/RESERVED
zfs set reservation=xxG tank/RESERVED

Daneben ist zu verifizieren, daß die Samsung-SSD nicht das Problem ist (laut Berichten bricht die Zugriffszeit massiv ein, wenn sie voll belegt ist). Die verwendete Partitionsgröße für L2ARC halte ich für deutlich überdimensioniert, sofern Statistiken nicht das Gegenteil beweisen (vgl. https://github.com/mmatuska/zfs-stats/ o.ä.); ich empfehle hier eine Neuaufsetzung mit 25-50% manuellem Overprovisioning, was auch der Lebensdauer entgegenkommt.

Nicht erwähnt, aber wichtig: Ein regelmäßiges Scrubbing via cronjob sollte gewährleistet werden (alle 1/2/4 Wochen).

Zitat von CmdrXay

[...] Nachteil von fail2ban... wenn jemand mit großer Bandbreite angreift (deswegen vielleicht in Kombination mit dem obigem Vorschlag), sind schon 200 Loginversuche durchgelaufen, bis fail2ban die IP sperrt... [...]

Ein weiteres Problem, sofern man einen Zugriff via IPv6-Adresse(n) erlaubt, ist die Tatsache, daß der derzeit für die meisten Linux-Distributionen verfügbare Versionszweig 0.9x von fail2ban keine IPv6-Adressen sperren kann... ("Meta-Fail"? )

(Das ist hier dokumentiert.)

Hallo Fisi,

Zunächst einmal Überlegungen zum Speicherplatz unabhängig von der Revisionssicherheit: Da von Netcup nicht explizit beworben, gehe ich davon aus, daß der via NFS eingebundene Storagespace nicht von einem ZFS-Pool [1] stammt; unter Datenintegritätsgesichtspunkten (und ggf. im Kontext einer ebenfalls zu planenden Backup-Strategie) wäre der Einsatz von ZFS unter Verwendung einer FreeBSD- oder (Ubuntu-)Linux-Installation auf einem Storage Server IMHO vorteilhaft, da dies (ansatzweise) einen Schutz gegen "kippende Bits" (bitrot/(silent) data corruption) [2] bzw. dem "write hole error" bietet.
Ich selbst lege Mails grundsätzlich auf mehreren ZFS-Datasets ab, welche die untengenannte lokale Datenredundanz gewährleisten (die Spiegelung der Mails zwischen mehreren Servern im active/active-Betrieb erledigt dovecot; generische Lösungen für eine Datenspiegelung erfordern demgegenüber allerdings den (zusätzlichen) Einsatz von DRBD, GlusterFS (block-/dateibasiert), MariaDB Galera Cluster (datenbankbasiert) o.ä.).

Da das Thema "Revisionssicherheit" auch noch auf der eigenen TODO-Liste steht, bin ich grundsätzlich an einem Erfahrungsaustausch/Erfahrungsberichten interessiert. Im Kontext des Einsatzes digitaler Signaturen ist hier je nach Anspruch/Mailaufkommen allerdings auch der Kostenaspekt zu berücksichtigen, d.h. es kann sinnvoll sein, von vornherein einen managed service inkl. SLA ins Auge zu fassen...

[1] Zur Terminologie siehe bspw. hier
[2] ZFS kann diese Fehler immer erkennen; um sie auch (stillschweigend) zu korrigieren, muß mindestens eine weitere, korrekte Kopie der Daten verfügbar sein (das geht selbst unter Verwendung einer einzigen physischen/logischen Partition, vgl. "zfs set copies=N", N>1)

mfg Markus

Hallo,

Zitat von Sheldor

Nun melden sich bei mir in der Tat verschiedene Banken und Firmen und bitten darum einen neuen öffentlichen Schlüssel für ein neues Zertifikat zur Verfügung zu stellen. [...] Hat damit jemand Erfahrung oder kann etwas dauerhaftes vernünftiges für S/MIME empfehlen?

Solange die Hinterlegung eigener S/MIME-Zertifikate via DNS-Eintrag noch nicht möglich ist (vgl. auch meine Anregung hier; Nutzer eigener DNS-Server sind hier natürlich flexibler) bzw. akzeptiert wird -- gleiches gilt auch für (Open)PGP, wo man zumindest Schlüssel dezentral hinterlegen kann --, bin ich für private Zwecke in den letzten Jahren ganz gut mit einem kostenlosen Angebot gefahren; hier empfiehlt sich eine Suche nach "Free Secure Email Certificate with Digital Signature" o.ä. ...

mfg Markus

Hallo,

Und noch eine "Wunscherweiterung" (Posting bitte ggf. verschieben): Gerade im Kontext einiger Angebote, welche LetsEncrypt-Zertifikate verwenden und diese ggf. automatisch erneuern, wäre im CCP die Unterstützung des RR-Typs 257 (DNS Certification Authority Authorization, CAA) gemäß RFC6844 interessant, welcher von Nutzern wahrscheinlich noch eher als TYPE53 und TYPE61 (SMIMEA/OPENPGPKEY, siehe vorheriges Posting) angenommen/verwendet/wertgeschätzt werden dürfte.

Mit freundlichen Grüßen
Markus Ueberall

Hallo,

Zitat von [netcup] Johannes

Wem sind noch Probleme mit DNSSEC oder DANE bekannt momentan?

Ich bin heute ggf. auf ein weiteres Problem gestoßen:
Zur Redundanz-Vermeidung sollte es laut RFC6698 (Absatz A.2.1.1.) möglich sein, beispielsweise für eine Subdomain auf den/die TLSA-Einträge einer anderen Subdomain zu verweisen:

Zitat

_443._tcp.sub1.example.com. IN TLSA 3 1 2 308202c5308201ab...
_443._tcp.sub1.example.com. IN TLSA 2 1 2 308202c5308201ab...
_443._tcp.sub2.example.com. IN CNAME _443._tcp.sub1.example.com.

(Das Ganze sollte insbesondere auch für Wildcards links (=Quelle) und rechts (=Ziel) funktionieren.)

Ich bin mir sicher, alle möglichen Kombinationen durchprobiert zu haben (sowohl mit als auch ohne Wildcards, jeweils ohne abschließendem "." bei Angabe der Domainnamen bei Übertragung des Beispiels), erhalte jedoch immer die Fehlermeldung

Zitat

Fehler: Eintrag ungültig: _443._tcp.sub2 CNAME 0 _443._tcp.sub1.example.com Destination des CNAME Eintrags ist falsch.

(In einem ersten Update-Schritt wurde das vorgenannte Ziel "_443._tcp.sub1" angelegt, es existiert also mit und ohne Wildcard-Verwendung.)

Ich vermute, daß die Syntaxprüfung für den Typ CNAME der entsprechenden CCP-Eingabemaske keine Zielangaben akzeptiert, welche mit nicht-alphanumerischen Zeichen beginnen.

Hallo,

Noch eine "Wunscherweiterung" (Posting bitte ggf. verschieben): Wenngleich die Standardisierung noch andauert, wäre es sicherlich interessant, mit Verfügbarkeit von DNSSEC auch die DNS-Einträge des Typs 53 (SMIMEA) und 61 (OPENPGPKEY) im CCP eintragen zu können, und sei es im Rahmen einer nächsten Betatestphase.

Diese Einträge werden es mittel- bis langfristig erlauben, eMail-Zertifikate in Eigenregie zu verwalten, ohne aufgrund von Akzeptanzproblemen auf der Empfängerseite auf Drittanbieter angewiesen zu sein.
Ich könnte mir vorstellen, daß dies im Zusammenhang mit DNSSEC sehr attraktiv für Kunden ist, welche keine eigenen Nameserver betreiben (können/wollen), aber Wert auf Ende-zu-Ende-Verschlüsselung legen (müssen) -- Netcup würde hiermit zu diesem Thema "alles aus einer Hand" anbieten können.

(Testseiten im Netz zu diesen Einträgen: OPENPGPKEY.info - Test, SMIMEA Test - SMIMEA.info; Hintergrundinformationen zur Zertifikatsverwaltung bspw. mittels XCA: https://bit.ly/phdcXCA)

Mit freundlichen Grüßen
Markus Ueberall

Hallo,

Weil es thematisch mit DNSSEC zusammenhängt (im Zweifelsfall bitte verschieben): Wäre es mittel-/langfristig denkbar, analog zu den VCP Webservices auch einen "CCP Webservice" anzubieten, welcher das Hinzufügen/Löschen von TLSA (und ggf. TXT[*]) RRs für eigene Domains erlaubt?
Hintergrund: Dies würde eine vollautomatische Erneuerung der für DANE erforderlichen Einträge (insbesondere für das vorbereitende "Rollover" bei Zertifikatswechseln) auch für diejenigen Nutzer erlauben, welche keine eigenen (drei) Nameserver betreiben.

[*] diese RRs werden bspw. für die letsencrypt DNS challenge validation verwendet

mfg Markus Ueberall