remove .local from Exchange 2010 (SBS2011)

Just renew the SSL certificate and remove the .local certificate names.

All you usually need is mail.domain.com and autodiscover.domain.com in the certificate.

Once renewed and verified, download the certificate and import it to the exchange server:

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\SSL_Certificate_Name.crt -Encoding byte -ReadCount 0))

Once imported, you will have to fix the lack of private key using certutil -repairstore my "Serial Number" (http://support.microsoft.com/kb/889651)

Once that is repaired, enable the certificate:

Enable-ExchangeCertificate -Thumbprint "SSL Certificate Thumbprint" -Services IIS,POP,IMAP,SMTP  (You can copy/paste the thumbprint shown once you have run the Import-ExchangeCertificate command above)

Once enabled, run the following Exchange Management Shell  commands:

Set-AutodiscoverVirtualDirectory -Identity * -internalurl “https://mail.domain.com/autodiscover/autodiscover.xml”
Set-ClientAccessServer -Identity * -AutodiscoverServiceInternalUri “https://mail.domain.com/autodiscover/autodiscover.xml”
Set-webservicesvirtualdirectory -Identity * -internalurl “https://mail.domain.com/EWS/Exchange.asmx”
Set-oabvirtualdirectory -Identity * -internalurl “https://mail.domain.com/oab”
Set-owavirtualdirectory -Identity * -internalurl “https://mail.domain.com/owa”
Set-ecpvirtualdirectory -Identity * -internalurl “https://mail.domain.com/ecp”
Set-ActiveSyncVirtualDirectory -Identity * -InternalUrl "https://mail.domain.com/Microsoft-Server-ActiveSync"

That will get around the .local issue and mean you can continue to work happily without certificate errors.

Alan

Thanks for the info Alan however, this solution will not work.

the problem is;  godaddy (and/or every other certificate authority) will not renew/issue the SSL as long as the .local address is in the CSR...
So basically, this wont work.

Let me explain/clarify a little more:
Apparently, the Certificate Authority requirements have changed in order to make our internet browsing safer...  
Starting in 2015, SSL Certificates will no longer be issued OR renewed if they contain any internal IP addresses or intranet names - no exceptions.
source - https://cabforum.org/

Because of this new rule, I am unable to create/order the Certificate (or renew an existing) under my 5 year SSL license...

Companies will still issue an SSL if the request contains intranet names or internal IP addresses BUT - the SSL MUST expire in 2015 (meaning; nothing more than a one year certificate will be issued by anyone anymore).  
So... back to square one...

It's true, I could just 'not use my 5 year SSL license' and purchase a one year SSL that expires in 2015 - but... Once that SSL expires, I will be right back in this same boat again, and this time I will have no option of purchasing a certificate - period (as long as my CSR still contains that info)...

I would rather get this resolved now than punt it for a year :)

I cant imagine how many people this is going to effect next year...

Anyway - does anyone have any other ideas???
Or am I screwed and just need to rebuild the server???

They will renew it - I have a reseller account with them and do it regularly for all my customers servers.

Choose to renew the certificate, it will take you through the CSR page and there is a tick box to use the previous CSR to renew with.  Tick that and then remove the .local names and complete the renewal request.

Approve the domain names when the email arrives and then follow the rest of my instructions.

You can create a new CSR, but you don't need to.  You can use the existing one, modify it and then complete the process happily.

Alan:
I spent 2 hours on the phone with godaddy's techs trying to get them to renew/re-register the SSL for 5 years. Ultimately, I ended up talking to a supervisor who assured me they will not renew any SSL's that contain the .local address- for any date that exceeds June of 2015.
If I had purchased a 5 year SSL last year, I wouldn't have to worry about this "new rule" until that SSL expired. So, for those companies that purchased a long term SSL (previous to this rule change), they will not be affected by this new "rule" until their current SSL expires and they attempt to renew it.
Of course, they offered to sell me a one year SSL because that one would expire before June 2015. However, if I attempt to renew that (one year) SSL when it expires- in 2015, they would not renew it again without a new CSR - because they have to confirm that no .local addresses are being registered.
They were very clear that the .local would have to be resolved on my server(s) by mid 2015 or I would be unable to get or renew any SSL's.
I think the part that you're missing is; that I have already paid for a 5 year SSL license and any renewal or registration of a domain name would be for 5 years. Thus putting it over the 2015 deadline for this new rule and that's why they wont do it.

I also contacted Verisign to inquire about getting an SSL through them instead.
They basically told me the same thing. 'because my CSR contains a .local address, they will only give me a one year SSL and after that, they will not renew it or issue a new one without a new CSR - that does not contain the .local address.

Gilad:
Thanks for the suggestion! I didn't think of using exchange rather than SBS console.
That makes total sense. I will give that a shot and let you know how it goes.

Thanks!!!

Gilad:
Thanks for the suggestion. That worked perfectly!
The new CSR was created by exchange (rather than SBS Wizard) without internal IP addresses or domain names - and GoDaddy issued the SSL certificate for 5 years :)

I will need to do a little reconfiguring on some of my users outlook accounts, so they connect to the proper server address. And a couple changes to my DNS records to the autodiscover and OWA site(s) but, all 'n all, this worked great!!

Thanks Again

I've renewed a 3 year SSL using the same CSR as previously, but removing the .local names and it went just fine and the SSL certificate was renewed happily on my GoDaddy Reseller account.

I've done this numerous times.

Sure they won't renew a certificate with those names in - but you modify them before you ask for the renewal.

Everything I told you will work - because I have done it myself.  They just gave you bad information, or can't figure out how to remove existing names.

Glad it worked:)
thank you.

I do not mean  to hijack this post but would like to add in my recent experience which I believe is linked to the same issue - but with the added complication that my client's site no longer utilises the onsite Exchange2010 setup but was migrated to a Hosted Exchange provider last September/October.

I too recently had to renew an SSL certificate (multiple SANs) on behalf of this client who run an onsite SBS2011 server, but was initially foiled in my attempt to complete the renewal on the GoDaddy site due to the new restrictions on the '.Local' extension...

After discussions with their Tech' folks I could see no other option than to remove the '.Local' SAN from the Cert before completing the renewal process - once the Cert was available I followed the GoDaddy instructions on installing the renewed Cert (including running the 'Fix my Network' wizard) and for several days all appeared 'OK'.

However - I subsequently received a call from a user at that client to inform me that his Outlook2013 client was requesting his username/password and that even though he was entering them correctly - it was repeatedly asking for them. Once I could get access to the PC I noted that the username that was being prefilled was in fact the users local domain ID (which the user had not spotted) so when I changed this to the correct external domain username (their full email address) and supplied the password Outlook2013 seemed to be placated. ** At the time I have to admit that I felt that this may have been 'finger trouble' on the users behalf and so was not too concerned! **

However - a few days later a different user from the same client contacted me to say that they were facing the same issue and that eventhough they had attempted to alter the username to their external domain username and password - Outlook would not accept it! When I connected to that PC later that day I double checked that Outlook2013 would not accept the change to the external email address/password and indeed it would not. After a little more head scratching and research I decided that perhaps it was a'Credentials' issue - so I went into 'Control Panel>Credential Manager>Windows Credentials' and delted the entries relevant to Outlook. I then restarted the PC before opening the Outlook client and at that point was prompted for the username/password (which I entered very carefully!) and that user went back to working normally.

The following day another user called with the same issue - also unable to progress after entering their correct external username etc. When I accessed that PC I tried the same Windows credential 'cleansing' - but after the restart of Windows the Outlook client was still uncoperative! Further investigation showed that the server name in this user's mail profile (new profiles were created for all users during the migration to the Hosted Exchange provider in September/October had been working perfectly for more than 4 months) had reverted to point back at the onsite Exchange2010 server and not the hosted provider... I decided my best option now was to create another new Outlook profile for the user (following the same 'manual configuration' settings provided by the Hosted Exchange provider that I had follwed at the initial migration to avoid the SBS2011 Autodiscover issue) and after I had done so that user was able to go back to using Outlook normally.

So, to sum up - at this point in the saga I have recreated Outlook profiles for three users, re-entered the username/password for one user and removed/cleansed the Windows credentials for another....there are six further users (all users have Outlook2013) who so far have reported no issues what so ever and I am more than I a little confused!

As ever - I would appreciate the groups suggestions...