[exchange] krijg RPC over HTTP niet werkend

[Galileo_Galilei]

Omdat de e-mail hosting op de huidige locatie niet langer voldoet heb ik een VPS gehuurd om eens te testen of dat een oplossing gaat zijn. Ik draai al een jaar of wat een exchange server in een intern netwerk maar de RPC direct over het net werkt niet. Vermoedelijk omdat allerlei firewalls die blokkeren maar ik wil sowieso RPC over HTTP laten tunnelen ivm veiligheid.

Dus ik heb netjes de guide gevolgd op:

http://www.msexchange.org...ver-2003-environment.html

Om de RPC client aan de praat te krijgen maar op dit moment werkt het nog niet, dat wil zeggen dat Outlook ingesteld op de RPC via HTTP geen verbinding kan krijgen. Heeft iemand een idee wat de volgende stappen zouden kunnen zijn waar ik naar moet kijken? Hoe belangrijk is het dat alle certificaten e.d. allemaal exact de juiste hostname vermelden? Omdat dit een test server is heb ik namelijk wel een beetje 'gerommeld' met hostnames, de ene geeft EX1 aan, de DNS heeft iets anders etc.

[Jazzy]

Zoals overal te lezen is, is het essentiëel dat je geen certificaatfouten hebt. Dus eerst testen met OWA en eventuelen problemen oplossen. Veel voorkomende fouten zijn dat de naam in de adresbalk (url) niet overeenkomt met de naam op het certificaat en dat de uitgever van het certificaat niet vertrouwd wordt, zoals bij een self signed certificaat.

Die problemen moet je eerst oplossen, pas dan gaat RPC over HTTPS werken.

Wat is een VPS eigenlijk?

[ Voor 3% gewijzigd door Jazzy op 03-07-2008 21:53 ]

[Galileo_Galilei]

Een VPS is een Virtual Private Server, een virtuele server dus. Ik heb een Windows VPS gehuurd zodat ik de exchange niet langer hier hoef te draaien, scheelt mij hardware management, scheelt mij hele hoge eisen aan internet verbindingen, uptime garantie management, stroom garanties en dat soort zaken.

Een exchange cluster is voor dit gebruik namelijk wat overdreven

Ik ga eens even al die hostnames goed zetten, wellicht lost dat het op inderdaad.

[ Voor 10% gewijzigd door Galileo_Galilei op 03-07-2008 22:10 ]

[Galileo_Galilei]

Die hostnames heeft wellicht wat gedaan, maar het probleem niet opgelost.

Ik heb er nu voor gezorgd dat:

* https://ex1.domein.ext verwijst via een a-record naar de exchange server
* de active directory kent als domein ex1.domein.ext
* het self signed certificaat op de Default Website is uitgegeven op ex1.domein.ext, door EX1 als certificate provider (de box zelf).
* OWA werkt na de prompt over het certificaat, het certificaat heb ik daarna geinstalleerd in IE
* De RPC poorten zijn 6001-6002 & 6004 gewijzigd in de registry als volgens de tutorial hierboven
* De firewall staat open voor die poorten vanaf het hele internet (zelfs met firewall uit doet hij het niet)

De foutmelding is dat "Outlook could not logon, make sure you're connected blah blah blah"

[Galileo_Galilei]

We komen steeds een stapje verder

Voorheen timede de verbinding simpelweg uit, nu heb ik in IIS de /RPC directory security alléén op basic authentication gezet en niet ook integrated windows. Dat zorgt er voor dat ik een prompt krijg voor een username/wachtwoord. Niet dat het werkt, maar het is alvast meer dan een time out.

Vervolgens de resource kit gedownload en volgens artikel How to use the RPC Ping utility to troubleshoot connectivity issues with the Exchange over the Internet feature in Outlook 2007 and in Outlook 2003 met de RPC ping geprobeerd wat het probleem was:

code:

rpcping -t ncacn_http -s ex1.domain.ext -o RpcProxy=ex1.domain.ext -P "username,ex1,*" -I "username,ex1,*" -H 2 -u 10 -a connect -F 3 -v 3 -E -R none

Output:
RPCPinging proxy server ex1.domain.ext with Echo Request Packet
Sending ping to server
Error 12175 returned in the WinHttpSendRequest.
Ping failed.

Wat volgens het artikel betekent dat:

The PRC Ping Utility test may have failed because the certificate is not trusted or because it does not trust the certificate and root authority. The server certificate subject from the RPC Proxy server does not match the one that is specified by -B.

The PRC Ping Utility test may have failed. The PRC Ping Utility test may have failed because a Mutual Authentication failed because the subject on the certificate did not match the expected subject. By default, the certificate subject should match the published fully qualified domain name (FQDN) of the RPC Proxy server.

Dus toch het certificaat. Wat moet ik nog meer doen om dat certifcaat goed te krijgen? Ik heb het oude verwijderd, het nieuwe uitgegeven aan ex1.domain.ext èn geïmporteerd in IE. Moet ik de hele certifcaat instantie verwijderen en opnieuw installeren?

[r0b]

Galileo_Galilei schreef op vrijdag 04 juli 2008 @ 00:54:
[...]

Dus toch het certificaat. Wat moet ik nog meer doen om dat certifcaat goed te krijgen? Ik heb het oude verwijderd, het nieuwe uitgegeven aan ex1.domain.ext èn geïmporteerd in IE. Moet ik de hele certifcaat instantie verwijderen en opnieuw installeren?

Kopen / je self-signed certificate toevoegen aan de lijst met vetrouwde CA's op zowel de server als de clients.
Zoals Jazzy in de eerste post schreef:

Jazzy schreef op donderdag 03 juli 2008 @ 21:52:
Veel voorkomende fouten zijn dat de naam in de adresbalk (url) niet overeenkomt met de naam op het certificaat en dat de uitgever van het certificaat niet vertrouwd wordt, zoals bij een self signed certificaat.

Zie ook: Troubleshooting RPC over HTTPS (Part 2)

quote: http://www.msexchange.org...RPC-over-HTTPS-Part2.html

Verifying the SSL Certificate and Trusts

In my experience, the number one cause of problems with RPC over HTTPS is caused by errors with the SSL certificate. In order for RPC over HTTPS to connect, you MUST have a valid SSL certificate from a trusted certification authority (CA).

To verify you have a valid SSL certificate installed, open up the IIS Manager MMC and drill down to Servername | Web Sites | Default Web Site. Open up the properties page of the Default Web Site and switch to the Directory Security tab. If you have a certificate installed, the View Certificate button will not be grayed out (if it is you need to install a certificate), press it and view the certificate. In this example (see Figure 1) the SSL certificate is not from a trusted CA and will not work for RPC over HTTPS connections unless the CA is added as a trusted root authority.

If you are not using a third party certificate, for example if you used an in house CA to create a self singed certificate, you will need to add the CA to the list of trusted CA’s on the server and all clients.

Of heb je dit al geprobeerd?

[Galileo_Galilei]

Thanks!

Op de server was alles goed ingesteld, kennelijk verleend de CA zichzelf automatisch een goedgekeurd kenmerk (logisch), maar op de client had ik het certificaat wel geinstalleerd via IE maar niet de root certificaat geinstalleerd als trusted CA.

Ik had dus wel ex1.domain.ext geinstalleerd als geverifieerd certificaat, maar omdat EX1 die het certificaat had uitgegeven nog niet vertrouwd werd bleef ik de meldingen krijgen. Om eerlijk te zijn is dit de eerste keer dat ik echt met een certificaat werk omdat zoals gezegd ik altijd inhouse heb gewerkt met exchange. Ik ben ook niet te beroerd om een certificaat te kopen, maar ik wil eerst zeker weten alles werkt zoals het werkt en ik niet een test server huur en een hoop kosten ga maken om daarna tot de conclusie te komen dat helaas pindakaas, het certificaat niet het goede was of de host niet lekker is waardoor ik weer helemaal nieuwe dingen moet kopen.

Maargoed, Outlook werkt nu over HTTPS, dus dat is al heel erg relaxt, nu moet ik nog de Windows Mobiles aan de praat krijgen. Ik zal er op letten dat ik ook daar een goed certificaat installeer