Ergebnis 1 bis 10 von 10
  1. #1
    Erfahrener Benutzer
    Registriert seit
    07.08.2012
    Beiträge
    204

    Idee 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)

  2. #2
    Erfahrener Benutzer
    Registriert seit
    17.02.2011
    Beiträge
    500
    Interessante Lösung, werde ich bei Zeiten auch mal genauer testen.

  3. #3
    Erfahrener Benutzer
    Registriert seit
    21.08.2012
    Ort
    Eisenhüttenstadt
    Beiträge
    443
    Hallo

    wir testen es auch gerade, kann euch morgen mal ne Rückmeldung geben.

    Mit freundlichen Grüßen

    Martin Krüger
    Systemhaus EHST - Ihr IT Service in Eisenhüttenstadt
    Geschäftsinhaber: M. Krüger | Beeskower Str. 259e | D - 15890 Eisenhüttenstadt |
    Kontakt: ICQ# 117049978 | E-Mail: m.krueger@systemhaus-ehst.de

  4. #4
    Erfahrener Benutzer
    Registriert seit
    07.08.2012
    Beiträge
    204
    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!

  5. #5
    Erfahrener Benutzer
    Registriert seit
    07.08.2012
    Beiträge
    204
    Nur weil ich neugierig bin...

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

  6. #6
    Erfahrener Benutzer
    Registriert seit
    17.02.2011
    Beiträge
    500
    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

  7. #7
    Neuer Benutzer
    Registriert seit
    04.03.2018
    Beiträge
    26
    Gibt es hierfür eig. Mittlerweile eine Lösung Seitens LiveConfig?

  8. #8
    Benutzer
    Registriert seit
    05.02.2013
    Beiträge
    39
    Zitat Zitat von Jens122 Beitrag anzeigen
    Gibt es hierfür eig. Mittlerweile eine Lösung Seitens LiveConfig?
    Würde mich auch interessieren. Ob es da von Liveconfig eine Lösung gibt bzw. geplant ist.

  9. #9
    Erfahrener Benutzer
    Registriert seit
    15.02.2016
    Beiträge
    307
    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 unnötigen Vollzitate. "Antworten" genügt meistens!

  10. #10
    Erfahrener Benutzer
    Registriert seit
    07.04.2011
    Beiträge
    745
    Zitat Zitat von WebOscar Beitrag anzeigen
    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.

Stichworte

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •