Exchange SSL Certificaat fout

[Kavaa]

Op enkele machines krijg ik deze melding als ik een mail account heb toegevoegd van de exchange server.
De server draait gewoon lokaal en heeft eerst een self signed certificaat gehad en daarna een gekocht SSL Certificaat.
Op verschillende machines geprobeerd ook die nooit het self signed hebben gehad.
Maar ik blijf deze melding krijgen.

Hoe kan ik dit oplossen heb al vanalles geprobeerd maar kom er niet uit.
Ook google heeft me nog niet verder kunnen helpen.

Alles draait lokaal.
Op Iphone Ipad en webclient enz werken gewoon goed.
Het SSL Certificaat is van: https://www.sslcertificat...ificaten#DV_Standaard_1_1
En dan het standaard basis certificaat van 10 euro.

Het domein heb ik even weg gehaald.

[Fish]

En komt de naam van het domein in het certifikaat overeen met de hostnaam die (outlook?) probeert te bereiken ?

druk op certifikaar weergeven en vergelijk zou ik zeggen

[Kavaa]

Ik heb al vanalles geprobeerd dat is juist het probleem.
Outlook maakt verbinding met exchange.domein.nl
En het certificaat staat ook op exchange.domein.nl

[col-dejong]

En de computernaam ?
Wordt anders de RootCA niet herkend?

[Kavaa]

Zat ik ook aan te denken maar de computer naam (Exchange) is gewoon goed.
Server draait AD DNS IIS en exchange natuurlijk.

RootCA heb ik al geëxporteerd en op enkele clients getest geen resultaat.

[Remco]

En als je de outlook connectivity test draait? Wat zegt deze?

[Powermage]

Welke Exchange server draai je?
aangezien je voor 2007 en 2010 een SAN certificaat nodig hebt (met meerdere namen)
zo een goedkoop certificaat is vaak niet geschikt daarvoor (en vaak zelfs niet eens ondersteund op mobiele devices waar je hem vooral voor wil hebben)

dit komt doordat je server vaak intern servernaam.activedirectorydomain.local heeft en extern exchange.domeinnaam.nl
deze moeten dan beide in het systeem zitten.

[ Voor 23% gewijzigd door Powermage op 23-04-2012 14:23 ]

[Thc_Nbl]

Ik denk ook dat je het verkeerde certificaat gekocht hebt.
Je moet een "Unified Communications SSL Certificaat" of te wel een SAN SSL certificaat hebben.

je mist nu in je certificaat het volgende.

exchange.domainnaam.nl
servernaam
servernaam.local ? misschien?

kijk maar eens op ssl.nu staat een duidelijke uitleg.

[Kavaa]

Ik draai Exchange 2010.
En gebruik hem alleen intern web enz werkt perfect.
De overige clients die eraan hangen zijn mac's en iPad en iPhones.
Die connecten zonder problemen met Certificaat enz..

Is het dan toch de naam of dergelijken van het certificaat.
Want een self singed zou toch ook al voldoende moeten zijn of niet voor intern gebruik.
Ben gewoon die meldingen een beetje beu ahhaa.
Ik zal zo even een test draaien en even gaan lezen op ssl.nu.

Ik krijg dit bij de test bij het SSL Stukje:

code:

Testing the SSL certificate to make sure it's valid.
    The SSL certificate failed one or more certificate validation checks.
    
    Test Steps
    
    ExRCA is attempting to obtain the SSL certificate from remote server autodiscover.mijndomein on port 443.
    ExRCA successfully obtained the remote SSL certificate.
    
    Additional Details
    Remote Certificate Subject: CN=mijndomein.com, OU=PositiveSSL, OU=Domain Control Validated, Issuer: CN=PositiveSSL CA 2, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB.
    Validating the certificate name.
    Certificate name validation failed.
     Tell me more about this issue and how to resolve it
    
    Additional Details
    Host name autodiscover.mijndomein doesn't match any name found on the server certificate CN=mijndomein.com, OU=PositiveSSL, OU=Domain Control Validated.

[ Voor 49% gewijzigd door Kavaa op 23-04-2012 14:46 ]

[Remco]

Je zou ook nog het certificaat in AD kunnen publiceren als trusted. Het zou eigenlijk al automagisch goedgekeurd moeten worden door je clients, maar er gaat ergens iets mis.
Had je nu al eens de Outlook connectivity test gedraaid? Deze geeft goed aan waar het mis is.

[Kavaa]

Remco schreef op maandag 23 april 2012 @ 14:44:
Je zou ook nog het certificaat in AD kunnen publiceren als trusted. Het zou eigenlijk al automagisch goedgekeurd moeten worden door je clients, maar er gaat ergens iets mis.
Had je nu al eens de Outlook connectivity test gedraaid? Deze geeft goed aan waar het mis is.

Domme vraag schaam maar waar zit dit: certificaat in AD kunnen publiceren als trusted.

Verschillende testjes gedraaid en alles blijkt toch op Certificaat.
Maar een Self signed is dan toch net zo goed zeg maar voor clients intern.
Het Certificaat wat ik nu heb werkt wel goed voor de webacces.

[ Voor 18% gewijzigd door Kavaa op 23-04-2012 14:52 ]

[Remco]

https://www.google.com/se...official&client=firefox-a

[Don van Boven]

Bekijk het volgende artikel eens: Security warning when you start Outlook 2007 and then connect to a mailbox that is hosted on a server that is running Exchange Server 2007 or Exchange Server 2010: "The name of the security certificate is invalid or does not match the name of the site".
Hiermee kan je de diverse URLs juist zetten.

[Jazzy]

Dat zal inderdaad het probleem wel zijn. Gebruik anders eens de Outlook Test Automatische Emailconfiguratie (ctrl indrukken en dan rechtsklikken op het Outlook icoon in de systray). Vul mailadres en wachtwoord in en laat Autodiscover zijn werk doen, vervolgens zie je welke hostnaam Outlook daadwerkelijk gebruikt om met je server te verbinden.

[Kavaa]

Jazzy schreef op maandag 23 april 2012 @ 16:45:
Dat zal inderdaad het probleem wel zijn. Gebruik anders eens de Outlook Test Automatische Emailconfiguratie (ctrl indrukken en dan rechtsklikken op het Outlook icoon in de systray). Vul mailadres en wachtwoord in en laat Autodiscover zijn werk doen, vervolgens zie je welke hostnaam Outlook daadwerkelijk gebruikt om met je server te verbinden.

code:

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
  <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
    <User>
      <DisplayName>Marcel | mijndomein2</DisplayName>
      <LegacyDN>/o=mijndomein1/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=[e-mail]0dc</LegacyDN>
      <AutoDiscoverSMTPAddress>[e-mail]</AutoDiscoverSMTPAddress>
      <DeploymentId>25f14826-8700-458c-ba10-3b130c79282f</DeploymentId>
    </User>
    <Account>
      <AccountType>email</AccountType>
      <Action>settings</Action>
      <Protocol>
        <Type>EXCH</Type>
        <Server>exchange.mijndomein1.com</Server>
        <ServerDN>/o=mijndomein1/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=EXCHANGE</ServerDN>
        <ServerVersion>738280F7</ServerVersion>
        <MdbDN>/o=mijndomein1/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=EXCHANGE/cn=Microsoft Private MDB</MdbDN>
        <PublicFolderServer>exchange.mijndomein1.com</PublicFolderServer>
        <AD>exchange.mijndomein1.com</AD>
        <ASUrl>https://exchange.mijndomein1.com/EWS/Exchange.asmx</ASUrl>
        <EwsUrl>https://exchange.mijndomein1.com/EWS/Exchange.asmx</EwsUrl>
        <EcpUrl>https://exchange.mijndomein1.com/ecp/</EcpUrl>
        <EcpUrl-um>?p=customize/voicemail.aspx&amp;exsvurl=1</EcpUrl-um>
        <EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&amp;exsvurl=1</EcpUrl-aggr>
        <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&amp;IsOWA=&lt;IsOWA&gt;&amp;MsgID=&lt;MsgID&gt;&amp;Mbx=&lt;Mbx&gt;</EcpUrl-mt>
        <EcpUrl-ret>?p=organize/retentionpolicytags.slab&amp;exsvurl=1</EcpUrl-ret>
        <EcpUrl-sms>?p=sms/textmessaging.slab&amp;exsvurl=1</EcpUrl-sms>
        <OOFUrl>https://exchange.mijndomein1.com/EWS/Exchange.asmx</OOFUrl>
        <UMUrl>https://exchange.mijndomein1.com/EWS/UM2007Legacy.asmx</UMUrl>
        <OABUrl>http://exchange.mijndomein1.com/OAB/46ec2a8b-f1de-4b6f-bd56-3507d61c97e3/</OABUrl>
      </Protocol>
      <Protocol>
        <Type>EXPR</Type>
        <Server>exchange.mijndomein2.com</Server>
        <SSL>On</SSL>
        <AuthPackage>Basic</AuthPackage>
        <OABUrl>http://exchange.mijndomein1.com/OAB/46ec2a8b-f1de-4b6f-bd56-3507d61c97e3/</OABUrl>
      </Protocol>
      <Protocol>
        <Type>WEB</Type>
        <Internal>
          <OWAUrl AuthenticationMethod="Basic, Fba">https://exchange.mijndomein1.com/owa/</OWAUrl>
          <Protocol>
            <Type>EXCH</Type>
            <ASUrl>https://exchange.mijndomein1.com/EWS/Exchange.asmx</ASUrl>
          </Protocol>
        </Internal>
        <External>
          <OWAUrl AuthenticationMethod="Fba">https://webmail.mijndomein1.com/owa/</OWAUrl>
        </External>
      </Protocol>
    </Account>
  </Response>
</Autodiscover>

Mijndomein1=

spoiler:

ictwebmail.com

Mijndomein2=

spoiler:

ictwebsolution.com of NL

Dit zijn 2 domeinnamen 1 gebruik ik als reply adres zeg maar, en 1 is mijn hoofd adres.
en dan hebben we nog een .nl en dat is ook een reply

[Jazzy]

Nou, dan kun je aan de hand van het artikel in de post boven de mijne de configuratie van je server aanpassen.

[Fish]

je hebt zowiezo een debian weak key

http://www.networking4all...olution.nl&protocol=https


Ik neem aan dat ik op exchange.ictwebmail.nl moet verbinden ? aka webmail.ictwebmail.com
Bendeden staan de valide namen voor het certifikaat. logisch dat er bellen afgaan. ze komen niet overeen met de site die ik bezoek

DNS Name=ictwebmail.com
DNS Name=www.ictwebmail.com

[ Voor 6% gewijzigd door Fish op 23-04-2012 19:11 ]

[Kavaa]

fish schreef op maandag 23 april 2012 @ 19:08:
je hebt zowiezo een debian weak key

http://www.networking4all...olution.nl&protocol=https


Ik neem aan dat ik op exchange.ictwebmail.nl moet verbinden ? aka webmail.ictwebmail.com
Bendeden staan de valide namen voor het certifikaat. logisch dat er bellen afgaan. ze komen niet overeen met de site die ik bezoek

DNS Name=ictwebmail.com
DNS Name=www.ictwebmail.com

Ik doe eigenlijk alles op ictwebmail.com
De webclient heb ik een subdomein voor gemaakt zeg maar webmail.
Verder doe ik het gewoon met https://ictwebmail.com/owa
Enz. en outlook clients aanmelden doe ik met het root adres dat die gekregen heeft bij het aanmaken daarna heb ik [e-mail] als naam gegeven. of [e-mail]

[Oid]

maar je exchange subdomein heeft een verkeerd certificaat, daarom gaat het toch fout, dat kan je toch ook zien?

https://exchange.ictwebmail.com/owa = certificaat error
https://ictwebmail.com/owa = goed.

Security warning when you start Outlook 2007 and then connect to a mailbox that is hosted on a server that is running Exchange Server 2007 or Exchange Server 2010: "The name of the security certificate is invalid or does not match the name of the site" dit dus gebruiken zoals Don van Boven en Jazzy al aangeven....


volgens mij denk jij een wildcard te hebben aangeschaft, met *.ictwebmail.com maar dat is niet zo...!

[ Voor 9% gewijzigd door Oid op 23-04-2012 20:17 ]

[Verwijderd]

djkavaa schreef op maandag 23 april 2012 @ 14:48:
[...]


Domme vraag schaam maar waar zit dit: certificaat in AD kunnen publiceren als trusted.

Verschillende testjes gedraaid en alles blijkt toch op Certificaat.
Maar een Self signed is dan toch net zo goed zeg maar voor clients intern.
Het Certificaat wat ik nu heb werkt wel goed voor de webacces.

Je hoeft niet persé een SAN-certificaat te kopen, maar het maakt je leven wel een stuk makkelijker.
Er zijn verschillende manieren om hier omheen te werken.

Wat ik bijvoorbeeld geconfigureerd heb:

Webacces en Activesync: Gaat via een reverse-proxy met ondersteuning voor RPC over http(s) en SSL-offloading. Deze proxy heeft een certificaat (voor de externe hostname) van een algemeen vertrouwde CA met sterke versleuteling en sluist de verzoeken via LAN door naar de Exchange-server. De Exchange-server heeft op zijn beurt een self-signed certificaat (voor de interne hostname) met wat zwakkere versleuteling.

Interne Outlook-clients: Deze vertrouwen het self-signed certificaat, omdat een GPO zegt dat ze dat moeten doen.

Interne toegang tot webacces: De interne DNS-servers hosten ook het externe domein, dus de externe hostname wordt netjes vertaald naar het adres van de reverse proxy.

We hebben dit alleen zo gedaan, omdat de hele infrastructuur (DNS-servers die ook het externe domein hosten voor interne clients en de reverse proxy) er toch al lag.

volgens mij denk jij een wildcard te hebben aangeschaft, met *.ictwebmail.com maar dat is niet zo...!

Een wildcard certificaat i.c.m. Exchange is volgens mij niet zo'n goed idee. Tenminste: de laatste keer dat ik dit heb nagekeken, werd dit min of meer door elke certificaten-boer afgeraden i.v.m. de niet altijd zo goede ondersteuning van wildcard certificaten door sommige client devices. (+ dat een wildcard certificaat je interne hostname ook niet dekt, tenzij je intern exact dezelfde domeinnaam en hostname gebruikt als extern)

[ Voor 16% gewijzigd door Verwijderd op 23-04-2012 20:45 ]

[Jazzy]

Dat laatste is tegenwoordig wel veranderd. Die mobiele devices waren Windows Mobile 5 en die kom je (gelukkig ) nog maar weinig tegen.

Sterker nog, MIcrosoft adviseert tegenwoordig om een wildcard certificaat te gebruiken.

[Kavaa]

Inderdaad, ik heb het nu ongeveer werkend dat het voor me goed is het bovenstaande heeft toch wel geholpen volgens mij.

[Kavaa]

Heb het al opgelost.
zonder nieuw certificaat.

Wat heb ik gedaan:

In de management console van exchange het e-mail adres waarbij het adres was aangemaakt dus de (AD) domeinnaam terug gezet als Reply adres.
Daarna bij outlook alle profielen weg gedaan (op een testbakje natuurlijk)
Dan handmatig de server settings instellen dus het addres van de server opgeven en dan gewoon de username.
Dan op naam controleren doen.
Dan komt het root adres er te staan wat dus aangemaakt is in AD.
Als je het dan voltooit kun je outlook starten wachten tot alles binnen is.
En dan het adres weer terug zetten op het gewenste mailadres dat je als reply wilt.

Dan krijg ik geen meldingen meer.