Wie man Autodiscover einrichtet, ohne dass Outlook einen Zertifikatsfehler meldet

    An einigen Stellen, hier im Forum, wurde das Thema bereits angeschnitten. Richtet man Autodiscover so ein, wie es im kb#13 beschrieben ist, funktioniert es grundsätzlich. Nur Outlook wirft jedes Mal einen Zertifikatsfehler, da das Zertifikat der Domäne, die das Autodiscover-XML ausliefert, nicht zur Domäne des Nutzers passt.


    Wir haben diese Einträge:


    Code
    autodiscover.kundendomain.tld cname autodiscover.anbieterdomain.tld
autoconfig.kundendomain.tld cname autodiscover.anbieterdomain.tld


    Outlook fragt per default https://autodiscover.kundendomain.tld und bekommt zur Antwort das Zertifikat von autodiscover.anbieterdomain.tld.


    Nun wird hier und da angemerkt, dass sich dieses Problem lösen ließe, wenn ein SRV-Record angelegt wird, da Outlook diesen vorziehen würde:


    Code
    _autodiscover._tcp.kundendomain.tld. 14400 IN SRV  0 0 443 autodiscover.anbieterdomain.tld


    Das ist aber leider nicht so. Outlook prüft erst, ob ein solcher Record existiert, nachdem es die HTTPS-Abfrage durchführt. Es kommt also wieder zum Zertifikats-Fehler.


    Da offensichtlich ausschließlich Outlook nach autodiscover.kundendomain.tld sucht, könnte man den entsprechenden CNAME-Record doch einfach löschen. In der Folge müsste Outlook nach dem SRV-Record suchen.


    Ja - fast! Ich gehe mal davon aus, dass die allermeisten hier per default einen Wildcard-Record für jede Domain setzen, wenn - wie bei uns - ein eigener DNS verwendet wird und nicht die DNS-Funktionalität in LiveConfig. Letztere würde das Problem lösen, da es dann tatsächlich nur Records für existierende Sub-Domains des Kunden anlegen würde. Da es aber bisher keine brauchbare Template-Verwaltung gibt um default-Einträge zu verwalten, fällt das zumindest bei uns aus.


    Also, besteht ein WildCard-Record für die Kunden-Domäne und der CNAME-Record autodiscover.kundendomain.tld ist NICHT vorhanden, wird das i. d. R. ebenfalls nicht funktionieren, wenn der WebServer mindestens ein SSL-Zertifikat installiert hat. (Anderes Thema, wurde aber hier auch schon besprochen). In diesem Fall (probiert es gerne einmal aus) führt ein HTTPS-Request dazu, dass - selbst wenn für die angefragte Domain kein Zertifikat eingerichtet ist - der WebServer offensichtlich das alphabetisch erste Zertifikat nimmt und damit antwortet. Somit bekommt der Kunde ggf. ein völlig fremdes Zertifkat ausgeliefert, was (wiederholt) zu besorgten Anfragen führt.


    Abgesehen davon liefert der WebServer dann auch kein Autodiscover-XML aus.


    Lösung (vielleicht nicht schön, aber läuft):


    Ich habe bei den Kundendomains, mit denen ich getestet habe, den CNAME-Record autodiscover.kundendomain.tld gegen einen A-Record auf 0.0.0.0 getauscht. Der CNAME-Record autoconfig.kundendomain.tld auf autodiscover.anbieterdomain.tld bleibt aber bestehen, damit Thunderbird bedient werden kann! Außerdem habe ich natürlich den o. g. SRV-Record gesetzt.


    Voilà! Ab jetzt gibt es keine gruseligen Zertifikats-Fehler mehr. Outlook richtet ohne Meckern bei Angabe von eMail-Adresse und Passwort das Konto ein.


    Hoffe, diese Problemanalyse nebst Lösungsansatz hilft weiter!


    Grüße,


    Oskar

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

    Ich freue mich auf Eure Rückmeldungen!


    Nachtrag und Zusammenfassung!


    Wenn man zusätzlich noch CNAME-Records für mail, smtp und imap anlegt, funktioniert die einfache Einrichtung - quasi para-autoconfig - auch mit eMail-Programmen, die stumpf ausprobieren! Mit Aquamail habe ich es gerade ausprobiert und das lief rund.


    Zusammengefasst also so: (vereinfacht - Umsetzung entsprechend eingesetztem DNS-Frontend)


    Code
    autodiscover.kundendomain.tld        A      0.0.0.0
autoconfig.kundendomain.tld          CNAME  autodiscover.anbieterdomain.tld


_autodiscover._tcp.kundendomain.tld  SRV    100 443 autodiscover.anbieterdomain.tld


mail.kundendomain.tld                CNAME  mx-server.anbieterdomain.tld
imap.kundendomain.tld                CNAME  mx-server.anbieterdomain.tld
smtp.kundendomain.tld                CNAME  mx-server.anbieterdomain.tld


    Viel Erfolg damit!

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

    Nur weil ich neugierig bin...


    Hat es wer ausprobiert und läuft es so? Bei uns gibt es jedenfalls keine Probleme.

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

    Oh Sorry, wollte noch Rückmeldung geben.


    Ja..funktioniert gut. Keine Probleme festgestellt bis jetzt. Wenn man das ganze template basiert jetzt noch in der Liveconfig DNS Verwaltung vorgeben könnte, wäre es auch langsam eine Überlegung die DNS Verwaltung Liveconfig zu überlassen.


    Ansonsten Top! Lösung .


    Grüße
    Björn

    auto.example.com sei die Adresse in Serververwaltung - E-Mail - Auto-Konfiguration - ohne https.
    example.com sei auf der HSTS preload list.


    1. Stört sich ein Mail-Programm daran und sollte eine andere Autodiscover-Adresse ohne HSTS-Domain verwendet werden?


    2. Funktioniert der Austausch der CNAME-Records durch GUI-Änderung der Autodiscover-Adresse?

    # Das Gras wächst nicht schneller wenn man daran zieht # Bitte keine inflationären Vollzitate #

    Zitat von WebOscar

    Lösung (vielleicht nicht schön, aber läuft):


    Ich habe bei den Kundendomains, mit denen ich getestet habe, den CNAME-Record autodiscover.kundendomain.tld gegen einen A-Record auf 0.0.0.0 getauscht.


    Oder, wie im Wiki beschrieben, einfach irgendwo eine (IPv4/IPv6)-Adresse konfigurieren, auf der Port 443 nicht offen ist (per Firewall-Regel, per Apache/Nginx-Listener, ...).


    Dann läuft der HTTPS-Connect in das Leere und es wird HTTP getestet, dem Redirect gefolgt und damit die Auto-Discovery durchgeführt.


    Wir nutzen die Autodiscovery und Autoconfig zusammen mit DNS-Verwaltung durch LiveConfig schon seit Ende 2017, ohne Probleme (die DNS-Verwaltung hat zwar ihre eigenen Probleme, aber Autoconfig funktioniert 1a).


    Thunderbird/Autoconfig benutzt direkt HTTP, hat das Problem gar nicht.


    Die CNAME-Einträge für IMAP/Mail/... sind IMHO kontraproduktiv, sobald der SSL/TLS-Zwang eingeschalten wird, da die Clients den falschen Hostname konfiguriert haben. Erhöht also den Support-Aufwand, statt ihn zu reduzieren.


    Wozu die DNS-Template-Einträge sinnvoll verwendet werden können: SRV-Records für IMAP etc, vergleiche RFC6186.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden