DANE & TLSA: dem Zertifikat einen Anker im DNS geben

Wenn zwei Mailserver verschlüsselt miteinander sprechen, stellt sich dieselbe Frage wie im Web: Ist das präsentierte Zertifikat echt? Im Browser vertrauen wir dafür einer Handvoll Zertifizierungsstellen. Bei Server-zu-Server-E-Mail gibt es diesen strengen Prüfmechanismus oft nicht — und genau hier setzt DANE an.

Die Idee

DANE hinterlegt im DNS einen TLSA-Record: einen Fingerabdruck des Zertifikats (oder des ausstellenden Schlüssels), das der Server verwenden soll. Der Gegenüber schlägt vor dem Verbinden nach: Passt das präsentierte Zertifikat zum hinterlegten Fingerabdruck? Wenn nicht, wird die Verbindung abgebrochen.

Warum das DNSSEC braucht

Ein Fingerabdruck im DNS ist nur so vertrauenswürdig wie das DNS selbst. Deshalb ist DNSSEC die Voraussetzung: Es garantiert, dass der TLSA-Record echt ist und unterwegs nicht manipuliert wurde. Ohne DNSSEC könnte ein Angreifer einfach einen eigenen Fingerabdruck unterschieben — DANE wäre wirkungslos.

Was es bringt

• Downgrade-Schutz: Ein Angreifer kann eine verschlüsselte Verbindung nicht heimlich auf „unverschlüsselt" oder ein gefälschtes Zertifikat umbiegen.
• Unabhängigkeit von der CA-Landschaft: Du legst selbst fest, welches Zertifikat gilt.

Wo DANE zählt — und wo nicht

Für E-Mail zwischen Servern ist DANE etabliert und sinnvoll. Für Web (HTTPS) validiert praktisch kein Browser DANE — dort übernehmen andere Mechanismen die Absicherung. Deshalb prüfen wir DANE streng beim Mailserver, behandeln es beim Webserver aber als optionalen Bonus.