Exchange Server 2013 provides secure client-server and server-server network communications by using SSL certificates to secure protocols such as HTTP, SMTP, POP and IMAP.
Because of the “secure by default” requirements, when an Exchange 2013 server is installed it is configured with self-signed SSL certificates that are enabled for those protocols.
Here is an example of the self-signed certificates installed on a new Exchange 2013 server.
[PS] C:\>Get-ExchangeCertificate | Select Subject,IsSelfSigned,Services | ft -auto Subject IsSelfSigned Services ------- ------------ -------- CN=Microsoft Exchange Server Auth Certificate True SMTP CN=E15MB1 True IMAP, POP, IIS, SMTP CN=WMSvc-E15MB1 True None
Although this means that services such as Outlook Web App, Outlook Anywhere, and Activesync are secure right from the moment the Exchange server is installed, the use of self-signed SSL certificates in Exchange Server 2013 is only intended to be temporary while the administrator acquires and installs the correct SSL certificates for the server.
SAN/UC Certificates for Exchange Server 2013
Exchange 2013 uses a type of SSL certificate that is known as a “Subject Alternate Name” (SAN) certificate. In some cases this will be called a “Unified Communications” (UC) certificate by providers such as Digicert.
A SAN certificate is an SSL certificate that has multiple server or domain names on the one certificate. This means that you can use a single certificate to secure one or more Exchange 2013 servers, and it can include all of the server names and other external URLs you plan to use for your Exchange environment, instead of having to provision a single-named SSL certificate for each of the different names.
Planning for Exchange 2013 SSL Certificates
There are three requirements for an SSL certificate to work correctly in your Exchange 2013 environment.
Certificate Validity Period
The certificate validity period is the period of time between when the certificate was issued and when it expires. Every SSL certificate will have an expiry date, and this will vary depending on how the certificate has been provisioned.
The default, self-signed certificate that Exchange 2013 creates during setup is valid for 5 years. A certificate issued from a private certificate authority may be valid for several years as well.
A certificate that has been acquired from a commercial certificate authority such as Digicert will usually be valid for one year.
Trusted Certificate Authority
For a client to trust the SSL certificate that a server is using the certificate must be issued by a certificate authority that the client already trusts.
If you’re using a private certificate authority to issue SSL certificates to your Exchange 2013 servers, and that CA is an enterprise CA in your AD forest, then that CA will already be trusted by clients that are members of domains in that AD forest. Non-domain members will not trust the CA unless the root certificate is imported into their trusted CA list.
The major commercial certificate authorities are already trusted by the operating systems running on most computers or mobile devices, so when you acquire your certificate from one of those CAs it will be trusted by connecting clients as well.
These trust issues mean that although you can use a private CA to issue your SSL certificates, it tends to be easier and less administrative effort to use a commercial CA.
Note: this trust issue only applies to the certificates installed on a dedicated Client Access server. The Mailbox server can use self-signed certificates because it does not accept direct client connections. In a multi-role server the trust issue still applies.
Correct Server/Domain Names
The final requirement is that the server or domain name that the client is connecting to must match one of the names on the SSL certificate.
For example, if the clients use the URL https://mail.exchangeserverpro.net/owa to connect to Outlook Web App, then the SSL certificate on the Exchange server must include the name “mail.exchangeserverpro.net”.
Depending on the role and configuration of the server it may need several names to be included on the SSL certificate. The minimum recommended names are the Client Access namespace (when a single, unified namespace is used) and the Autodiscover namespace.
For example, an Exchange 2013 server in the “exchangeserverpro.net” domain may need:
- the OWA, Outlook Anywhere, Activesync external URL names, eg “mail.exchangeserverpro.net”
- the Autodiscover name for the primary SMTP namespace, eg “autodiscover.exchangeserverpro.net”
Microsoft’s published best practices on SSL certificates for Exchange recommend not including the server FQDN in the certificate. For more information on how to configure Exchange servers so that the server FQDN is not required on the certificate please refer to this article.
In an Exchange 2007 to 2013 upgrade/co-existence scenario the certificate may also need to include a legacy name, such as “legacy.exchangeserverpro.net”.
If you’re using an internal DNS namespace that you don’t own or is not valid (eg, .local) you may also need to read How to Deal with SSL Requirements for Exchange when Certificate Authorities Won’t Issue You a Certificate
How Many SSL Certificates to Configure?
For ease of administration, as well as for lower costs, it is recommended to provision as few certificates as possible.
Because the SSL certificate can include as many names as you need (up to about 50 before it may begin to cause performance issues), and with the way SAN/UC certificates are priced, it is often less costly to use a single SAN certificate for multiple Exchange Server 2013 servers than to acquire a unique certificate for each server.
Also consider that the trust issues when using a private CA to issue the SSL certificates for Exchange 2013 generally only apply to the internet-facing servers that will be accepting connections from non-domain members such as mobile devices. It may be possible in your environment to use a private CA to issue the SSL certificates for the non-internet-facing servers, as they may only be seeing direct connections from domain members.
The best number of certificates to configure is something for you to determine in the planning for your unique environment, but generally speaking fewer certificates is less costly and more manageable.
Next Steps
After planning your Exchange Server 2013 SSL certificate requirements the next steps are:
- Generate a Certificate Request for Exchange 2013
- Submit the certificate request to your chosen CA to acquire the SSL certificate. I recommend Digicert for their competitive pricing, good support, flexible licensing, and free re-issues if you happen to make an error. Or if you’re using a private CA refer to these steps.
- Complete the pending certificate request
- Export/import an SSL certificate to multiple Exchange 2013 servers (optional)
- Assign the SSL certificate to services in Exchange 2013
Hi, if we’re using Exchange on-premise solely as transport for mail to/from O365 as well as internal mail relay servers, should we include the server FQDNs on the SAN?
i.e. Let’s say we have a SAN with CN=smtp.mydomain.com and a self-signed cert for server1 and server2 that were installed when Exchange were installed.
SANs:
smtp.mydomain.com (auto-included)
smtp.myseconddomain.com
relay.mydomain.com
server1.mydomain.com
server2.mydomain.com
1. Should server1 and server2 be included if we want to use this cert for internal Exchange to Exchange server communication?
2. If we do not include these names on the cert, what will happen when the self-signed certs expire. Will Exchange server to server communication continue to work with the SAN cert as long as SMTP is enabled for this cert? Or will it fail because we did not include the server names?
3. If we keep two certs, one SAN for external use and the self-signed for server to server internal communication, will the self-signed cert auto-generate when it nears the expiration date?
I’ve read that including internal server names on SAN certificates is not best practice long term so we’re looking for guidance before we purchase a certificate.
Thank you very much in advance.
Surely it would just be easier to purchase a public wildcard cert and bind it to IIS.
At least that way you will cover all your urls?
It’s possible to test this by implementing an internal CA and issuing a privately signed wildcard.
when all steps as outlined above in the article were done, how does one fix this error:
“the security certificate was issued by a company you have not chosen..” and
“the security certificate is not from a trusted certifying authority”
fixed it myself!
this new CA where we bought their cheap certificates can’t seem to figure out how to bundle the root and intermediate certificates (that’s what it seems) in the .cer files they are sending us. so what i did was to push the root and intermediate certs to our users via gpo.
problem solved!
Hello Paul, first of all thx for you keeping this site updated it’s great!
5years ago I’ve installed Exchange 2013 (thanks to your manual), now self signed certificate is expiring (If I remember correctly it was isued by internal CA (domain)).
This certificate has IMAP,POP,IIS,SMTP services assigned.
Now we also have a certificate issued from public CA (Rapid**L) for *.domain.com for other services we use. I suppose that using this certificate would be beter. Shlould I just import it to ECP and check same services as on currently used SelfSinged cert?
Thx for any advice.
The Real Person!
The Real Person!
Renew the self-signed certificate. It’s still used for some server to server communications. Also IMAP, POP, and SMTP can have multiple certificates bound to the server. IIS only has one cert per site, but there’s a frontend and backend website in IIS, so often the backend website is still using the self-signed cert (which is fine).
Ty for fast reply, well, I had renewed it trough ECP last week and I had to recover whole server from backup 🙁 In ECP i clicked on renew, OK (it didnť generated any sing request for CA, and certificate got just renewed) then I restarted server and I wasn’t able to login to ECP or even start Exchange Powershell – had to do quick restore (It was in production time). Any advices how to proceed? Ty.
Currently used certificates are:
[PS] C:\Windows\system32>Get-ExchangeCertificate | Select Subject,IsSelfSigned,Services | ft –
Subject IsSelfSigned Services
——- ———— ——–
CN=*.XXXX.XXX False None
CN=mail.XXXX.XX True IMAP, POP, IIS, SMTP
CN=Microsoft Exchange Server Auth Certificate True SMTP
CN=SERVERNAME True IIS
CN=WMSvc-SERVERNAME True None
The Real Person!
The Real Person!
The steps are documented on TechNet.
https://technet.microsoft.com/en-us/library/ee332322(v=exchg.160).aspx
As with any change, test what you’re unsure about, and perform the change during non-critical hours.
Rolling back the entire server was potentially more harmful than a bit of downtime while you worked on fixing whatever was wrong.
I am using a wildcard certificate for the IIS service. When I attempt to log into ECP or OWA, it loops back to the login prompt page. If I switch the certificate to the self-signed one, I am able to login without any issues. Why would it not work with the wildcard cert?
Same as mentioned by HybridDude
Its a single 2013 server with CU15. Cert is issued by COMODO RSA Certification Authority
Hi,
After some digging i found a site that solved my problem: https://blogs.technet.microsoft.com/jasonsla/2015/01/15/the-one-with-the-fba-redirect-loop/
Converted the pfx-file from CNG to CryptoAPI-compatible provider using the following commands:
openssl.exe pkcs12 -in old_certificate.pfx -out certificate.pem -nodes
openssl.exe pkcs12 -export -in certificate.pem -out new_certificate.pfx
Cheers, Manfred.
Hello Paul,
I have question please
I am using a public certificate from godaddy, and I see that WMSVC certificate will be expired in few months
Is it mandatory to renew it?
Thanks,
Mina
Hello Paul,
I have question please
I am using a public certificate from godaddy, and I see that WMSVC certificate will be expired in few months
Is it mandatory to renew it?
Thanks,
Mina
our SSL Cert. exceed the number of SAN – it’s up to 5 SANs –
The Support service advice me to buy new SSL Cert. so I’ll have 2 Certs. so I can add new SAN
I this case .. can Exchange work with more than one SSL Certificates in same time ?
or shall I purchase SSL Cert. up to 10 SAN then transfer all domains in one Cert. ?
The Real Person!
The Real Person!
Only one cert can be bound to IIS at a time, so I would recommend you increase the number of names on the certificate. I believe up to 50 names is supported before it becomes a performance problem.
I have a weird situation. I am trying to setup a phone for email. I am getting “The name of the site does not match the name on the certificate.” when I try to configure externally or internally. To make things even weirder, when I view the certificate externally, I get support.contoso.com and when I view the certificate internally I get *.contoso.com. We did purchase a wildcard certificate for all of our web services. I just do not understand what would cause this.
The Real Person!
The Real Person!
You might be seeing this behavior.
https://www.practical365.com/exchange-server/fixing-autodiscover-root-domain-lookup-issues-mobile-devices/
My exchange 2013 completely failed after certificate renewal?? any advice is appreciated..
Your website is invaluable and your Exch 2010-2013 Migration Guide is really helpful too (http://bit.ly/28ITHhR). I’m glad I bought it.
I’m installing Exchange 2013 into a new domain. The internal domain name is “ad.widgets.com” but external is “widgets.com”. I’ve never built an Exchange org with an internal domain that has that additional level. How (if at all) does that affect the names I’ll need on my cert and the forward lookup zones I’ll need to create in local dns? Also, when I configure virtual directories, should they be like “https://mail.widgets.com/ecp”, for example or “https://mail.ad.widgets.com/ecp”?
Thank you!
I’m stuck with 3 SSL certificates for mail.domain.com, autodiscover.domain.com, and legacy.domain.com. Is there any way I can incorporate those three certificates into Exchange 2013 (with coexisting Exchange 2007 for limited time) without having to buy another SSL SAN certificate? My certificates are from Network Solutions, and they don’t support SAN. I’m getting lots of certificate errors for legacy.domain.com and autodiscover isn’t working properly, so external access using Outlook Anywhere isn’t working either. Everything was great on Exchange 2007 with Outlook Anywhere with my old SSL certificate. I just need some ideas on if and how I can get these three certificates to work with Exchange 2013 while I still have legacy clients, and even after everything is migrated, how to get autodiscover working on Exchange 2013. I appreciate your help.
The Real Person!
The Real Person!
Certificates can’t be combined or merged, and only one certificate can be bound to IIS for all of the HTTPS services in Exchange.
I suggest you buy a cert from a vendor that can provide the correct type. I recommend Digicert.
I am using a wildcard certificate for the IIS service. When I attempt to log into ECP or OWA, it loops back to the login prompt page. If I switch the certificate to the self-signed one, I am able to login without any issues. Why would it not work with the wildcard cert?
The Real Person!
The Real Person!
Single server? Multiple servers? Load balancing?
Thanks Paul,
Excellent reading. I have spent some time figuring out a problem with a purchased certificate and Exchange 2016. Kept on getting SSL Protocol errors when trying to access OWA en ECP from the internet. It turned out to be a enabled hidden port in my router (443 used for VPN over SSL) which had a self-signed certificate. Since the error is a bit vague I spent some time searching. So for anyone reading this comment and having SSL trouble: *check your router for 443 ports*. Often 443 is enabled as maintenance port but it good also be very well hidden in the router’s VPN settings.
Hello Paul, I am securing a single server with Exchange 2013 CU11, FQDN is ES2013.mydomain.com, I followed your guides to mask the server FQDN and instead use mail.mydomain.com however I have users who will still use POP mail. When I generate the request in ECP it says ES2013 for POP and IMAP, all others say mail.mydomain.com. I tried changing to mail.mydomain.com but it just changes back to ES2013 – I guess this is because they aren’t virtual directories? If this is the case do I need to leave the server name and the request and use a SAN? Also, autodiscover Internal URL is es2013.mydomain.com — I guess this alone will make it a SAN? I have tried changing that URL also and it doesn’t ever update.
The Real Person!
The Real Person!
The wizard is just auto-populating based on your current namespace configurations on virtual directories, on Outlook Anywhere, and on AutoDiscover. On one of the last steps of the wizard you can add/edit/remove any of those entries and just cut it down to the namespaces you want.
If it’s auto-populating an AutoDiscover namespace that you don’t want to use then I’d suspect your namespaces aren’t configured correctly. Here’s an article that should help you with that:
https://www.practical365.com/avoiding-exchange-2013-server-names-ssl-certificates/
Also bear in mind that even though one SSL cert can do it all for you, POP and IMAP are capable of being bound to separate SSL certs than the HTTPS (IIS) services. So you can have a separate cert entirely for POP and IMAP, but it’s simpler to put it all on one cert.
Hi Paul,
After we have assigned a public certificate to services, would you recommend that we remove the self-signed certificate as it is linked to SMTP?
My issue is that I am trying to our users to start using SMTP:587 for legacy customers who uses Imap/SMTP via Thunderbird.
Thunderbird keeps complaining about the certificate has name which does not match the load balance fqdn to the Exchange 2013 servers.
I want to remove those Self Signed Certificates bound to SMTP – but I am concern that they are used by Exchange for Internal Transport or something like that…
Thanks in advance!
The Real Person!
The Real Person!
No need to remove it. But what you do need to do is set which certificate is to be used by that receive connector for TLS connections.
Thanks legend 🙂
Paul,
Following your 2007-2013 blog I found the 2007 Exchange Certificate issued by godaddy has all the names required to import into Exchange 2013. When export from 2007 I get the PFX. When I import either in MMC or ECP it shows invalid. Is there anything you recommend to resolve this issue? We still have 8 months left on the certificate expiration.
The Real Person!
The Real Person!
Are you exporting it with the private key?
Pingback: Exchange Server 2013 - Renewing an SSL Certificate
Pingback: Configuring Autodiscover in Exchange 2013 | geekdudes
Thanks Paul,
I have followed your instructions and all looks well, except for one thing.
For some reason ECP Login Page intermittently loops. Sometimes it will log you in with no problem, other times after you put your password and hit login, you just loop back to the login page without any errors. OWA seems fine for now just ECP problem after changing that Cert.
Thanks again for the great assistance
The Real Person!
The Real Person!
You’re load balancing across 4 servers? Possibly there’s an issue with one of them or the load balancer itself. Use a hosts file to test each one directly, bypassing the load balancer.
https://www.practical365.com/testing-connectivity-and-dns-changes-with-a-hosts-file/
Will give it a try and revert,
I’m using DNS to do the round robin, owa.domain.com pointing to the 4 Exchange servers IP’s.
Thanks Paul,
Managed to find the “faulty” one and sorted out.
Hi,
I have an Exchange 2013 environment, and the 3rd part Cert is about to expire. I have already got the new cert and installed it all all 4 exchange servers, however 1 server still keeps logging a Transport Service and Front End Transport Service StartTLS error saying that the Thumbprint XXXXX of the old cert is going to expire.
The new cert is installed and working fine, only this one server keeps giving this error.
Any Advise?
Many Thanks
The Real Person!
The Real Person!
SMTP can have multiple certs enabled for it. So I’d say your old cert is still enabled for SMTP.
I Have disable the cert from Cert Store and seems like the error has gone away.
Thanks,
Ok Disabling that cert, doesn’t look like it worked. My users are now having a problem were Outlook says, Connected and Updating Folder, but no new emails come in. If they close and open Outlook, the emails start coming in.
By any chance is this related?
The Real Person!
The Real Person!
Disabled from Cert Store? You mean by opening MMC and adding the Certificates snapin… that’s not the right way to do it.
I’d say you’ve disabled the wrong cert. Revert your change to fix your end user problems.
Here’s how to remove an old cert that is only enabled for SMTP:
https://www.practical365.com/remove-ssl-certificate-exchange-server-2013/
When I do the following I don’t have the “Microsoft Exchange Server Auth Certificate” On the CAS or mailbox servers. Do I need to add that cert? Our domain internally is domain.local and external domain.com.
Get-ExchangeCertificate | Select Subject,IsSelfSigned,Services | ft -auto
Subject IsSelfSigned Services
——- ———— ——–
CN=EXMB1 True IMAP, POP, IIS, SMTP
CN=WMSvc-EXMB1 True None
Subject IsSelfSigned Services
——- ———— ——–
CN=mail.domain.com, OU=Domain Control Validated False IMAP, POP, IIS, SMTP
CN=WMSvc-EXCAS1 True None
My certificate will expire in two months. I already got the new one. Can I add the new one and leave the old one until the expiration date without issue?
The Real Person!
The Real Person!
Did you get the new one as a renewal or as a whole new cert?
If it’s a renewal I think there is no “old one” left behind. If it’s a completely new cert with the same names then yes you’ll have an “old one” left behind. There’s no specific harm in having expired certs on the server as long as they aren’t enabled for any Exchange services. Removing expired certs is good if you like neat and tidy servers 🙂
Dear Paul,
hope you can help me,
I have the following issue, when I am trying to move my exchange 2013 to office365 I got issue that “RPC Proxy can’t be pinged.” when I am using http://www.testexchangeconnectivity.com.
please help.
Hi Paul,
I am in a similar situation where my internal and external domain names are different (domain.prv and domain.com).
I am planning on moving from Exchange 2010 to Exchange 2013. I am also planning on getting a SSL UC Cert from DigiCert. I see you mentioned that the internal url’s do not have to match the AD domain (domain.prv). The current Exchange 2010 server has different internal and external URL’s.
So if I used domain.com for my internal and external url’s on the new deployment how would the DNS work? When internal clients go to resolve mail.domain.com it would resolve to the external/public IP? I guess this would still work but would result in a bit more traffic/hops to reach the internal mail server.
Any ideas?
The Real Person!
The Real Person!
The answer is to use split DNS.
I have a quick question regarding the renewal of our GoDaddy certificate that is about to expire.
Will I create a new certificate request and follow the same guide as the first one installed? I don’t see a “renew” option within EAC. Then once it’s imported delete the one that is expiring?
Thanks,
Mike
The Real Person!
The Real Person!
Select a certificate in EAC and there is a “Renew” link to click on to generate the cert req for the renewal.
I’m in the same situation as Rovert.Natsud. I have a need to create an internal cert for the mail.server.its. mail.domain.com. Trying to convince management to change now would not work. We have limited staff to do the work, easier to have a cert for internal and the external.
Dear Fred,
you may use a Comodo SAN certificate for your situation.
They still support internal host names, but maximum validity period is limited to one year from now on (as Comodo will not issue a certificate with an expiry date later than 31 October 2015 with a subjectAlternativeName (SAN) or Subject commonName (CN) field containing a reserved IP address or internal server name).
Have a look here:
https://www.sslpoint.com/multi-domain-ssl-certificates/
https://www.sslpoint.com/exchange-ssl-certificates/
More info on internal domain names / SSL certificates:
https://cabforum.org/wp-content/uploads/Guidance-Deprecated-Internal-Names.pdf
Best regards
Peter
Hey Paul
Thanks, sounds promising and that you speak from experience, I don’t suppose you have any step by step instructions or URL’s you point us to?
Thanks
Rovert
Hi,
My Setup:-
Server 2012 r2 AD/DC using domain.local
Server 2012 r2 and Exchange 2013 with Godaddy UCC Cert (mail.domain.co.uk) as primary record
Internal DNS (default setup as with AD/DC)
–> domain.local
–> added mail.domain.local –> Internal Exchange IP
–> added autodiscover.domain.local –> Internal Exchange IP
External DNS MX
–> mail.domain.co.uk –> Public IP
–> autodiscover.domain.co.uk –> Public IP
Clients
–> Win 7 Pro
–> Outlook 2010
SSL
–> Public records only (i.e. mail.doamin.co.uk) as domain.local is no longer an option on Godaddy certs.
My Issue:
When either I setup a new client (Autodetect on setup) or when a client open’s Outlook they are presented with a certificate error (example: http://1.bp.blogspot.com/-NxXZoCeZUZ0/UrRHz9AFmQI/AAAAAAAAAJg/D-kEGuKJGHw/s1600/SSLError.png). The certificate is from a trusted authority and the certificate date is valid but the error is “The name on the security certificate is invalid or does not match the name of the site.
After searching round I found this (http://www.digicert.com/ssl-support/redirect-internal-exchange-san-names.htm) but im not sure of its effects as it states “this method will not allow access to mail using the Outlook Anywhere service so users connecting over a VPN would have connection problems” so personally I don’t think this is a good option.
I have also found this (http://www.digicert.com/internal-names.htm) which I think maybe a better option but i’m misunderstanding what exactly I have to do.
Please can someone give me a bit of a step by step on what I have to do?
Thanks in Advanced
The Real Person!
The Real Person!
Why not stop using .local for your internal Exchange namespaces?
Exchange doesn’t need to use the same namespace as AD. It can be anything you like. In fact it is quite common to use the same internal and external namespaces in Exchange 2013.
Hi Paul
Thanks for taking the time to reply, sounds a good idea, although now I have the network built with .local I can see why you wouldn’t use .local using Server 2012 r2 and Exchange 2013 with Outlook.
What options do I have to fix this issue and how would I go about it? ive seen a number of sites suggesting a fix but I don’t want to cause further issues or connection problems like not being able to get to OWA or ECP.
Any help would be grateful.
Thanks
The Real Person!
The Real Person!
Well your situation is never going to get better now that CAs won’t issue certs for .local domains and other similar restrictions these days. So going through the pain of a transition to new URLs is worth it, in my opinion.
If it is done right the only real impact to end users is possibly learning a new “webmail” URL for internal use (if that is even a use case for them). And you can soften that blow with HTTP redirects and other tricks anyway.
So my recommendation is you build up a simple test lab using .local internal names, connect up some test Outlook clients, and then test the process of changing your internal namespaces over to the new URL. It isn’t actually very difficult at all.
Hi Paul
Can I ask your advice regarding my current 2010 environment and upgrading to 2013 please?
The environment is 2010 SP3 ru5 and is set up as follows
AD Site 1 has 2x CasHub and 2 Mailbox servers
AD Site 2 has 1x CasHubMailbox
These have a 3 node DAG
For whatever reason the VDs on the servers in site 1 are set to autodiscover.domain.com for both internal and external URLs
The VDs in site 2 are set to legacy.domain.com for both internal and external URLs
Certificate is issued by Digicert and contains Mail. Autodiscover. Legacy. & Webmail. SAN names
The mailbox servers in both sites serve mailboxes and cross site silent redirection is configured
Even though everything works perfectly I’m pretty sure the virtual directory names aren’t configured to follow the best practices.
I’m having a bit of trouble getting my head around how to name the virtual directories in 2013 to support a coexistence scenario bearing in mind the server in AD site 2 needs to stay in the 2010 DAG (we can’t remove it to make migration easier)
I’m just wondering how you recommend configuring this going forward to support a 2010/2013 coexistence scenario ?
Thanks
Jim
Pingback: Exchange 2010 to 2013 Migration - Namespace and Certificate Planning
Thanks Paul
Hi Paul,
I know with 2013 co-exiting 2007 we required new SAN certificate.
Do we required new certificate for 2013 in co-exiting of 2010? I believe no the reason why because there is no legacy name is required for 2010.
Please confirm the same.
The Real Person!
The Real Person!
Correct, in most scenarios you wouldn’t need to replace the Exchange 2010 certificate because no legacy namespace is being added, unlike with Exchange 2007.
Hello, informative artical, but i am having a few issues trying to sync my sharepoint 2013 and my exchange 2013 for task sycronisation, following a guide on technet.
my exhcange 2013 has no issues and has working certs and the users are happy.
Hello, been stuck on the same issue for around 8hours +, tried different methods and guides to resolve it, prior to this I have installed EWSMangaedApi on the sharepoint server and am trying to follow this guide,
http://technet.microsoft.com/en-us/library/jj655399(v=office.15).aspx
When I run the command on the exchange server I get this error
Creating Partner Application using metadata with linked account .
Cannot acquire auth metadata document from ‘https://sharepointserver/_layouts/15/metadata/json/1’. Error: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel..
+ CategoryInfo : ResourceUnavailable: (:) [New-PartnerApplication], AuthMetadataClientException
+ FullyQualifiedErrorId : [Server=exchange2013,RequestId=db3e1621-3811-4897-887e-1fcdd9c6ebf5,TimeStamp=11/03/2014 16:51:09] 3E70882,Microsoft.Exchange.Management.SystemConfigurationTasks.NewPartnerApplication
+ PSComputerName : exchange2013.domain.co.uk
When I run the command on the SharePoint server I get this error
PS C:Userssp_install> New-SPTrustedSecurityTokenIssuer -MetadataEndpoint “http
s://sharepointserver/autodiscover/metadata/json/1” -Name “exchange2013”
New-SPTrustedSecurityTokenIssuer : The underlying connection was closed: Could
not establish trust relationship for the SSL/TLS secure channel.
So look at this there obviously a SSL/TLS error.
I am wanting to configure task synchronisation between the exchange server and SharePoint 2013 servers, the SharePoint is going to be internal and access provided to outside users via a VPN.
I created self-signed certificate on the SharePoint server (this is still a development environment).
I then used bindings in IIS to add to the SharePoint site adding https over port 443 and added the self-signed cert to the SSL certificate, then in SharePoint central admin I managed the trusts and added it to the trusts list and also configures a new alternate access mapping to HTTPS.
When I now navigate to the website it comes up with a certificate warning, if I install the certificate the error still appears even if I add it to trusted root certificates, (is this normal???)
I have even installed the certificate on the exchange server in the trusted root certs and it still complains about the SSL TLS connection.
Any suggestions are welcome,
Many Thanks – BpdZenith Admin
The Real Person!
The Real Person!
Can’t help you with SharePoint I’m afraid, but I suspect what you’re seeing is a problem due to certificate trust issues. That can be caused by the root CA not being trusted, by the URL not matching a name on the certificate, or by the certificate being expired.
Hi Paul,
I am wondering what you recommend with requirements below?
> Exchange 2013 will provide services for both intranet and internet access.
> FQDN for intranet is xxx.com. FQDN only exists in internal DNS, but not in external DNS.
> FQDN for internet is xxx.com.au.
> Since internet access is allowed, public certificate will be used.
As I understand, public SAN certificate will not be allowed to have intranet FQDN soon for security concern. http://support.godaddy.com/help/article/6935/phasing-out-intranet-names-and-ip-addresses-in-ssls
With this reason, public SAN certificate will only include FQDN for internet.
So, feasible solution here is to put CAS dedicated to intranet access and CAS dedicated to internet separately?
The Real Person!
The Real Person!
Some reading for you here:
https://www.practical365.com/avoiding-exchange-2013-server-names-ssl-certificates/
Hi Paul,
What I meant was that we need to use separate FQDN for intranet and internet users.
So, if possible, public SAN certificate might to be nice to have both FQDNs. However, the problem is that internal FQDN does not exist as a public DNS, and with that reason, public CA will not allow it to be included in SAN certificate.
The Real Person!
The Real Person!
Then you’ll need to issue the cert from your own CA.
Or, use a proper namespace for your internal URLs so you can get the cert from a commercial CA.
I have issue after we change the IP Public for our Exchange Server.
We can access our email by outlook in computer that join domain
But it is not working when i tried to connect outlook in computer that is not join domain.
the outlook always asking password and not let me login.
Then In outlook anywhere at outlook, I tick connect using SSL only and proxy authentication setting is NTLM
it gave me error code 8 when i opened the outlook.
“There is a problem with the proxy server’s security certificate. The security certificate is not from a trusted certifying authority.
Outlook is unable to connect to the proxy server mydomain.com. (Error Code 8).”
is there any missconfiguration ?
before migrate to new IP Public, it worked find.
Regards,
Rendy
Pingback: Issue an SSL Certificate for Exchange 2013 from a Private CA
What about the SAN Certicate with an empty subject common name, is it supported?
Thanks
George
The Real Person!
The Real Person!
No idea. Never tried. Never even seen a cert like that I don’t think.
Hi,
what about the WildCard Certificate, is it supported in Exchange 2013 ?
Thx
Yes, it works. You can save money on using wildcard cert, I deployed it with full Exchange 2013 functionality (except UM) and also it works on reverse proxy based on IIS ARR.
Yes, wildcard SSL certificates are supported and work without annoying error messages.
You could also have a look on multi-domain SSL certificates (UCC/SAN) – they protect up to 100 host names with one certificate and might be cheaper than wildcard SSL certs (up to five host names are usually included in the standard package of the differents certificate authorities).
Getting below error on HT server though the TLS is enable and receive 250 StartTLS response.
Receive connector “XYZ” requires Transport Layer Security (TLS) before the MailFrom command can be run, but the server can’t achieve it. Check this connector’s authentication setting.
Hi Paul,
Thanks for your sharing. Your article did help me a lot while I set up Exchanger 2013.
May I seek your suggestion on the below scenario? Thanks in advance.
AD Schema: Windows Server 2008 R2
OS of Exchange server: Windows Server 2013
Version of Exchange Server: 2013
SSl Certificate: generated by DC
External DNS setup: Yes
Accessibility of external OWA: Yes
Currently my company want to let users access company mail by Outlook 2007/ 2010 on non domain-joined computers. The only way for the user to do it is to import root CA to the machine. May I seek your advice if there is another way to do it without manually importing root CA?
Appreciation.
Prudence
The Real Person!
The Real Person!
The solution is to buy an SSL certificate from a provider such as Digicert. The process is almost identical, except after generating the certificate request you upload it to Digicert instead of to your own CA.
The price of an SSL cert is quite reasonable and will avoid problems with non-domain members not trusting certificates issued by your own CA, as well as avoiding the administrative burden of importing root certificates on all the non-domain members.
Pingback: Avoiding Server Names in SSL Certificates for Exchange Server 2013
I have a question regarding SAN cert name requirement for Unified Messaging (UM).
Since UM is now hosted on mailbox servers, will we need to have all of the mailbox servers with UM roles enable (started) as part of the SAN cert names?
I am asking the question in consideration of multiple DAG mailbox servers, and lync integration in the exchange Org.
Thanks all!
Ed
The Real Person!
The Real Person!
Good question. I’m not sure of the answer though since I don’t do a lot with UM. I’ll try and look into that…
Paul,
I have just completed the deployment of UM servers on two of my DAG Mailbox servers.
I have also deployed 2 CAS servers that runs UM routing services.
When I don’t have the servers hostname on the SAN certificate, my UM will not work. Voice calls will be directed to the UM servers but will immediately be dropped. I then tested generating new SAN certificate that includes only the CAS server with UM routing services, still no go.
(note: yes my old exchange 2010 cas/hub/mailbox/um is still working in co-existence mode. However mailboxes migrated to exchange 2013 were the one having the UM issues).
When I included the hostnames on all of my CAS and DAG servers, UM started working.
I may have made a few configuration a long the way that caused UM to work, but I was able to get UM working with those addtl hostnames in the SAN.
I hope this post will help others with similar scenario.
Cheers, Ed Osckar
Hi Paul,
You don’t need server fqdn in the certificate provided that you have configured Exchange properly, by re-pointing all urls to a VIP, NLB etc. It is not about exposing the server names in the cert, just because it is exposed in the message headers anyway!
You can remove server names from the headers using Header Firewall. http://howexchangeworks.com/2012/02/header-firewall-in-exchange-2010.html
It is about keeping the entries in the cert to a minimum, therby reducing the cost and keeping things simple. I work in a very large org with 100s of Exchange servers and if we were to add server names in the cert, we will need a full time person to refresh the cert on all servers, as more number of servers get added/removed on a weekly basis in large corps.
If you have any reasoning to have the server names, let us know.
Thanks,
Rajith.
Hi
I have two exchange 2010 and two exchange 2013 2010 is our existing environment and we are upgrading to 2013 now . i just want to know one we want to run both the environments paralally we have separate certificates for 2010 with the entries of server 1 and server 2 with owa and all other things now we have to create a server for exchange 2013 what are the things we are supposed to add in that certificate FYI we have 2 servers of 2013 is that required to add all four servers in the certificates if yes we have a constrain here only five entries can be keyed in a certificate could you please advise on this.
Hi
Adding the CAS server name to the SSL certificate is not an option for me as we don’t own the internal domain namespace.
What should I do then?
The Real Person!
The Real Person!
You can configure the URLs for a namespace that you do own instead.
You’ll also want to add a forward looup zone internally for your paid for external namespace, and configure your autodiscoverinternaluri with the external namespace as well. You don’t need any of your internal only names listed on the cert.
The ExternalURL and InternalURL parameters on the autodiscover virtual directory are not used at all. They only exist because they are inherited from a base class used for all virtual directories.
Pingback: Exchange 2013: Assign SSL Certificates to Exchange Services
Pingback: Exchange 2013: The Internal Transport Certificate Cannot be Removed
Pingback: Exchange 2013: Export/Import SSL Certificates to Multiple Servers
Pingback: Checkboxes Greyed Out While Managing Services for SSL Certificate
Hello, If I am correct Exchange 2013 certificate best practices differs from Exchange 2010.
http://technet.microsoft.com/en-us/library/dd351044(v=exchg.141).aspx
It’s written:
The most important step you can take to reduce the number of host names that you must have and, therefore, the complexity of your certificate management, is not to include individual server host names in your certificate’s subject alternative names.
So example would be:
Mail.contoso.com This host name covers most connections to Exchange, including Microsoft Office Outlook, Outlook Web App, Outlook Anywhere, the Offline Address Book, Exchange Web Services, POP3, IMAP4, SMTP, Exchange Control Panel, and ActiveSync.
Autodiscover.contoso.com This host name is used by clients that support Autodiscover, including Microsoft Office Outlook 2007 and later versions, Exchange ActiveSync, and Exchange Web Services clients.
Legacy.contoso.com This host name is required in a coexistence scenario with Exchange Server 2003 or Exchange 2007. If you’ll have clients with mailboxes on both a legacy version of Exchange and Exchange 2010, configuring a legacy host name prevents your users from having to learn a second URL during the upgrade process. For more information about upgrade and coexistence, see Upgrade from Exchange 2003 Client Access and Upgrade from Exchange 2007 Client Access.
In your example of SAN’s you include FQDN of the server hostname. Is it really must have? If we include it then external users can see internal server names and domain name. Maybe there are some hard changes that need hostnames? I remember Exchange 2007 times when I setup all names including NetBIOS hostnames:)
All you HAVE to have on 2013 is mail dot and autodiscover dot. Legacy is not needed for 2010. It proxies the connection to the backend 2010 through the 2013 frontend. NetBIOS is not needed either if you change all of the autodiscoverinternaluri and other settings to match the external namespace. As a side note, there is no security risk with people on the internet knowing your internal server names. Security by obscurity is no security at all. 😉
It’s not so easy to setup Autodiscover in Exchange 2013:
http://social.technet.microsoft.com/Forums/en-US/exchangeserverpreview/thread/921dc266-419a-4093-a918-84816168b4d4/
legacy is needed for Exchange 2007 coexistence.
I have one installation where Outlook 2007 prompts (Outlook 2010 goes without error) an error about the certificate name mismatch due to the fact that Exchange appier as hostname of the server (even all was setup to use another name). So Paul written that FQDN of the server hostname is needed, so if you have eg 4 CAS servers you need more SAN names…
The Real Person!
The Real Person!
I am sometimes amused by people trying to avoid putting server names in an SSL certificate all the while exposing them in message headers anyway.
Good reason, but this does not answer the question: why we need FQDN name of the CAS servers:)
@Gediminas
You do not need the internal FQDN so long as you set the autodiscoverinternaluri correctly.
http://www.shudnow.net/?s=autodiscoverinternaluri
Yes, Kyle, thank you for the link. It was indeed all correct for Exchange 2007/2010. But 2013 autodiscover configuration needs to be done using low level utility eg adsiedit. By default autodiscover internal and external URL are empty. I hope this config is still supported by Microsoft.
@Gediminas incorrect. I’ve done multiple production deployments, both greenfield and in 2010 coexistence, and I can assure you that both the internal/external urls are not needed and can be left blank. The only thing you need to change is all of your regular web urls (ews, oab, eas, owa, oa, etc) and the autodiscoverinternaluri. Once you’ve changed all of those to something like mail.company.com, that and autodiscover.company.com (the built in url that outlook uses when NOT inside the network) is all you need to have on the cert. In fact, you will NOT physically even be allowed to add internal FQDNs to all new certs as it is no longer allowed. See the changes here: http://www.networking4all.com/en/ssl+certificates/faq/change+san+issue/
Thank You Kyle, you answered my question fully. It’s very clear that there is no need and is even not recommended to put FQDN of server in certificate. I was indeed wrong with configuration and this post also is misleading:
http://social.technet.microsoft.com/Forums/en-US/exchangeserverpreview/thread/921dc266-419a-4093-a918-84816168b4d4/
because we setup autodiscover uri using the “Set-ClientAccessServer” cmdlet with the “AutoDiscoverServiceInternalUri” parameter instead of Set-AutodiscoverVirtualDirectory
By the way you can configure to not expose internal host names in headers by using header firewall or transport rule to remove some info from outbound messages.
I follow you guide and configure certificate successfully and can be access owa without certification error message. Now I want to use Outlook 2013 to connect mailbox. Could you give steps how to do it? thanks.
The Real Person!
The Real Person!
Open Outlook and follow the prompts. Autodiscover should take care of the configuration for you automatically.
Thanks for your reply. I want to configure the mailbox account manually, in order to change and debug it easily. I select “Microsoft Exchange Server or compatible service” in “select service” page, and then fill “Server” and “User Name” information correctly in the “Server Settings” page. (make “More Settings” as default). After the configuration, I find I can’t connect to Exchange Server. Could you supply me the steps how to configure it? Thanks in advance.
My second question is if I configure outlook anywhere on both “Exchange Server 2013” and Microsoft Outlook 2013 client, Can I connect to Exchange Server 2013 using outlook client even though the outlook client doesn’t install in the same domain with Exchange Server? (that means can I install outlook client outside the domain if I configure outlook anywhere?).
Sorry for the expression. English is not my native language.
Hi all,
After requested certificate for Exchange server 2013 (client access+mailbox role are same as PC), does I need to import this certificate for non-domain PC for using Outlook to connect to Exchange 2013 ?
Thanks,
The Real Person!
The Real Person!
If the cert comes from a CA that the PC already trusts (eg a commercial CA such as Digicert or Verisign) then you shouldn’t need to do anything.
If you’ve issued the cert from a private CA then you’ll need to import the CA’s root certificate into the trusted root cert store on the PC.
Could you give steps about how to import the CA’s root certificate into the trusted root cert store on the PC?
The Real Person!
The Real Person!
Via Technet:
http://technet.microsoft.com/en-us/library/cc754841.aspx
Pingback: Outlook 2013 SSL Trust Errors When Connecting to Exchange Server
Can you please explain how certificates are used when Exchange 2013 UM is combined with Lync 2013 as a trusted app for OWA IM integration? Since there are two different worker processes and services, one on the front end and one on the backend, I’m not sure where this cert needs to go and what names it needs to have on it. And Technet does a horrible job of explaining this, and describes it differently depending on the link you are looking at.
The Real Person!
The Real Person!
Which Technet articles are you looking at?
One of them is this, where it says you have to edit the OWA webconfig file:
http://technet.microsoft.com/en-us/library/jj688055(v=ocs.15).aspx
Another one is this, where it makes no mention of this, but has some other Exchange commands not listed in the first one. It also makes mention of needing the server FQDN in the certificate, as you do. However, they reference the CAS name as the name of the app pool and the name that needs to be included in the cert…but OWA is actually in a backend IIS directory on the MB role when it’s split.
http://technet.microsoft.com/en-us/library/jj204857(v=ocs.15).aspx
And in yet another article (can’t find the technet one right now, but have listed another), it specifically points out the backend IIS directories with still more confusing certificate info.
http://memphistech.net/?p=280
And to wrap it all up, all articles say that if you are not connecting to IM, just check the “C:Program FilesMicrosoftExchange ServerV15LoggingOWAInstantMessaging on the MBX server” but I can’t find that directory anywhere, much less find the log files to reference for troubleshooting. And there is nothing in the event logs either.
Am I going crazy?
The Real Person!
The Real Person!
There is an OWA vdir on the back end but client connections hit the CAS and are proxied through from there. So that would include Lync as well, according to that Technet article (its asking for the CAS FQDN).
I wish I could say for sure one way or the other but I haven’t looked into your scenario enough to know.
Think I may have found the answer…haven’t tested yet, but it looks like it might work. I got this from our Exchange/Lync 2013 TAP program guys.
http://blogs.technet.com/b/jenstr/archive/2012/10/31/troubleshooting-tips-for-exchange-2013-owa-im-integration-to-lync-2013.aspx
Pingback: Installing Certificates in Exchange Server 2013 | The Best Email Server
Pingback: Exchange 2013: How to Complete a Pending SSL Certificate Request | The Best Email Server
SSL SAN Certs in about 2 more years are going to be a bit challenging!
http://www.digicert.com/internal-names.htm
Pingback: Exchange Server 2010 SSL Certificates
Pingback: Exchange 2013: Create an SSL Certificate Request