IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: InfoSec (Seite 15 von 16)

DNSSEC und DANE: TLS-Zertifikate mit TLSA-Records absichern

Meine Domain ist per DNSSEC gesichert, der Webserver bietet TLS an. Mit DANE (DNS-based Authentication of Named Entities) lässt sich beides verbinden: Die Checksumme des TLS-Zertifikats wird als TLSA-Record im DNS veröffentlicht — DNSSEC schützt diesen Record vor Manipulation.

Warum DANE?

Das klassische CA-System hat ein grundsätzliches Problem: Jede der hunderten Certificate Authorities kann ein Zertifikat für jede Domain ausstellen. Wird eine CA kompromittiert oder handelt fahrlässig, können gefälschte Zertifikate im Umlauf sein — der Browser merkt nichts. DANE löst das, indem der Domaininhaber selbst festlegt, welches Zertifikat gültig ist. Der Hash steht im DNS, DNSSEC garantiert die Integrität. Keine CA kann das unterlaufen.

Unterstützt ein Client DANE, prüft er beim TLS-Handshake, ob der TLSA-Record zum angebotenen Zertifikat passt. Das funktioniert auch mit selbstsignierten Zertifikaten — solange der Hash stimmt und DNSSEC aktiv ist, wird dem Zertifikat vertraut. Die Spezifikation steht in RFC 6698.

TLSA-Record erstellen

Der TLSA-Record enthält einen Hash des Public Keys (SPKI) aus dem Zertifikat. Mit OpenSSL erzeugt:

openssl x509 -in server.pem -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256

Den Hash trägt man als TLSA-Record in die DNS-Zone ein. Für den Webserver (Port 443):

_443._tcp.www.kernel-error.de. 3600 IN TLSA 3 1 1 a321...f7

Die drei Zahlen 3 1 1 bedeuten:

  • 3 — DANE-EE (End Entity): Das Zertifikat wird direkt geprüft, kein CA-Vertrauen nötig
  • 1 — SPKI (Subject Public Key Info): Nur der Public Key wird gehasht, nicht das ganze Zertifikat. Vorteil: Bei Erneuerung mit demselben Key bleibt der TLSA-Record gültig
  • 1 — SHA-256 als Hash-Algorithmus

Der TTL von 3600 Sekunden ist bewusst kurz gewählt — bei einem Zertifikatswechsel mit neuem Key soll der alte Record schnell ablaufen.

Prüfen

Mit dig lässt sich der TLSA-Record abfragen:

dig TLSA _443._tcp.www.kernel-error.de +short
3 1 1 a321...f7

Ob der Record auch zum tatsächlich ausgelieferten Zertifikat passt, prüft man mit OpenSSL — Hash vom Server-Zertifikat erzeugen und mit dem DNS-Record vergleichen:

echo | openssl s_client -connect www.kernel-error.de:443 2>/dev/null \
  | openssl x509 -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256

Stimmen die Hashes überein, ist alles korrekt. Komfortabler geht es mit posttls-finger (Teil von Postfix) — das Tool prüft TLSA-Record und Zertifikat in einem Schritt.

DANE für E-Mail

DANE funktioniert nicht nur für Webserver. Für E-Mail ist es sogar wichtiger — SMTP hat kein Vertrauensmodell wie Browser, opportunistisches TLS kann trivial per Downgrade-Angriff ausgehebelt werden. Mit DANE und TLSA-Records auf Port 25 wird die Verschlüsselung kryptographisch verifizierbar. Wie man das mit Postfix einrichtet, steht im Beitrag Postfix mit DANE und DNSSEC absichern. Zur Visualisierung des DANE-Anteils im Mailverkehr habe ich damals Mailgraph um DANE-Graphen erweitert.

Siehe auch: DNSSEC einrichten

Fragen? Einfach melden.

PRISM: Ein Blick auf das Überwachungsprogramm

Nachdem nun dieses Thema in den Medien so hochgekocht ist und auch der letzte Facebooknutzer mitbekommen hat das seine Daten nicht „privat“ sind *lach*.
Kommen in der letzten Zeit vermehrt Fragen zu Verschlüsselung bei mir an. Egal ob Kunden auf der Arbeit, Bekannte vom Stammtisch oder irgendwer aus dem Internet! Zwar hat noch immer keiner etwas zu verbergen, zumindest nicht wirklich, also nur das mit den Filmen und den mp3s und den Spielen und und und….. Darum geht es ja aber nicht, denn plötzlich scheint es doch nicht mehr jeden etwas anzugehen, welche Nachrichten, E-Mails oder Bilder sie verschicken. Bla bla bla bla…
War da nicht etwas mit einem Frosch der aus kochendem Wasser springt, wenn man ihn aber im Wasser erwärmt sitzen bleibt bis er tot ist? Ich habe es noch nie probiert, will es auch nicht… Der Punkt ist denn noch klar, oder? Da rennt man Jahrelang herum und predigt was das Zeug hält und nix is.
Ein paar Leute sind stinkig, einige machen sich Gedanken über Verschlüsselung aber in 1 – 2 Monaten interessiert sich kein Mensch mehr dafür und alle verschicken weiterhin ihre Postkarten. Man hat ja nichts zu verbergen und wenn, soll doch so ein Agent von der NSA oder BSI oder sonst einem Verein die Urlaubsbilder sehen, richtig? *ironie alarm*
Na, was soll es? Die Aluhüte mussten ihren Vorrat an Clinex und Handcreme aufstocken *i told you so* und wir sind alle noch ein kleines Bisschen mehr abgestumpft. Dann kann die nächste Welle der Empörung ja kommen.

Fragen? Einfach melden.

StartSSL Identiy Validation Class 2

Veraltet: StartSSL wurde 2017 von allen Browsern als nicht vertrauenswürdig eingestuft und eingestellt. Kostenlose Zertifikate gibt es bei Let’s Encrypt.

Na wunderbar, mein Class 2 x.509 S/MIME Zertifikat läuft in kürze aus. Die Class 2 Validation ist auch ausgelaufen, also muss ich wohl was tun, hm?


Schnell alles bei StartSSL angeschoben und auf den bekannten Anruf irgendwo aus Israel warten… Es klingelte auch aber aus 001 213-341. Die Landesvorwahl ist USA und mein Android meint der Rest wäre etwas aus Los Angeles, CA! Das hat mich etwas überrascht; whatever. Wie gewohnt war das Gespräch schnell erledigt. Wobei die Dame am anderen Ende der Leitung extrem schlecht zu verstehen war. Nun warte ich also auf die Bestätigung meiner Class 2 Zertifizierung.

 


 

*UPDATE*

Na wunderbar:

### Schnipp ###
To Sebastian Van De Meer,

This electronic mail message was created by StartCom’s Administration Personnel:

Congratulations! Your Class 2 Identity Validation has been confirmed and approved. You are eligible for certificates at Class 2 level until 2014-05-01.
Additionally you have been awarded with StartSSL™ Web-of-Trust Notary status due to your fulfilling of all requirements. Well done!

Best Regards
### Schnapp ###

Dann kann ich ja gleich mal von diesem Zertifikat:

Seriennummer: 13:27
SHA1-Fingerprint: 28:AE:4C:96:51:75:EB:18:03:F9:9E:E3:7A:ED:C7:EA:13:8B:44:99

Zu diesem Zertifikat wechseln:

Seriennummer: 33:97
SHA1-Fingerprint: 7F:8B:92:19:FF:07:BF:EB:8E:E0:18:D4:98:B8:48:DF:E3:0E:4A:85

 

 

Unix / Linux Openssl Zertifikat pem konvertieren zu Microsoft Windows pfx

Man man man… Da bittet ein Kollege um ein Zertifikat, ich schraube das schnell zusammen und schiebe es im als .PEM – Base64-kodiertes Zertifikat, umschlossen von „—–BEGIN CERTIFICATE—–“ und „—–END CERTIFICATE—–“ zu.

Nun versucht dieser das Zertifikat auf seinem Windows Server zu importieren. Klappt aber so einfach nicht. Microsoft hätte nämlich gerne das Zertifikat als .PFX (.P12 – PKCS#12, kann öffentliche Zertifikate und private Schlüssel (Kennwort-geschützt) enthalten.) Macht ja auch Sinn wenn es eh in einer Zertifikatsverwaltung liegt und dass ganze Kennwortgeschützt ist. So ist es etwas sicherer, wenn die Datei mal jemanden in die Hände fällt, der es nicht haben soll!

Wie also nun aus PEM ein PFX machen? Openssl hilft:

# openssl pkcs12 -export -out telefon.de.pfx -inkey telefon.de.key -in telefon.de.crt -certfile CACert.crt

telefon.de.key sowie telefon.de.crt sollten wir beim einfachen erstellen des Zertifikates per Openssl ja bereits haben. CACert.crt ist einfach der Zertifikat der CA, mit welchem unsere CSR unterschrieben wurde. Noch Fragen?

Siehe auch: Elliptic Curve Zertifikate mit OpenSSL

Fragen? Einfach melden.

Buchtipp Kabelsalat

Vor einiger Zeit ist mir ein Buch mit dem Titel „Kabelsalat: Wie ich einem kaputten Kabel folgte und das Innere des Internets entdeckte“ empfohlen worden. Klang spannend, also bestellt. So eine Bestellung ist ja schnell gemacht, das Lesen dauert dann doch länger.

Inzwischen habe ich es durch und finde: nicht schlecht. Das Buch ist nicht so technisch, dass man es nicht versteht. Ich glaube selbst meine Mutter könnte es ohne Probleme lesen. Genau das ist aber auch der Punkt — wenn man sich für das Thema nicht interessiert, ist es trotzdem nichts. Wenn man wissen will, wie das Internet wirklich aussieht, sollte man es unbedingt lesen.

Wer ist Andrew Blum?

Andrew Blum ist Journalist und schreibt unter anderem für Wired und die New York Times. Der Anlass für das Buch war ziemlich banal: in seinem Garten in Brooklyn fing ein Eichhörnchen an, ein Kabel anzunagen. Sein Internet wurde langsam und immer wieder gestört. Beim Versuch zu verstehen, wo dieses Kabel eigentlich hinführt, stellte er fest, dass er keine Ahnung hat, wie das Internet physisch aufgebaut ist. Aus dieser Frage wurde dann eine Reise und am Ende ein Buch. Das Original heißt „Tubes: A Journey to the Center of the Internet“ und ist 2012 erschienen, die deutsche Übersetzung kam ein Jahr später im Heyne Verlag.

Was steckt drin?

Blum besucht die Orte, an denen das Internet tatsächlich existiert. Und das sind nicht „die Cloud“ oder „irgendwo im Netz“, sondern sehr konkrete Gebäude mit sehr konkreten Stromanschlüssen. Ein paar Stationen aus dem Buch:

  • DE-CIX in Frankfurt — einer der größten Internet-Knoten der Welt, in dem ein Großteil des europäischen Traffics zusammenläuft
  • MAE-East in Ashburn (Virginia) und das Equinix-Cluster drumherum, wo gefühlt das halbe US-Internet seine Pakete austauscht
  • Pionen, der ehemalige Atombunker in Stockholm, in dem damals unter anderem Bahnhof seine Server stehen hatte (auch Wikileaks war dort einquartiert)
  • Cornwall, wo Transatlantik-Glasfasern an Land kommen — inklusive der Verlegeschiffe, die das Zeug über tausende Kilometer auf den Meeresboden bringen
  • The Dalles in Oregon, wo Google eines seiner ersten großen Rechenzentren am billigen Strom des Columbia River gebaut hat

Blum erklärt dabei nebenbei, wie Peering überhaupt funktioniert, was ein Tier-1-Carrier ist, warum Glasfaserverbindungen genau so verlaufen, wie sie verlaufen, und wer diese ganze Infrastruktur eigentlich besitzt. Das Tempo ist dabei eher Reisereportage als Lehrbuch — wer schon BGP-Sessions konfiguriert hat, lernt fachlich nicht viel Neues, bekommt aber viele Geschichten zu Orten und Menschen, die hinter den abstrakten Begriffen stecken.

Update 2026: Was hat sich seit 2012 geändert?

Das Buch ist inzwischen über zehn Jahre alt. Die Grundstrukturen stehen noch genauso und an vielen Stellen hat sich die Logik sogar verfestigt, an ein paar Punkten ist die Realität aber weitergezogen:

  • Hyperscaler-Konzentration: AWS, Google, Microsoft und Meta betreiben mittlerweile eigene Backbones rund um die Welt und legen sogar eigene Seekabel. Was Blum bei Google in Oregon noch als Ausnahme beschreibt, ist heute Standard.
  • Submarine-Cable-Sabotage: Die Verletzlichkeit von Seekabeln war 2012 eher Theorie. Seit den Vorfällen in der Ostsee 2023/2024 reden auch Politik und Medien drüber.
  • RPKI und BGP-Hijacks: Routing-Sicherheit war im Buch nur am Rande Thema. Heute haben große Provider RPKI-Validierung eingeschaltet, und trotzdem gibt es regelmäßig Routenleaks. Wer mehr will, schaut bei bgp.tools oder im eigenen BGP-Beitrag vorbei.
  • Satelliten-Internet: Starlink, Kuiper und Co. haben einen Teil der Infrastruktur über die Wolkendecke verlagert. Das Buch endet noch mit dem Bild „alles läuft durch Glasfasern“. Stimmt nicht mehr ganz.
  • Datacenter-Strom: Was bei Blum als „günstiger Wasserkraftstrom in Oregon“ auftaucht, ist heute eines der Hauptthemen der Branche — Datacenter sind in vielen Regionen zur Belastung für das Stromnetz geworden.

Lohnt sich das Buch heute noch?

Ja, mit Einschränkungen. Wer das Internet nur als Cloud-Symbol auf einer Powerpoint-Folie kennt, dem öffnet das Buch die Augen. Wer schon mal in einem Rechenzentrum stand oder selbst Peering verhandelt hat, wird gelegentlich schmunzeln und sich bei den Reisebeschreibungen wiederfinden. Auf jeden Fall lesbar, nicht zu lang, gut geschrieben — und nach den 250 Seiten weiß man, warum „die Cloud“ eben doch ein paar sehr konkrete Adressen hat.

Bei Amazon: Kabelsalat — Andrew Blum (Heyne, 2013)

Bild des Buches Kabel Salat von Andrew Blum für eine Buchempfehlung.

Siehe auch: DNS missbrauchen — Dateisysteme, DOOM und Tunnel durch Port 53, Internet in Deutschland und BGP und wie sicher ist das Internet?

Fragen? Einfach melden.

Thunderbird Autoconfig: Automatische E-Mail-Konfiguration für den eigenen Mailserver

Thunderbird kann sich selbst konfigurieren. Der Benutzer gibt E-Mail-Adresse und Passwort ein, Thunderbird sucht die Servereinstellungen automatisch — kein Eintippen von Hostnamen, Ports oder Verschlüsselungsoptionen. Das funktioniert nicht nur bei Gmail oder GMX, sondern auch mit dem eigenen Mailserver. Man muss nur eine XML-Datei an der richtigen Stelle bereitstellen.

Wo Thunderbird nach der Konfiguration sucht

Thunderbird arbeitet eine feste Reihenfolge ab. Sobald ein Schritt eine gültige Konfiguration liefert, ist die Einrichtung fertig:

1. Thunderbird ISPDB — Mozilla pflegt eine zentrale Datenbank mit Konfigurationen für große Provider. Steht die Domain dort, ist sofort alles konfiguriert. Für eigene Mailserver irrelevant.

2. autoconfig.<domain> — Thunderbird fragt https://autoconfig.example.org/mail/config-v1.1.xml. Das ist der Weg, den wir nutzen. Ein CNAME im DNS, ein Webserver mit gültigem TLS-Zertifikat, eine statische XML-Datei — fertig.

3. .well-known auf der Domain — Thunderbird versucht https://example.org/.well-known/autoconfig/mail/config-v1.1.xml. Funktioniert, wenn die Domain selbst einen Webserver hat. Braucht keinen eigenen Hostnamen.

4. MX-Heuristik — Als Fallback versucht Thunderbird gängige Hostnamen wie imap.example.org und smtp.example.org mit üblichen Ports und Verschlüsselung. Klappt oft, ist aber Glückssache.

5. Manuell — Wenn nichts funktioniert, muss der Benutzer alles von Hand eingeben. Genau das wollen wir vermeiden.

Die config-v1.1.xml

Die XML-Datei beschreibt alle Servereinstellungen. Thunderbird liest sie und konfiguriert das Konto automatisch. Hier die Version, die ich für alle meine Maildomains einsetze:

<?xml version="1.0" encoding="UTF-8"?>
<clientConfig version="1.1">
  <emailProvider id="kernel-error.de">
    <domain>kernel-error.de</domain>
    <domain>kernel-error.com</domain>
    <domain>vandemeer.de</domain>
    <domain>fuchs-meckenheim.de</domain>
    <domain>heidbreders.de</domain>
    <domain>linux-rheinbach.de</domain>
    <domain>rfc-ignorant.de</domain>

    <displayName>kernel-error.de Mail</displayName>
    <displayShortName>kernel-error</displayShortName>

    <incomingServer type="imap">
      <hostname>imap.kernel-error.de</hostname>
      <port>993</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </incomingServer>

    <outgoingServer type="smtp">
      <hostname>smtp.kernel-error.de</hostname>
      <port>465</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </outgoingServer>
  </emailProvider>
</clientConfig>

Wichtige Details:

%EMAILADDRESS% — Thunderbird ersetzt das automatisch durch die eingegebene E-Mail-Adresse. Kein PHP nötig, kein dynamisches Script — eine statische Datei reicht. Das ist der große Unterschied zu Outlook Autodiscover, wo ein PHP-Script die E-Mail-Adresse aus dem POST extrahieren muss.

password-cleartext — Klingt gefährlich, ist es nicht. Es bedeutet, dass das Passwort über die TLS-verschlüsselte Verbindung gesendet wird. Der Name ist irreführend — Mozilla meint damit „Klartext innerhalb des verschlüsselten Kanals“ im Gegensatz zu Challenge-Response-Verfahren wie CRAM-MD5.

Port 465 (implizites TLS) — Die Verbindung ist sofort verschlüsselt, kein STARTTLS-Handshake nötig. Ein Eintrag reicht — Thunderbird braucht keinen Fallback.

Mehrere <domain>-Einträge — Eine XML-Datei für alle Maildomains. Thunderbird prüft, ob die Domain der eingegebenen E-Mail-Adresse in der Liste steht.

DNS und Webserver

Für jede Maildomain wird ein DNS-CNAME angelegt:

autoconfig.vandemeer.de.  IN CNAME www.kernel-error.de.

Alle CNAMEs zeigen auf denselben Webserver. Dort braucht jeder Hostname einen eigenen HTTPS-Server-Block mit passendem TLS-Zertifikat — Thunderbird akzeptiert keine Zertifikatsfehler. Die Nginx-Konfiguration ist simpel:

server {
    listen      [::]:443 ssl;
    listen      443 ssl;
    server_name autoconfig.vandemeer.de;

    ssl_certificate     /usr/local/etc/letsencrypt/live/vandemeer.de/fullchain.pem;
    ssl_certificate_key /usr/local/etc/letsencrypt/live/vandemeer.de/privkey.pem;

    location /mail/ {
        alias /usr/local/www/autoconfig-mail/mail/;
    }
}

Das TLS-Zertifikat muss autoconfig.vandemeer.de als SAN enthalten. Bei Let’s Encrypt reicht ein certbot --cert-name vandemeer.de -d vandemeer.de -d www.vandemeer.de -d autoconfig.vandemeer.de beim nächsten Renewal.

Für Domains mit Wildcard-Zertifikat (*.kernel-error.de) entfällt das — der Hostname ist direkt abgedeckt.

Unterschied zu Outlook Autodiscover

Thunderbird und Outlook lösen dasselbe Problem auf unterschiedlichen Wegen:

Thunderbird Autoconfig — Statische XML-Datei, %EMAILADDRESS% als Platzhalter, GET-Request, kein serverseitiges Scripting nötig.

Outlook Autodiscover — POST-Request mit E-Mail-Adresse im Body, PHP-Script extrahiert den Benutzernamen dynamisch, DNS SRV-Records statt CNAME. Details dazu: Outlook Autodiscover für IMAP/SMTP

Beide können auf demselben Webserver laufen. Bei mir bedient autodiscover.kernel-error.de Outlook per POST und liefert gleichzeitig /mail/config-v1.1.xml für Thunderbird aus.

Fragen? Gerne per Kontaktseite.

DKIM Schüssel getauscht

Nachdem nun alle etwas nervös wegen zu kurzer DKIM Keys sind (512Bit), diese lassen sich wohl bei Amazon in knapp 72 Stunden knacken. Habe ich dann meine Schlüssel auch einmal getauscht. Diese hatten bisher eine Länge von 1024 Bit, mit diesen wäre ich also noch locker auf der sicheren Seite denn noch kann es ja nicht schaden sie auf 2048Bit aufzubohren. Fast alle Systeme können mit diesen inzwischen umgehen. Die Leistung aktueller Systeme sollte heute ebenfalls nicht sonderlich unter diesen Schlüssellänge leiden.

Die Schlüssel sind schnell erstellt:

$ dkim-genkey -b 2048 -s kernel-error.de -d kernel-error.de

Wie gewohnt habe ich dann den TXT-RECORD in mein Zonenfile gekippt. Beim signieren der Zone per DNSsec sprang mich aber folgende Fehlermeldung an:

dnssec-signzone: error: dns_rdata_fromtext: kernel-error.de:25: ran out of space

Na nu? Ach so… ja klar! Der TXT-RECORD ist zu lang. Da gibt es ja eine Beschränkung…. Fast vergessen! Mehr als 255 Zeichen sind ja nicht zulässig. Ich musste den DKIM TXT-RECORD also in ein multi-line TXT-RECORD umwandeln. Nicht weiter kompliziert, einfach Klammer auf, Klammer zu und alles brav mit Anführungszeichen trennen. Damit sieht mein Zoneneintrag nun wie folgt aus:

kernel-error.de._domainkey IN TXT ( "v=DKIM1; g=*; k=rsa; "
                    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1V7WG+ZchvAxfJ2wi9jn7vWVs2mDkk66cqrKjTETdbuPwL"
                    "CX4N4IXTemT7SMS2Z+gTxcPNnUCorcMsXigNlGJK4Oq8GNx0fcxbXB+vq522FpM6FY8FVTfhL7bqLg5ajp9k0boJnSRv"
                    "F4wY3nci6E7CYCdP9XjHVoOciJdlrGFMo8rYGGiI9Ubgvue8etqgPCV2T8BKEZgys7kabPyaujSHmqrPbBkjb/F+QPJH"
                    "WqcyD7ywfT5vUkrj40Qiwsr7HxGk9aYCAHwyvdP4dvXd5xfMH2QlRKbrMjIQfKJfD5cfTiAl7YgFBFO1n7Wfj5syB6FE"
                    "bRZR9HO+rusv0hojiViQIDAQAB" )

Schnell noch mit einer Testmail an: check-auth@verifier.port25.com prüfen ob alles korrekt ist.

Fertig….

----------------------------------------------------------
DKIM check details:
----------------------------------------------------------
Result:         pass (matches From: kernel-error@kernel-error.com)
ID(s) verified: header.d=kernel-error.com
Canonicalized Headers:
    To:'20'<check-auth@verifier.port25.com>;'0D''0A'
    Subject:'20'check-auth@verifier.port25.com'0D''0A'
    MIME-Version:'20'1.0'0D''0A'
    Content-Type:'20'text/plain;'20'charset=UTF-8;'0D''0A'
    '20'format=flowed'0D''0A'
    Content-Transfer-Encoding:'20'7bit'0D''0A'
    Date:'20'Fri,'20'09'20'Nov'20'2012'20'11:33:48'20'+0100'0D''0A'
    From:'20'Sebastian'20'van'20'de'20'Meer'20'<kernel-error@kernel-error.com>;'0D''0A'
    Message-ID:'20'<c580aed4c89d48c1a93fea35ee80fe30@vandemeer.de>;'0D''0A'
    DKIM-Signature:'20'v=1;'20'a=rsa-sha256;'20'c=simple/simple;'20'd=kernel-error.com;'0D''0A'
    '09's=kernel-error.com;'20't=1352457228;'0D''0A'
    '09'bh=v55t4Oe0VsnE3Xa3exogjgnS10dkjG1rhPQxGz4STJo=;'0D''0A'
    '09'h=To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:'0D''0A'
    '09''20'Date:From:Message-ID;'0D''0A'
    '09'b=

Canonicalized Body:
    check-auth@verifier.port25.com'0D''0A'
    

DNS record(s):
    kernel-error.com._domainkey.kernel-error.com. 300 IN TXT "v=DKIM1; g=*; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtlhidIl+KZgelAOOVYiGHi+uGxEnpjmhXH2IVZNpH69ZsWYTYd1OgXIvWQnAiQ4rRCyvbjcrKaFnXJUpda9eGJeqlr3hE4YhOPLS34K86+8Gr17+WOofkdc3STmlqAI60r1+bQQh8rCWb1YPXIssinq3ll8GVDwAEmh3Bm8zSWz2Ntc+W/maURTlZbMGaRoi+lwhBzr+DnNYL+mPs3UVQoE9ei2Z/bjNQzdpzWeriFgfk56muVZNTvmn8LxkugMhoHMohCr/vkr99xTVmIeMFwMerB2B/JOpeADIf4Wsz6OJQR3GaBA91MX9T2nFncvW3pL03O4wYYVCGnFqz8gbcQIDAQAB"

NOTE: DKIM checking has been performed based on the latest DKIM specs
(RFC 4871 or draft-ietf-dkim-base-10) and verification may fail for
older versions.  If you are using Port25's PowerMTA, you need to use
version 3.2r11 or later to get a compatible version of DKIM.

 

Siehe auch: DKIM einrichten

Fragen? Einfach melden.

Postfix für sichere E-Mail-Auslieferung: Nur noch per TLS konfigurieren

Verschlüsselte E-Mail-Übertragungen sind meist ganz gut. Zumindest hält sie einem lästige Lauscher vom Hals. Besonders wichtig ist dabei der verschlüsselte Austausch zwischen Mail-Server und Mail-Client. Denn die User sitzen mit ihren Mail-Clients sehr schnell in einem „unsicheren“ Netzwerk. Daher wird inzwischen sehr oft und gut darauf geachtet diese Verbindungen zu sichern.

Die Verbindungen zwischen den Servern werden oft als nicht SO wichtig empfunden. Denn die Kisten stehen ja meist in gesicherten Bereichen (Serverraum, DMZ, Rechenzentrum) und dort zu lauschen ist schon aufwendiger – nicht unmöglich.
Es macht also Sinn seinem Postfix zu ermöglichen seine Server zu Server Verbindungen kryptisch zu gestalten.

Mit folgender Änderung sagt man seinem Postfix dass bei ausgehenden Verbindungen TLS benutzt werden kann, wenn möglich.

$ postconf -e smtp_tls_security_level=may

Wird Postfix nun ein Zertifikat gereicht, welches von Postfix mangels der Root-Zertifikate nicht geprüft werden kann… Ja, dann ist hier schon wieder Ende.

Sep 25 10:38:07 rootserver postfix/qmgr[2069]: D69471A2026: from=<kernel-error@kernel-error.com>;, size=38273, nrcpt=1 (queue active)
Sep 25 10:38:07 rootserver postfix/smtp[9454]: certificate verification failed for gmail-smtp-in.l.google.com[2a00:1450:400c:c05::1b]:25: untrusted issuer /C=US/O=Equifax/OU=Equifax Secure Certificate Authority

Auf Debian Systemen finden sich eine recht gepflegte Ansammlung im Paket: ca-certificates. Nachdem dieses installiert ist:

$ apt-get install ca-certificates

Sagt man Postfix noch wie er es findet:

$ postconf -e smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

Schon sollte Postfix in der Lage sein, ausgehende Serververbindungen zu prüfen und zu verschlüsseln.

Siehe auch: Client-Initiated Renegotiation deaktivieren

Fragen? Einfach melden.

Mehr als nur A-Records

Dass mein DNS-Server DNSsec http://www.kernel-error.de/dnssec beherscht und so meine Zonen schützt, das wissen ja fast alle. Wie man damit nun seinen GPG Schlüssel verteilen kann und/oder die SSH-Fingerprints einzelner Hosts gegen den DNS Server validieren lassen kann…. Dieses findet sich nun hier:

GPG im DNS: http://www.kernel-error.de/dnssec/gpg-im-dns

SSH-Key im DNS: http://www.kernel-error.de/dnssec/ssh-key-im-dns

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑