As already mentioned in my previous post , I now have a test Exchange 2010 Server running on Azure. Now working in Mobile Device & Email Management space, my mobile devices needed to eventually connect to my Email Infrastructure to try out few scenarios.
Initially I thought that opening the https endpoint and enabling ActiveSync (for the Mailbox User) would suffice, but I was wrong. Needed to make few changes to the SSL bindings on the IIS and trust the certificate used for the same.
Let's get to it then.
When we create a new VM on Azure it gets the Certificate for the cloud service added to the machine's personal Cert store.
Below is a screenshot showing the same :
Now as mentioned in my previous post Exchange by default will create a self signed Certificate and bind it to the CAS Server for https communication.
This was also the case with Exchange Server VM, as it was by default for the https binding using the Cert issued to the VM , see below :
Now when I head over to https://testconnectivity.microsoft.com/ to test the EAS connectivity to my Exchange box:
it fails with the below Certificate error.
This is obvious as the hostname used is my Cloud Service public DNS name but the SSL binding is done with a Certificate issued to the machine name DEXEXCH.
Think of it like, I say to everyone my name is Dexter but when asked for proof of identity I show up a certificate which says my name is Deepak ;)
The fix is easy to bind the correct certificate (cloud service certificate) to the HTTPS traffic.
Let's do that using PowerShell.
Now you can verify the changes do reflect in the InetMgr :
Testting EAS Connectivity again threw me an error telling Service unavailable :
The problem seems to be only with the EAS endpoint as I was able to connect to the OWA endpoint (with Certificate errors ofcourse, it is a self signed cert) and see my emails.
Now after banging my head for a while on this and few efforts to connect my mobile device over EAS, one of my friend at office quickly helped me troubleshoot it.
It appears I forgot to add the Certificate issued to the cloud service (the one which I binded to the Exchange CAS server for https traffic ) to my Trusted Root CAs.
So let's do this using PowerShell too ;)
First let's get the cert from the Personal Store of the Machine and store it in a variable :
Now let's add this Certificate to the trusted root CA store :
After you have done this time to close the Stores which were opened and stored in the variable.
Let's head back to the Connectivity Analyzer and test our EAS connectivity.
Voila ! all done , now my Mobile devices can connect over EAS to my Email Infrastructure :)
Initially I thought that opening the https endpoint and enabling ActiveSync (for the Mailbox User) would suffice, but I was wrong. Needed to make few changes to the SSL bindings on the IIS and trust the certificate used for the same.
Let's get to it then.
When we create a new VM on Azure it gets the Certificate for the cloud service added to the machine's personal Cert store.
Below is a screenshot showing the same :
Now as mentioned in my previous post Exchange by default will create a self signed Certificate and bind it to the CAS Server for https communication.
This was also the case with Exchange Server VM, as it was by default for the https binding using the Cert issued to the VM , see below :
Now when I head over to https://testconnectivity.microsoft.com/ to test the EAS connectivity to my Exchange box:
it fails with the below Certificate error.
This is obvious as the hostname used is my Cloud Service public DNS name but the SSL binding is done with a Certificate issued to the machine name DEXEXCH.
Think of it like, I say to everyone my name is Dexter but when asked for proof of identity I show up a certificate which says my name is Deepak ;)
The fix is easy to bind the correct certificate (cloud service certificate) to the HTTPS traffic.
Let's do that using PowerShell.
001
002 003 004 005 006 007 008 |
#store the Certificate for the cloud service
$cert = Get-ChildItem -Path Cert:\LocalMachine\My | where {$_.Subject -like '*Cloudapp.net'} #Import the WebAdministration Module to manage IIS Import-Module webadministration #set the binding by using the IIS PSdrive Set-Item -Path IIS:\SSLBindings\0.0.0.0!443 -Value $cert |
Now you can verify the changes do reflect in the InetMgr :
Testting EAS Connectivity again threw me an error telling Service unavailable :
The problem seems to be only with the EAS endpoint as I was able to connect to the OWA endpoint (with Certificate errors ofcourse, it is a self signed cert) and see my emails.
Now after banging my head for a while on this and few efforts to connect my mobile device over EAS, one of my friend at office quickly helped me troubleshoot it.
It appears I forgot to add the Certificate issued to the cloud service (the one which I binded to the Exchange CAS server for https traffic ) to my Trusted Root CAs.
So let's do this using PowerShell too ;)
First let's get the cert from the Personal Store of the Machine and store it in a variable :
001
002 003 004 005 006 007 008 009 010 |
$SourceStoreScope = 'LocalMachine'
$SourceStorename = 'My' $SourceStore = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Store -ArgumentList $SourceStorename, $SourceStoreScope $SourceStore.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadOnly) $cert = $SourceStore.Certificates | Where-Object -FilterScript { $_.subject -like '*Cloudapp.net' } |
Now let's add this Certificate to the trusted root CA store :
001
002 003 004 005 006 007 |
$DestStoreScope = 'LocalMachine' $DestStoreName = 'root' $DestStore = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Store -ArgumentList $DestStoreName, $DestStoreScope $DestStore.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite) $DestStore.Add($cert) |
After you have done this time to close the Stores which were opened and stored in the variable.
001
002 003 |
$SourceStore.Close() $DestStore.Close() |
Let's head back to the Connectivity Analyzer and test our EAS connectivity.
Voila ! all done , now my Mobile devices can connect over EAS to my Email Infrastructure :)