I currently have an SSL cert in place used for OWA access for internet access to OWA. We wnat to be able to acces OWA on our internal network. I have put a DNS entry inour internal DNS server that use the same name - webmail.mycompany.com. The users get a cert error that says there is a problem with this cert. I understand I need to update this with a third party cert but I have run into a snag. When somebody named our domain they used a .com in the root domain so the FQDN of our mail server is Mailserv1.telcom.zebco.com - we do not own zebco.com and the person that does wont let us use in as part of our SAN cert. The docs on using the UCC cert say you need to use the FQDN of the mail server. If I just want users on the internal network to access the mail server by going to https://mailserv1/owa if i just put that as an alternate name in the cert will it work? do I have to use the FQDN for the autodiscover name as well? Can I just use the mailserv.telcom.com for the autodiscover entry? Does any of this affect the cert I already have installed that is being used on our external access to OWA or does it stay the same as before?

Hi, As per my understanding You can use the same cert for internal and create DNS A Record for Mailserv1.telcom.zebco.com in you internal DNS or even you can create cname entry for your mail server. Regards. Shafaquat Ali. M.C.I.T.P Exchange 2007/2010, M.C.I.T.P Windows Server 2008, M.C.T.S OCS Server 2007 R2, Phone: +923008210320

I have an entry that points to the internal mail server ip address using the same name as our external OWA name - webmail.mycompany.com but when I go to this address while on our internal network I get the cert error. Is there something special I need to do with the DNS entry?

Hi, Is it true that: You have a third-party certificate for the external URL (webmail.mycompany.com) of OWA. The users from Internet can access the OWA without warning. But the users in your domain will get the warning when accessing the OWA by using the same URL webmail.mycompany.com? I think the problem is in the third-party certificate. It is probably binding with the public IP address of your OWA server. For internal accessing, it is safe to use a exchange self-signed certificate. By default, the self-signed certificate has the following certificated domain names: Mailserv1 (NetBIOS Name) Mailserv1.telcom.zebco.com (FQDN) You can run get-exchangecertificate |fl to view the detail of the certificates. Since it's a self-signed certificate, it cannot be trusted by other computers (User Trusting CA means that CA certificate held in user's Trusted CAs store). when the users try to access the https://Mailserv1/owa or https://Mailserv1.telcom.zebco.com/owa will get the warning like "There is a problem with this website's security certificate". They have to click the "Continue" to access the OWA. To prevent getting such warning, you need to store this self-signed certificate on the user's Trusted CA store: 1. Click View certificate button on the internet security warning message. 2. Click install certificate, click next. 3. Select “Place all certificate in the following store”, click Browse, then select “Trusted Root Certification Authorities”. Click Ok next. You can also use Using Group Policy to deploy this certificate for all users. More information, please refer the following article: http://technet.microsoft.com/en-us/library/cc770315(WS.10).aspx

Hello, Check the Event Viewer for Event ID 12014,12017 & 12018 and go through those Event Id and FQDN & according to that create a Self sign certificate for SMTP service. For example :-- New-ExchangeCertificate -DomainName server.domain.local,mail.domain.com -Services SMTP After creating the Self sign certificate for SMTP service & restart the Transport service. It will help you. EXCHANGE2010, MCSE, MCTS, MCSA MESSAGING, CCNA & GNIIT

You never have to have the FQDN of the server or the shortname on the Certificate. Autodiscover (when not domain joined or no access to AD such as outside the network) uses autodiscover.primarysmtpdomain.com for the FQDN and has no direct tie to the domain FQDN. In fact, what I would suggest is getting a certificate with the name you use for webmail such as webmail.domainyouown.com and autodiscover.primarysmtpdomainyouown.com. Users would have a primary SMTP address of primarysmtpdomainyouown.com. Now to ensure that you get no certiicate errors, you'll need to update all InternalURLs, ExternalURLs, and the AutodiscoverServiceInternalURI (which is used for domain joined autodiscover and when those domain joined users have access to AD). This will ensure, when Outlook connects, they will get no zebco.com responses for which the Outlook client could connect to). In my following blog article, I show you all of the services that need to be updated to prevent this certificate error from appearing: http://www.shudnow.net/2007/08/10/outlook-2007-certificate-error/MVP | MCSE:M | MCITP: Enterprise Messaging Administrator | MCTS: OCS + Voice Specialization | http://www.shudnow.net