Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
?
Solved

Exchange 2010 best practice for receive connectors to avoid STARTTLS errors

Posted on 2014-08-29
10
Medium Priority
?
1,638 Views
Last Modified: 2014-09-23
We're receiving the usual MSExchangeTransport 12014 error on our new Exchange 2010 box.  It's a single box and still talking to our old Exchange 2007 while we wrap up the migration.

No edge server or device.  We send all email out to a single mail server (offsite) that handles anti-spam for us; they also send back in on the same range of IP addresses and we have our hardware firewall set to only allow SMTP in from that range.

Our internal domain is domain.local, for sake of this discussion.

Our best practice has always been to leave the DEFAULT receive connector alone, with the except of taking out 0.0.0.0-255.255.255.255 from the network and just specifying our local subnet (192.168.0.x) in here.  We understand the DEFAULT connector is for Exchange servers to talk to each other.  We do not touch the FQDN here as this appears to be a no-no and will break Exchange servers from talking to each other.

We then setup a second receive connector which we'll call "Receive from Internet".  In here we set the network to be 0.0.0.0-192.167.255.255 and 192.169.0.0-255.255.255.255.  We set proper authentication and security and DO set the correct external FQDN here (mail.domain.com.)  

We receive the 12014 STARTTLS error on the default receive connector, and presumably this is only while the old 2007 box is still around.

I couldn't find a good article explaining how Exchange 2007 and 2010 talk to each other in this situation, so I wasn't comfortable unchecking TLS or any other authentication methods on the box.

Any suggestions?  Thanks.
0
Comment
Question by:dipersp
  • 5
  • 5
10 Comments
 
LVL 18

Expert Comment

by:Chris
ID: 40294741
if you are getting TLS errors then you need to make sure the FQDN thats specified in the connector is included in the certificate or you change the FQDN on the connector to match whats on the certificate. make sure there is a matching dns record and you shouldn't get any errors
0
 
LVL 9

Author Comment

by:dipersp
ID: 40294746
The FQDN is exchange.domain.local.  My understanding is that you are NEVER to change the FQDN of the default receiver or it will break internal communications between Exchange servers.  Additionally, you're no longer allowed to have .LOCAL extensions on certs.
0
 
LVL 18

Expert Comment

by:Chris
ID: 40296282
it is best practise not to change that but you can create additional SSL certs with the correct values in and attach to SMTP so that way you can have a certificate that should only be presented to the external mail connections.

the best reason to not to have internal domain names is when you have no mail gateway sitting between you and external mail services as you don't want to expose your internal CA details.

The other reason is changes in architecture once you get to exchange 2013 they are trying to unify the name spaces to make it simpler so it would only be mail.external.com
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
LVL 9

Author Comment

by:dipersp
ID: 40298652
Not sure how to create an additional SSL cert since .LOCAL is no longer allowed on a cert. . .  Additionally, I don't need to present the DEFAULT connector to external mail connections - as far as I know, default is only used for intrasite communications between Exchange servers.  No?
0
 
LVL 18

Expert Comment

by:Chris
ID: 40298736
not really sure what you mean by .local not being allowed on a cert?
if you are getting it signed externally then that might be the case but you would use an internal CA to sign this certificate and then its fine.

The default will be used by anything that isn't cover by the scope of another connector.
0
 
LVL 9

Author Comment

by:dipersp
ID: 40298913
See below re internal domains -

http://support.godaddy.com/help/article/6935/phasing-out-intranet-names-and-ip-addresses-in-ssls

I'd prefer not to have to setup an internal CA just to have one cert for the default receive connector.  What I'm really looking for is more information on the default receive connector and what it's really used for.  If it's only internal communications between Exchange servers, does it even need TLS?  I'm guessing not, since we don't have a proper cert on there now.
0
 
LVL 18

Expert Comment

by:Chris
ID: 40300413
ah ok understand now.

I would always have an internal setup and the internal hub servers being signed by an internal CA certificate (IIS and SMTP) then with an edge server on in a DMZ so none of the internal certificates are exposed to the outside world. But if you don't already have internal PKI then thats a lot of effort

The internal mail flow would be Opportunistic TLS so if it can support it then it will use it.
Do you have the Self Signed Cert that is there by default as this would cover it?
If you uncheck TLS and leave at either Exchange server authentication or Basic then there should be no issues.
0
 
LVL 9

Author Comment

by:dipersp
ID: 40313497
I'll give that a try in our lab, thanks.  No self-signed cert.  I think only SBS has that. . .
0
 
LVL 18

Accepted Solution

by:
Chris earned 2000 total points
ID: 40313868
good plan. all exchange 2010 installs will setup a self signed cert and by default its attached to SMTP
0
 
LVL 9

Author Closing Comment

by:dipersp
ID: 40339898
Haven't had a chance to test yet, but wanted to accept for the time/help given.
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I am posting this in case anyone runs into similar issues that I did, this may save you a lot of grief: Condition: 1. Your NetBIOS domain name contains an ampersand " & " character.  (e.g. AT&T) 2. You've tried to run any Microsoft installation…
Mailbox Corruption is a nightmare every Exchange DBA wishes he never has. Recovering from it can be super-hectic if not entirely futile. And though techniques like the New-MailboxRepairRequest cmdlet have been designed to help with fixing minor corr…
The basic steps you have just learned will be implemented in this video. The basic steps are shown to configure an Exchange DAG in a live working Exchange Server Environment and manage the same (Exchange Server 2010 Software is used in a Windows Ser…
Nobody understands Phishing better than an anti-spam company. That’s why we are providing Phishing Awareness Training to our customers. According to a report by Verizon, only 3% of targeted users report malicious emails to management. With compan…
Suggested Courses

569 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question