Godaddy SSL certificaat .local eruit halen

[HellBeast]

Na 1 november 2015 worden er geen SSL certificaten meer uitgegeven met .local als naam. Dit in verband met een "man-in-the-middle-attack" die daardoor plaats kan vinden. Nu heb ik een klant en die heeft zojuist zijn Godaddy SSL certificaat verlengt met 3 jaar en geimporteerd in Exchange 2010. Nu blijkt dat het certificaat twee .local verwijzingen had en nu is het certificaat geldig tot 1 november 2015. De klant vraagt nu of ik de twee .local adressen eruit wil halen en het certificaat opnieuw wil importeren.

Nu heb ik bij Godaddy wel een procedure gevonden om namen uit een certificaat te halen, maar ik zit een beetje met de gevolgen.

Als ik dit doe hebben de clients intern een probleem, omdat die lokaal connecten met andere namen. Nu zag ik op GoDaddy een handleiding waarmee je exchange kunt configureren om externe DNS namen te gebruiken.

Is dit inderdaad de te bewandelen weg? Of kan dit simpeler? Iemand met ervaring op dit gebied?

[CAPSLOCK2000]

Geen ervaring met Exchange, maar stoppen met .local is sowieso een goed idee.

Let op dat als je bij Godaddy het certificaat veranderd het oude certificaat al snel ongeldig wordt. Zorg dus eerst dat je clients connecten met de FQDN en verander daarna past het certificaat.

[RaseriaN]

URL's in Exchange aanpassen naar externe varianten en dan intern paar DNS records aanmaken?
Cert opnieuw laten uitgeven maar dan zonder .local adressen, importeren, services omzetten (mail/owa/etc) en je bent klaar?

[pennywiser]

Heruitgifte is sws nodig.

[HellBeast]

Bedankt voor de tips. Dus de procedure is inderdaad wel de juiste:

1. Exchange configureren om externe DNS adressen te gebruiken
2. Certificaat aanpassen
3. Certificaat importeren

Top, Ga ik het zo doen! Dankjewel

Overigens, de clients connecten toch automatisch naar FQDN via de autodiscover? Dan hoef je toch op de clients niets te veranderen?

[ Voor 23% gewijzigd door HellBeast op 16-02-2015 12:26 ]

[Jazzy]

HellBeast schreef op maandag 16 februari 2015 @ 12:15:
Bedankt voor de tips. Dus de procedure is inderdaad wel de juiste:

1. Exchange configureren om externe DNS adressen te gebruiken

Even voor de zekerheid, maar dit zijn dus twee stappen.

De eerste is controleren dat AutoDiscover de publieke DNS naam uitgeeft voor interne en externe client connecties. In de praktijk betekent dit dus dat alle InternalURL en ExternalURL waardes naar de zelfde urls wijzen die allemaal dezelfde FQDN als basis hebben, bijvoorbeeld webmail.domain.com.

Tweede stap (of eigenlijk eerst ) is DNS record aanmaken zodat interne clients het interne IP-adres van de Exchange-server krijgen.

Als dit allemaal werkt dan kun je het certificaat vervangen door eentje waar de interne FQDN niet meer op staat.

[HellBeast]

Bedankt voor je uitgebreide toelichting. Ik zag dat er ook een tool is die een hoop voor je kan regelen. Die schijnt alleen niet de OA internal host name aan te passen. Dat moet je dan nog wel zelf doen.

[sanfranjake]

Zou ik niet zo snel doen, afhankelijk van hoe goed die tool rekening houdt met allerlei aangepaste configuraties. Als je maar een server hebt misschien leuk maar als je verschillende groepen met verschillende hostnames voor clientverbindingen hebt ziet het er niet zo betrouwbaar uit. En als Exchange admin wil je toch begrijpen wat er precies allemaal gebeurt, niewaar ?

[Jazzy]

Ben ik het helemaal mee eens. Ben geen fan van die tool omdat die het naar mijn idee simpeler maakt dan het is.

[johnkeates]

Moet je niet gewoon een nieuwe CSR laten ondertekenen en die importeren? Geen stappenplan bij nodig right...

[Jazzy]

Ervan uitgaande dat de .local FQDN niet voor niets op de server staat gebeurt het volgende. De gebruiker start Outlook op zijn domain-joined werkplek. Outlook vraag in AD het SCP op en vind daar de volgende url: https://server11.domain.local/autodiscover/autodiscover.xml. Vervolgens maakt Outlook verbinding met https://server11.domain.local/autodiscover/autodiscover.xml om een AutoDiscover query te doen maar vind geen certificaat waar server11.domain.local op staat. Outlook geeft dan de volgende melding:


Daarom moet je dus eerst zorgen dat de clients niet meer op die interne naam proberen te verbinden.