none
SSL Certificate Server Name is Incorrect because of external smarthost RRS feed

  • Question

  • I am running SBS 2003 and have a self-signed certificate.  We run OWA and have iPhones that connect up to the system, so I need certificates.  We also have an external smarthost that hosts our website and catches our mail.  To get around this we use a no-ip domain to point the devices to, OWA, etc.  I created a certificate using the no-ip domain name, and this worked for the longest time.  Recently I was unable to connect to our Exchange store public folders, but only on my Windows 7 machine.  Other users can connect without issue.  I can also connect without issue via Remote Desktop or OWA.  When I try to right click on the public folders on the server itself using Exchange System Manager I get the error indicated in the subject.

    I've looked at solutions that involve removing the certificate from the Exadmin folder, but I don't even have those checkboxes checked, so they don't apply.  I even went as far as stopping the IIS, and explicitly adding myself to the public folders directory with full permissions, and then starting IIS back up.  This didn't seem to have any effect.

    If I click on the public folder from my machine it appears to process, but nothing ever displays on the screen. If I try to drop an email onto the folder it says I don't have permissions - which is untrue because according to the other machines I'm the folder owner.

    • Edited by Tony NSLA Tuesday, May 15, 2012 5:18 PM
    • Changed type Xiu Zhang Thursday, May 17, 2012 2:51 AM Q&A
    Tuesday, May 15, 2012 5:16 PM

Answers

  • Here's the answer.  At the very end you will need to restart services that will temporarily interrupt communications with the Exchange server, so probably not best to implement in the middle of the day.

    The SSL certificate server name is incorrect. ID no: c103b404
    May 6, 2008 by Paul Morgan-Roach 42 Comments

    This error occurs when trying to view Public Folders in the Exchange System manager when he SSL certificate name differs between the FQDN and the local server name.  The Exchange System Manager will not allow you to view the public folders as it believes the folder name to be incorrect.

    This can be resolved using a front-end, back-end scenario, but what if you are stuck with a single Exchange server (ie. SBS) in your environment?

    On following a few blogs and sites, the solution seems to be to remove SSL requirement for that particular folder in the IIS Manager.  This didn’t work for me though – and I found a lot of people out there with unresoved issues on Experts Exchange etc.

    The end solution was to use the ADSIEdit utility to manually stop the Exchange System Manager from using SSL.

    The steps are as follows:

    1) Install the ADSIEdit Utility (one of the Windows Server 2003 Support tools) from your SBS2003 CD (CD2) using suptools.msi

    2) Run a Microsoft Management console (Start->Run->MMC)

    3) Open the ADSIedit.msc (browse to the Support Tools folder)

    4) Browse through to

    Configuration > Services >  Microsoft Exchange > Domain Name > Administrative Groups >     First Administrative Group > Servers > Servername > Protocols > HTTP > 1 > Exadmin

    5) Right click msExchSecureBindings, and click Properties

    6) Highlight :443: and click Remove

    7) Click OK

    Restart the Exchange System Attendant and the IIS Admin service

    Exchange system manager will now no longer try to use SSL when connecting to the service

                  
    • Marked as answer by Tony NSLA Tuesday, May 29, 2012 11:02 AM
    Tuesday, May 29, 2012 11:02 AM

All replies

  • None of the services you describe would have to go through an external smart host since none of those use SMTP, so I believe you are mistakenly confusing the two.

    Please post the complete and unedited error message you are getting, and the steps you take to get to that point.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Tuesday, May 15, 2012 5:23 PM
    Moderator
  • Any update?

    Xiu Zhang

    TechNet Community Support

    Thursday, May 17, 2012 6:29 AM
  • Exchange system manager, navigate to public folders, right click on the public folder I want to check permissions on.

    Exchange System Manager

    The SSL certificate name is incorrect.

    ID no: c103b404

    Exchange System Manager

    My mail and web site go to an external smart host.  The domain is www.realdomain.ca.  My internal host is realdomain.myvnc.com.  *not real names, but real format*

    My certificate is made out to realdomain.myvnc.com.  I need the certificate for iPhone email and OWA, but can't use my actual domain name since www.realdomain.ca resides outside my network and this causes issues.

    Thursday, May 17, 2012 10:09 AM
  • Does this help?

    http://support.microsoft.com/kb/324345


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Friday, May 18, 2012 2:09 AM
    Moderator
  • This is where the problem comes in.  Our internal name is realcompany.lan.  Our external name is realcompany.myvnc.com.  The certificate has to be for realcompany.myvnc.com.  The rest of the article doesn't apply, since the requirement for a certificate isn't turned on for the EXADMIN site.

    This change is recent - this server and certificate has been working for YEARS with this configuration, and it's only been recently that it's stopped working.

    Friday, May 18, 2012 12:14 PM
  • Nobody?
    Friday, May 25, 2012 4:11 PM
  • I recommend you implement a split-brain DNS and use your public domain for all such services.  It just works better, is easier to implement, especially for certificates, and it's easier on your users to understand.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Friday, May 25, 2012 6:30 PM
    Moderator
  • There's nothing for my users to understand, but I'll research the split brain scenario further.  I'm just curious as to why this would have self-signed certificate worked fine for years and then suddenly stopped working.  Everything else works fine, so I don't want to mess up an otherwise perfectly functioning live server.
    Friday, May 25, 2012 6:35 PM
  • If your self-signed certificate has worked, then it's a miracle.  Those are poor for anything in Exchange except for SMTP.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Friday, May 25, 2012 6:51 PM
    Moderator
  • If your self-signed certificate has worked, then it's a miracle.  Those are poor for anything in Exchange except for SMTP.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    I only used it for Outlook Web Access and iPhones.  I just let everyone know the error message about the certificate wasn't important, and to carry on.  It was definitely a pain to get working, and I don't want to have to mess with everyone's phones again to change the whole system.  Anyhow, I'll read up on split brain DNS and see what's involved and go from there.
    Friday, May 25, 2012 6:53 PM
  • It just means to create a DNS zone for company.com internally and map the names to internal addresses.  That way everyone uses the same hostnames and URLs whether they are inside or outside.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Friday, May 25, 2012 7:00 PM
    Moderator
  • On Fri, 25 May 2012 19:00:44 +0000, Ed Crowley wrote:
     
    >It just means to create a DNS zone for company.com internally and map the names to internal addresses. That way everyone uses the same hostnames and URLs whether they are inside or outside.
     
    Amen. The whole .local or realdomain.myvnc.com (inside), and .com or
    ..ca (outside) thing will make you bonkers -- especially if you have
    mobile users.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Friday, May 25, 2012 9:04 PM
  • I reviewed the whole split brain thing and it won't work in my situation. The only traffic that goes directly to my internal server is a secured web portal for users to access from both inside and outside the LAN and iPhones.  My company's www. and mail. are a different name and are on the ISP's server.  This prevents me from using my real domain info internally.  This would probably be a lot easier if I could use real machine/domain names - would that present a major security risk?  The information could be easily scanned from the net and found in our CIRA site info.

    Monday, May 28, 2012 2:52 PM
  • That doesn't prevent you at all.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Monday, May 28, 2012 8:39 PM
    Moderator
  • Here's the answer.  At the very end you will need to restart services that will temporarily interrupt communications with the Exchange server, so probably not best to implement in the middle of the day.

    The SSL certificate server name is incorrect. ID no: c103b404
    May 6, 2008 by Paul Morgan-Roach 42 Comments

    This error occurs when trying to view Public Folders in the Exchange System manager when he SSL certificate name differs between the FQDN and the local server name.  The Exchange System Manager will not allow you to view the public folders as it believes the folder name to be incorrect.

    This can be resolved using a front-end, back-end scenario, but what if you are stuck with a single Exchange server (ie. SBS) in your environment?

    On following a few blogs and sites, the solution seems to be to remove SSL requirement for that particular folder in the IIS Manager.  This didn’t work for me though – and I found a lot of people out there with unresoved issues on Experts Exchange etc.

    The end solution was to use the ADSIEdit utility to manually stop the Exchange System Manager from using SSL.

    The steps are as follows:

    1) Install the ADSIEdit Utility (one of the Windows Server 2003 Support tools) from your SBS2003 CD (CD2) using suptools.msi

    2) Run a Microsoft Management console (Start->Run->MMC)

    3) Open the ADSIedit.msc (browse to the Support Tools folder)

    4) Browse through to

    Configuration > Services >  Microsoft Exchange > Domain Name > Administrative Groups >     First Administrative Group > Servers > Servername > Protocols > HTTP > 1 > Exadmin

    5) Right click msExchSecureBindings, and click Properties

    6) Highlight :443: and click Remove

    7) Click OK

    Restart the Exchange System Attendant and the IIS Admin service

    Exchange system manager will now no longer try to use SSL when connecting to the service

                  
    • Marked as answer by Tony NSLA Tuesday, May 29, 2012 11:02 AM
    Tuesday, May 29, 2012 11:02 AM