I’ve been receiving more and more questions about SSL certificates from people who find themselves in a situation where they can’t get the certificates they need from a public certificate authority.
The scenarios tend to be either:
- they are using a DNS namespace that they do not actually own the domain name for
- they are using names that are no longer accepted by commercial certificate authorities due to changes in the rules for issuing certificates
Let’s take a quick look at an example of each of those scenarios.
Using a DNS Namespace You Do Not Own
I’ve seen this scenario occur a few different ways. In some cases the company uses something they thought was harmless and generic for their internal namespace, such as office.net, and then a public namespace of company.com. However, someone else already owns the office.net domain, so they are not able to register it.
In other cases the company used company.net internally, and company.com externally, but simply forgets to register company.net and someone else came along and registered it afterwards.
In either case because you are not the owner of the domain a public certificate authority will not issue you an SSL certificate for that domain.
Using a Name No Longer Valid Under New Rules
In this scenario a company uses an invalid namespace for their internal domain name, eg company.local, or uses short names such as webmail or even IP addresses for internal access to certain services, and wants to include those invalid names, short names, or IP addresses in their SSL certificate.
In 2012 the rules for SSL certificate issuance have changed. From Digicert:
The CA/Browser Forum, a collaborative effort between Certificate Authorities (companies like DigiCert that issue certificates) and Web Browsers (companies like Mozilla or Microsoft that manage trust on a CA level), has introduced new Baseline Requirements for certificate issuance.
As part of these new requirements, Certificate Authorities must phase out the issuance of certificates issued to either Internal Server Names or a Reserved IP Address by October 2016. Specifically, CAs cannot issue certificates to these internal names with expiration dates after November 1, 2015…
Essentially, this change in SSL standards will make it impossible to obtain a publicly trusted certificate for any host name that cannot be externally verified as owned by the organization that is requesting the certificate.
Avoiding the Problem at Design Phase
For those who get the opportunity to design new Active Directory and Exchange environments from scratch the best advice is to avoid using an internal namespace that the company doesn’t own.
I recently saw a new AD/Exchange design that proposed a .local namespace and gave them that same advice. Even though it may have been possible for them to be issued an SSL certificate with .local names in it today, when that certificate expires it may not be possible to renew it.
Better to avoid the problem before the first domain controller is even promoted.
For more information see Avoiding Server Names in SSL Certificates.
Resolving the Problem for Existing Organizations
For those who are already in the situation where they will not meet the new requirements for certificate issuance there are a few approaches that can be taken.
Renaming/Migrating Active Directory Domains
Digicert published some brief guidance on renaming Active Directory to resolve the issue. They also suggest considering a migration to a new domain that has a compliant namespace.
Personally I would not be keen to undertake either of those unless absolutely necessary. This is really a decision for businesses to make based on the number of things in their environment that would be impacted by such a change.
Renaming your entire Active Directory isn’t necessary when you can run your Exchange namespaces on a different domain anyway. Just because your Active Directory is domain.local doesn’t mean you need to use that namespace for Exchange services. For more information see Avoiding Server Names in SSL Certificates.
Using a Mix of Private and Public Certificate Authorities
More and more organizations are running their own internal PKI these days due to the increasing number of products that use SSL in their communication channels (not just Exchange, but also Lync and the System Centre family).
This makes it possible to meet your SSL requirements for non-compliant names using your private CA. The challenge though is to combine this with public CA certificates so that non-domain members (such as mobile devices) will continue to work correctly for external access.
Note that the examples below were created in the Exchange 2007/2010 era, before Exchange 2013 was released. Also note that adding multiple websites and virtual directories is going to increase the complexity of your environment, making it more difficult to maintain and troubleshoot.
Example 1
In this example you could use a private CA to issue the SSL certificate for the .local names, and a public CA for the public names (eg webmail.company.com). The public cert is bound to the ISA/TMG for external access, while the private cert is bound to the Exchange server itself. The ISA/TMG bridges the traffic between the two, with external clients unaware of the internal namespace.
Note: this is also a solution for those who don’t want the public-facing cert to have internal server names on it.
Example #2
Another approach is to create a second IIS website on the Exchange server (Client Access server) and create additional virtual directories for the external services such as OWA. You can then bind the public CA issued certificate to that IIS website, and the private CA issued certificate to the Default Website.
When combined with split DNS this allows internal and external clients to connect to services such as OWA by using the same name.
If an ISA/TMG server is also involved it would also have the public CA cert bound to it, and would publish external access to the second IIS website.
Summary
It is difficult to cover every scenario in an article such as this because there will be a lot of variables depending on the specific environment. Before you deploy any solution I do recommend that you thoroughly test it first in a test environment, or at the very least have a clear rollback plan if something unexpected occurs.
Hopefully though you can see that there are options that exist to allow us to work through these changes to the rules for SSL certificate issuance, without necessarily having to make a major architectural change to our AD/Exchange.
Further reading:
Pingback: Godaddy Ssl Certificate Faq – Cyber Sun
Hi,
Our internal AD is “ourcompany.local” , external DNS is “ourompany.com”.
We run slit-DNS and map internal and external URLs to “webmail.ourcompany.com”
We are currently using a wildcard certificate for *.ourcompany.com with the EXPR Outlook Providers set to “msstd:*.ourcompany.com”
Can we replace the wildcard with a SAN and update the EXPR Outlook provider to “msstd:webmail.ourcompany.com” ?
Cheers
Hi Paul,
Thank You for the information, We are using 2013 in a separate AD environment only for exchange and all clients are connected via either webmail or OAW (no local users). Now we are receiving certificate expiration notice . Our current certificate includes .local domain names and is going to invalid from 1st of Nov. 2015. As we are not using the exchange locally is it necessary to create the local CA certificates ? or we can just remove the non FQDN from the certificate and reissue. Any other settings need to be changed in exchange.
Exchange 2013 (847.32)
Server 2012
5 years ago we deployed Cisco WaaS between sites.
To have compression to and from Exchange, we disabled (via GPO) the encryption requirement. That was when we were on 2003, and wasn’t an issue when we migrated to 2010.
My issues I have had since migrating to 2013 all seem to be related to the fact that RPC encryption was disabled.
I have since disabled the WaaS between our stores (more harm than good even with Cisco Engineers engaged) and I have removed the GPO forcing the no encryption via RPC over HTTP.
Problems have disappeared. Yay.
But, is it really required (internally for Outlook clients) using OA?
Thanks as always for your insight – Thanks to you and your guides I was at least able to know my server WAS configured right.
If I hadn’t had a reason to be modifying our GPO – I might still have the manual configuration nightmares.
Love this game
Pingback: Active Directory Domain Naming Best Practices - Oxford SBS Guy
Hi Paul,
I am in the process of reissuing our exchange certificate without internal names (like suggested in that Digicert blog).
https://blog.digicert.com/exchange-replacing-internal-names-certificates-part-2/#prerequisites
Is it correct that I have to change the Client Access Array’s URL to match the public name in the certificate? I’m not a 100% sure if it is necessary.
Thank you very much for your time.
Joerg
The CAS Array name should not be on the SSL cert, and it should be different to any of the URLs used for HTTPS services like OWA, Outlook Anywhere etc.
Well, an interesting Sunday afternoon [grin]. The changeover seems to have gone reasonably well. Most of the issues I had centered around tweaking the settings for TMG, especially intermediate certs.
However, I’m still facing an issue where internal users are getting a certificate warning. I’m sure I missed something, but I don’t now what. The one thing I noticed was that, on my servers, there doesn’t appear to be a parameter for “InternalHostName” on the Outlook Anywhere setup.
The check for the Autoconfiguration setting returns all the right values on an Outlook connection (ctrl-right-click “Test Email AutoConfiguration”, but the Connection Status still shows “mail.localdomain.local” and “ex2.localdomain.local” as the connection points.
Below is the result of all the “get” commands following the changeover, edited to remove the real domain name. Any thoughts would be gratefully received.
[PS] C:Windowssystem32>Get-OutlookAnywhere | Select Server,ExternalHostname,Internalhostname
Server ExternalHostname Internalhostname
—— —————- —————-
EX2 mail.publicdomain.com
EX1 mail.publicdomain.com
[PS] C:Windowssystem32>Get-OwaVirtualDirectory | Select Server,ExternalURL,InternalURL | fl
Server : EX1
ExternalUrl : https://mail.publicdomain.com/owa
InternalUrl : https://mail.publicdomain.com/owa
Server : EX2
ExternalUrl : https://mail.publicdomain.com/owa
InternalUrl : https://mail.publicdomain.com/owa
[PS] C:Windowssystem32>Get-ActiveSyncVirtualDirectory | select server,externalurl,internalurl | fl
Server : EX1
ExternalUrl : https://mail.publicdomain.com/Microsoft-Server-ActiveSync
InternalUrl : https://mail.publicdomain.com/Microsoft-Server-ActiveSync
Server : EX2
ExternalUrl : https://mail.publicdomain.com/Microsoft-Server-ActiveSync
InternalUrl : https://mail.publicdomain.com/Microsoft-Server-ActiveSync
[PS] C:Windowssystem32>Get-WebServicesVirtualDirectory | Select Server,ExternalURL,InternalURL | fl
Server : EX2
ExternalUrl : https://mail.publicdomain.com/EWS/Exchange.asmx
InternalUrl : https://mail.publicdomain.com/EWS/Exchange.asmx
Server : EX1
ExternalUrl : https://mail.publicdomain.com/EWS/Exchange.asmx
InternalUrl : https://mail.publicdomain.com/EWS/Exchange.asmx
[PS] C:Windowssystem32>Get-OabVirtualDirectory | Select Server,ExternalURL,InternalURL | fl
Server : EX2
ExternalUrl : https://mail.publicdomain.com/OAB
InternalUrl : https://mail.publicdomain.com/OAB
Server : EX1
ExternalUrl : https://mail.publicdomain.com/OAB
InternalUrl : https://mail.publicdomain.com/OAB
[PS] C:Windowssystem32>Get-ClientAccessServer | Select Name,AutoDiscoverServiceInternalURI
Name AutoDiscoverServiceInternalUri
—- ——————————
EX2 https://mail.publicdomain.com/Autodiscover/Autodiscover.xml
EX1 https://mail.publicdomain.com/Autodiscover/Autodiscover.xml
[PS] C:Windowssystem32>
Hello, Paul. With your permission, I’ll keep asking more stupid questions (in hopes I’ll start to wrap my head around some of this [le sigh])
I have an Exchange 2010 environment, set up long ago (by a previous admin) in the then traditional manner: 2 servers in a DAG
EX1.domain.local
EX2.domain.local.
Current SAN cert – expiring in about 3 weeks – has those two names, plus
mail.publicdomain1.com
autodiscover.publicdomain1.com
autodiscover.publicdomain2.com
Outside users connect via TMG at mail.publicdomain1.com
Based on what I’m reading here and elsewhere, I believe I want to:
o Get a new SAN cert from a public CA for just the Public names
o Gen a SAN cert on my internal (domain) CA for the Private names
o Apply the public cert to the TMG
o Apply the private cert to the two Exchange servers
I’m sure I’m missing something there, but not sure what. Is there anything special I need to do to make sure TMG trusts the certificate issued by my internal CA?
Also, we *were* planning to retire TMG, as OA/OWA/ActiveSync is pretty much all it’s doing now. If we want to do that at some point, do you think we can do the same SSL proxy using an IIS server configured for Reverse Proxy?
Read this article and consider changing your Exchange namespaces so you don’t have this problem now or ever again. The article applies to Exchange 2010 as well.
https://www.practical365.com/avoiding-exchange-2013-server-names-ssl-certificates/
Thanks. Reading and absorbing (slowly). Two concerns, maybe you can address:
1) I assume this requires Exchange 2010 SP3. If so, I have to plan and apply that update – previous admin left it at SP1. I want to do that anyway. This would just impose a time frame limitation.
2) In the “Testing” section at the end, you say “On a client with no existing Outlook profile launch Outlook and confirm that the profile is configured automatically and without any certificate warnings.” Does this mean that existing Outlook profiles will need to be re-created? If so, that’s a huge political problem. For other reasons, we just had to recreate a couple hundred user profiles, so doing it again right now will not go down well.
1) No.
2) No, it’s just a test of the end to end autodiscover/autoconfig. No reason I can think of why existing users would need to have profiles recreated.
Hi Paul,
I need your help to resolve this mystery
I have an internal domain name (xyz.local) and an external domain name (abc.com).
I have 2 CAS and 2 Mailbox server (exchange 2010)
I have a wildcard cert on my TMG to facilitate external connections to OWA, EAS, etc., but I also have a Local SAN cert genrated from one of my CAS box that contains internal server references with mutiple names.
I am using Network Load Balancing Manager which is installed on one of CAS server with cluster internal domain name outlook.xyz.local
Inside this cluster it has 2 CAS Server with their own ip assigned to it for load balance and from each server it has cluster ip as seconday ip
When outlook open it connects to : outlook.xyz.local (Automatically pickup this name)
OultookAnywhere point to: webmail.abc.com
I utilize split-DNS, so my internal DNS server handles both the xyz.local and abc.com domain for users connecting internally.
Inside the DNS Server i have extneral DNS records (webmail.abc.com and outlook.abc.com) both point to same Cluster IP
I can access web owa and other without any issue
According to your example 1
I created new local san cert from one of the CAS server with mutiple name like
outlook.xyz.local
CAS-1.xyz.loccal
CAS-2.xyz.local
webmail.abc.com
autodiscover.abc.com
abc.com
and assigned to both CAS server (personal – certificate) with services (IMAP,POP,IIS,SMTP)
From CAS-1 Server
Exchange OWA + ECP + Active Sync + OAB Current Settigs are Internal Points to : https://cas-1.xyz.local/owa
and External Point to : https://webmail.abc.com/owa
From CAS-2 Server
Exchange OWA + ECP + Active Sync + OAB Current Settigs are Internal Points to : https://cas-2.xyz.local/owa
and External Point to : https://webmail.abc.com/owa
other settings as below
Get-ClientAccessServer |fl identity,autodiscoverserviceinternaluri
Identity : CAS-1
AutoDiscoverServiceInternalUri : https://webmail.abc.com/Autodiscover/Autodiscover.xml
Identity : CAS-2
AutoDiscoverServiceInternalUri : https://webmail.abc.com/Autodiscover/Autodiscover.xml
When user open outlook 2013 When they are in internal network. They getting security alert “CAS-1.xyz.local The name on the security certificate is invalid or does not match the name of the site”
Could you please advise what i am missing plz
Thanks for your help in advance
Hi Paul,
Thanks for providing this solution for internal and external network
In My Scenario I have 2 CAS server.
example CAS-A CAS-B
CAS-A server has configured with network load balancing manager with local name mail.local which point to both cas server IP for load balance and provide HA for exchange 2010.
I have wildcard certificate for external web access -which is working fine (only holding external domain name) and I also have TMG
I have local DNS entry for external mail and internal mail server to connect locally when user is on campus.
According to your guide in Example#1
I have assign external wildcard certificate to TMG -for owa access externally
Internal Network:
From CAS-A server I have created exchange certificate via powershell using private CA (local/cert) which includes external name + autodiscover + CAS-A+CAS-B + FQDN + mail.local and assigned to SMTP, POP, IMAP services and assigned external certi wild card cert to to IIS and SMTP
I have also assigned same certificate to CAS-B server and imported to trusted root and private location on both CAS server
Issue: when I open outlook 2013 after while getting security alert
“CAS-B.local
the name on the security certificate is invalid or does not match the name of the site”
Is this error mean I have to generate individual certificate from each CAS server and assigned to it’s own exchange services (sorry for confusion I mean 2 certi from 2 different server with same fqdn and name and assigned to it’s own exchange services)
Could you please help me with this
Thanks for your help in advance
Abhi
The older certificate would work fine as it supports split DNS. The existing certificate that supports split DNS would not work after December 2015. All admin who have not had issues with old certificate should check with certificate provider about new certificates rule and validity.
Would it help to create internal zone with public DNS name and avoid CA installation
Yes.
Hi Paul,
Most of the users who said they figured out the fix on split DNS might still be using old type of certificate. Those certificate would expire after 2015 December and would not resolve split DNS for internal name.
No for CA solution you have recommended for internal cert would require installation for two servers one for Root CA (shut down) and issuing CA. Would it work with just SSL cert, if cert are deployed to all system with group policy? If not second OWA binding might be a better solution if it works for same address.
Pingback: Active Directory Domain Naming Best Practices | Oxford SBS Guy
Hi Paul,
I am in the process of migrating Exchange 2007 to 2013. I will be installing Exch 2013 next week to get a certificate ruquest from our agency. This will take a week. Does the initial Exch 2013 changes any of my OWA or URL (internal and external) before I manually configure them. In other words, my intent is to only install Exchange 2013 (without any additional configuration) so I can do a certificate request. Once I get my certificate back from my agency, I will then go through the hoops of pointing my URL to my legacy name, DNS cname, and configuring my virtual directories. I understand when you first install Exchange 2013, it creates a self-signing certificate. Does it also redirects my webmail URL to my 2013 Exchange or will it default to Exchange 2007 OWA until I change this manually in 2013?
In a nutshell, will my webmail from 2007 be affected by installing exchange 2013 without any url configurations? Do I need a certificate readily available or can it wait a week before redirecting my URL from 2013 to 2007?
Hi Paul,
I reread your article that you linked to and i was not understanding one part. I got it figured out and I see what you were saying about split dns. My exchange 2013 certificate is working perfectly thanks to me reading your article’s again. I am only using the one public certificate and exchange is working great.
Thank you,
Jeff
Hi Paul,
Thank you for all of your exchange 2010 to 2013 migration guides they were very helpful in my migration. However, i am having one issue with the certificates and i still can not seem to get it to work.
I am hoping you can help and here is my setup below.
We have our main adsite test.corp (no i was not the one that set this up.) We also have subdomains test.fr, test.com etc.
We are in Co-Exsitance right now and I moved my mailbox to 2013 and I am getting certificate issues. I have a kemp LM2200 with 2 cas servers and 2 mailbox servers. What I am trying to do is use the public cert on the kemp and the internal cert on the cas servers but something is going wrong. The public cert contains autodiscover.test.com and webmail.test.com. The private cert(from our private certificate authority) has the fully qualified domain of the server in it but only the server name for its own server so test-cas-1.test.corp. the 2nd cas server has test.cas-2.test.corp. when i assign these certificates I cannot get through via webmail and my outlook just keeps trying to connect or ask for my password. This is the only thing that is not working. when i just use the public cert on the cas servers i get the cert error about the internal names not existing on the public(makes sense.)
You should be using the same cert on the LB and both CAS really.
All the CAS in the site should have the same namespaces configured, and those namespaces should be on the cert.
https://www.practical365.com/avoiding-exchange-2013-server-names-ssl-certificates/
I understand that but the only way right now i can do this that i feel would work with the least amount of impact is either example 1 or example 2 of this current link. our ad site is test.corp which can not be put into the public certificate since it is internal. we our a world wide company so we have .com, .fr, .es, .it etc. we also have exchange servers in .fr. so i was hoping If i understand example 1 correctly we can put the public cert on the kemp loadmaster and than use the inter private cert on the exchange servers for internal. or would i be better off creating 2 iis sites and having the public cert on the kemp and the default of exchange and than the internal cert on the 2nd iis and point internal users to the 2nd iis site.
thank you,
Jeff
I don’t recommend option 2 for Exchange 2013 environments. That article pre-dates Exchange 2013’s release. The CAS architecture has changed.
If “webmail.test.com” is what your users type into their browser to connect to OWA, then that is what should be configured on the OWA virtual directory of all the CAS in that site, and that is what should also be on the SSL cert. The same cert should be used on all of the CAS that are configured with that namespace.
The simplest configuration is to follow the recommended practice, which is to not use server FQDNs on CAS URLs, and not use server FQDNs on SSL certs, and to use the same cert across multiple CAS.
Everything you’re considering as a way to avoid doing that only adds complexity. Complexity is the enemy of supportability. It complicates troubleshooting, and makes the environment more difficult to manage overall.
Hi all,
I am in the same boat as many. I have an internal domain name (xyz.local) and an external domain name (abc.com).
I have a wildcard cert on my TMG to facilitate external connections to OWA, EAS, etc., but I also have a SAN cert on my CAS box that contains internal server references.
I utilize split-DNS, so my internal DNS server handles both the xyz.local and abc.com domain for users connecting internally.
My current SAN certificate will expire soon. I have the new SAN cert ready to go, minus the internal server names (ie. exchange.xyz.local).
Assuming that I have the correct references setup in my split-DNS zone, isn’t there some configuration changes that need to be done on the CAS and/or active directory to tell the clients (Outlook) to connect using the “external FQDN” as opposed to the internal exchange.xyz.local name?
Currently, when a user connects via Outlook the connection settings look for the internal server name (ie. exchange.xyz.local). That internal server name is currently on my soon to expire SAN cert, but will not be included on my new cert.
Will my Outlook clients have a fit when suddenly the internal server name is no longer on the SAN cert?
I just want to make sure that I don’t disrupt my internal Outlook clients when assigning services to the new certificate.
If you take a name off the cert and clients are still making HTTPS connections to that name then yes, they will “have a fit”.
You don’t need to use local namespaces or server FQDNs in your Exchange URLs. It is explained more in this article:
https://www.practical365.com/avoiding-exchange-2013-server-names-ssl-certificates/
We finally hit the time where Go daddy does not accpet .local on their Cert Requests.
We have no problem with the external names because OWA, RPC, HTTS, and Active sync use mail.ourdomain.com structure.
I have only the issue with the Outlook clients. They prompt that comes now, after I installed a cert without .local. Our internal domain has this structure mydoamin.local and of courser all PCs and servers names have the domain.local.
Outlook is looking for myxchserver.domain.local
I understand that I could use option 1 from your post. I like that approach.
I have already installed the Godaddy cert.
After I install the CA in my domain, how do I tell XCH to use the internal CA just for the outlook clients?
Is it the service SMTP assignment?
Is it a bidding on the ISS in Exchange server?
I thank you beforehand for your assistance.
We finally hit the time where Go daddy does not accpe.t. .local on their Cert Requests.
We have no problem with the external names because OWA, RPC, HTTS, Active sync use mail.ourdomain.com structure.
I have only the issue with the Outlook clients. They prompt that comes now after I installed a cert without .local . Out internal domain has this structure mydoamin.local and of courser all PCs and servers names have the domain.local.
Outlook is looking for myxchserver.domain.local
I understand that I could use option 1 from your post. I like that approach.
I have already installed the Godaddy cert.
After I install the CA in my domain, how do I tell XCH to use the internal CA just for the outlook clients?
Is it the service SMTP assignment?
Is it a bidding on the ISS in Exchange server?
I thank you beforehand for your assistance.
Pingback: Fix Unifiedmessaging.js Errors - Windows XP, Vista, 7 & 8
Pingback: car hire
So with that in mind would I create two certificate requests? One to be deployed on the reverse proxy that would be from Thawte and have our Internet facing names:
ccmail.clark.wa.gov
autodiscover.clark.wa.gov
and then another one that would from our internal CA and have:
cas.clark.root.local
esxvm400.clark.root.local
esxvm401.clark.root.local
I assume that I would give the certificate that I receive back from Thawte to my reverse proxy guy to add on the reverse proxy.
My question though is how do I assign these? Do I assign the commercial/Internet compliant certificate to SMTP and then the internal CA cert to IIS, IMAP and POP?
I guess that I am confused as to how to assign these and what needs to be included in each. Would I need to include the external clark.wa.gov names in the SAN for my self signed one as well?
Thanks-
Pingback: typical garage
Pingback: official website
Pingback: sarswatichandra
Pingback: game hacksd
Pingback: local garage door repair Berkeley
Pingback: cell phone spy mac
Pingback: easyspy cell phone tracker
Pingback: potato Peeler
Pingback: garage door installation Fremont
Pingback: Palm Springs AC Repair
Wasnt MS Best practice to have a domain like contoso.LOCAL internally?
This new SSL change seems to upend that entirely.
Best practices evolve over time 🙂
Pingback: fluoride filters
Pingback: Mike Dillard reviews
Hi Paul,
I find your website very interesting and this post has significance to an error i encountered with my Exchange environment.
I have 2 CAS servers and 2 Mailbox servers that was implemented from scratch.
All outlook clients could connect and suddenly on 02/05/2014 my clients keeps prompting for username and password.
When i delete and recreate the profile it says: “The connection to Microsoft is currently unavailable. Outlook must be online or connected to complete this action”
All connections through OWA works fine.
Hi Paul,
Could you help me to find risk in this scenario
Here’s one for your review… one of the Devs is asking for a certificate for dev environments to validate domains like:
*.ws01.dev9.com
*.ws01.dev10.com
This would allow them to validate any Dev subdomain off our internal CA cert.
Thanks
zulfiqar
Hello Paul,
great article. I completetly agree with you. Fortunately I have always designed the AD using registered domain name.
But just today I have an issue on an Exchange 2013 installation on a domain.local AD domain. I have changed all the internal/esternal url to the esternal register domain name, configured the split DNS. Just all the stuff I saw you mentioned on your article “Avoiding Server Names in SSL Certificates for Exchange Server 2013”.
But configuring Outlook 2013 I always receive the error on the name exchange2013.domain.local. And, as you wrote, adding the .local host name on the SAN certificate is not an option.
Any ideas?
Still my compliments. Ciao
My only thought is that you’ve missed something in your config.
Hello! I know this iss kinda off topic buut I was wondering which blog plaatform are you using for this website?
I’m getting sick and tired of WordPress because I’ve had problems with hackers aand I’m looking at options for another platform.
I would be great if you could point me in the direction of a
good platform.
This is a very informative article. I currently have an Exchange 2010 Server with SAN certificate. I use a mix of public DNS and private DNS names.
Currently I have the following in the SAN Names:
es1.company.com (used for OWA and Active Sync over the Internet and Outlook over HTTP)
autodiscover.company.com used for public auto-discovery
autodiscover.company.wan for private auto-discovery on LAN
servername.company.wan for network RPC communications
I use split DNS internally. Would it be a big deal to phase out the use of servername.company.wan and autodiscover.company.wan? Other than to ensure that my Internal DNS is pointing the first two records to my internal IP addresses, what else do I have to do or watch out for?
The best resource I’ve found that addresses this issue is “http://www.it-book.co.uk/2459/how-to-setup-exchange-ucc-or-san-certificate-with-non-standard-domain” works like a charm.
Pingback: SSL Certificates without Non-FQDNs | Entrust, Inc.
Is reconfiguring Exchange virtual directories to use the external namespace for both InternalURL and ExternalURL, and using split DNS valid for Exchange 2013?
I know for a fact that it works for 2010. But not sure about 2013.
Please advise.
Can i verify something (as we want to use SSL for activesync):
We use domain.local – locally.
External email and website domain used is do-main.co.uk
How best to proceed with activesync and godaddy cert?
Thanks
Two options:
a) Use a reverse proxy like TMG or other, so that you can have a public-facing SSL cert with just the public names, and then use your own CA for the internal SSL cert that is installed on the Exchange server itself.
b) Reconfigure your Exchange virtual directories to use the external namespace for both InternalURL and ExternalURL, and use split DNS (refer to Joseph’s comment above – https://www.practical365.com/ssl-requirements-for-exchange-when-certificate-authorities-wont-issue-certificate/#comment-14968)
Another alternative is to use a Layer 7 load balancer with SSL offloading. It is similar to the TMG example. In this case the virtual directories are configured not to require SSL and the ‘internal’ leg of the connection is transmitted insecurely – however we DO trust our internal network, so that’s not a problem is it?
It is a complicated topic. An IIS website can only have one certificate bound to it. IF SSL is required, the namespace configured on each virtual directory must be included on that certificate and that certificate must be trusted by the client. Outlook clients will access several virtual directories including Autodiscover, EWS and OAB (and possibly UnifiedMessaging too). If you get just one wrong, you can get a certificate warning message.
Some companies trust their internal network enough to not use SSL internally. Some do not. That is up to you. Personally I prefer to use SSL internally.
I ran into a similar situation during an Exchange 2003 to 2010 migration.
Someone thought it would be clever to use domain.AD as the internal namespace.
The workaround I used was to update the InternalURL properties of all of my CAS services to match the ExternalURL value.
The only real issue with this setup as it was necessary to maintain a split DNS zone internally for the external namespace to service clients connecting locally.
But that still seems like less work than maintining an additional CA, or renaming you production AD domain (Yikes!)
Just thought I’d throw that out as another possible workaround.
Thanks!
This also worked for me. We had a ‘.local’ internal namespace. We also had an internal DNS entry for our mail server’s external (.com) name which pointed to the server’s internal IP address. I used a non-SAN (i.e. basic web server) certificate from a public cert. authority for IIS/HTTPS, and my local certificate authority for everything else. By updating the Web Services Virtual Directory Internal URL and the Autodiscover Service Internal URI from the shell (as well as setting all of the CAS URLs in the GUI) I was able to allow OWA and EAS to function properly both internally and externally, and Outlook clients to connect without getting those pesky certificate popups. Thanks!
Paul,
regarding “Using a Mix of Private and Public Certificate Authorities”, you mentioned Microsoft Firewalls ISA/TMG to bind the external certificate to (Example1 and also Example2).
What if you don’t run an ISA/TMG but an alternative firewall such as pfSense, Astaro or IP-Cop?
Should it also be configurable, or does the bridge-functionality resp. access chain EXTERNAL CLIENT -> FIREWALL -> CAS require some special Microsoft-only features?
Thanks in advance!
If you want to use a mix of private and public certs then your public facing reverse proxy needs to be able to do the SSL proxying like ISA/TMG. Some do, some don’t. It isn’t a Microsoft-only capability.
Hi Paul – Currently we have a default self signed server certificate which contains the name of the Exchange Server. However when we use OWA and OutlookAnywhere, unless we use the internal LAN Exchange server name in the OWA URL / Outlook Anywhere Proxy server settings, we get certificate errors eg for OWA the error is that the certificate is not trusted and for Outlook Anywhere the error is that the server name is incorrect…
And this will of course only work when on the local Domain…
NOW..I want to create a new Exchange Server Certificate, which contains my resolvable server name (eg the server name which is used in the EXTERNAL Public DNS namespace..)
In your posts you have said that only one certificate can be used by IIS, and I am wary of creating a certificate that affects my local Outlook clients…
Can I create a second Exchange certificate solely for OWA and Outlook Anywhere services and leave the IIS,SMTP services on the default server certificate
We have problems getting a CA issued certificate as there are too many requirements asked for by the Certificate Issuer we have tried so far…Also we would like to use the private CA route if possible…
Thank you for your feedback/comments on the above
Yes, only one SSL certificate can be used by an IIS website. OWA, ActiveSync, OA etc run off IIS.
SMTP can use the same, or a different certificate, that is up to you.
The solution is to use a SAN certificate. I suggest you start reading here:
https://www.practical365.com/exchange-2010-ssl-certificates
That will tell you everything you need to know, including how to use a private CA if you choose to go that way.
I thought it was a best practice to have your internal and external namespaces different. Now its suggested that if you are creating a new AD forest/domain to go away from that and make them the same. Or rename your domain to a resolvable one. This makes no sense.
I assume Lync will be severely impacted by these changes as well.
Fewer namespaces are easier to manage, but that doesn’t mean that it is the right solution for all situations.
The main point is that you should not use namespaces that (a) you don’t own, or (b) are no longer valid under the new rules for SSL certificates.
Yes this will impact Lync and really any other product or technology where you need to acquire an SSL certificate from a public CA.
Hello Paul, the correct FQDN Server is: cas-01.scuola.local
Hello Paul, I have an Italian student and I read with interest your post but I would like to ask you a question that might interest many users.
I would like to use a registered domain for testing laboratory for a school. You carry the sample data for the domain name, server, etc..
Can you tell me what names should I take to a CA for a certificate SAN (The CA may issue certificates .local and .it)
Internal Domain Name: scuola.local
Public Domain Name: scuola.it
Name Server Exchange 2010: cas-01
FQDN Server: cas-01.server.local
I would like to use the name OWA mail.scuola.it, is it possible? Or should it be cas-01.scuola.it?
Could you tell me all the names to be included in the certificate request.
Thanks
Antonino
Actually i have learnt that i can use any internal name for my company, and if i want to have public name i have to choose one matches the world rules.
I mean would it be a problem to have my active directory domain (ABC.local)? , and if i wanted to have a public name i have to choose a name that hasn’t taken before by any company !
Is that what you meant or you mean to make the internal name like the external name (ABC.com) ?
If you think about E-mails, i can use hub transport Accepted domains for the external name and make an email address policy to change the E-mail addresses to the new extension (test@abc.com).
Do you think i am thinking right?
The internal/external namespaces can be different.
The point is that if you choose an internal namespace that doesn’t meet the new rules, or that you don’t own, then you won’t be able to get SSL certificates for those internal names (such as your Exchange server FQDN) from commercial CAs.
Aha, Got your point. But what should i do if can’t buy an certificate for my internal name space. i think i can use a local certificate authority or what is you opinion ?
Yes, thats when you can consider using your own private CA to issue the certs you need.