Solved

Cert problem on Exchange 2010

Posted on 2014-03-19
12
305 Views
Last Modified: 2014-03-25
I have two exchange servers in a single domain that share a DAG across a WAN.  
Both have matching settings for receive connectors, and of course share the same send connector.  
The same SAN certificate from GoDaddy is installed on both servers, and enabled for POP, IMAP,SMTP,IIS. get-exchangecertificate returns the same cert on both machines, with the same services enabled.
Both servers are able to send and receive mail through a smarthost without SSL working. Using fixyourip.com to view web certificates, both respond immediately and display the cert.
Using fixyourip.com to view the mail cert, one of them does not respond.  The net impact is TLS will not work through this server.  It comes back as 'not enabled' when testing the connection with things like MXtoolbox.
I need it to work.
I need help.
0
Comment
Question by:billherde
  • 8
  • 2
  • 2
12 Comments
 
LVL 38

Expert Comment

by:Adam Brown
ID: 39940561
Check the configuration on your Receive connectors. You should make sure that the connectors are all publishing a name that matches your SSL certificate. Open the properties of your receive connectors and enter one of the names on your SAN as what the server will use in response to HELO EHLO commands.

In addition, check the Authentication Tab on all your connectors to make sure TLS is checked on them. (but not necessarily the Domain Auth TLS option)
0
 
LVL 3

Author Comment

by:billherde
ID: 39940671
I have verified that the name in the receive connector matches the name assigned for the IP address, and it is listed as one of the names in the certificate, and it also matches RDNS lookup.  On the authentication tab TLS is checked, and I tried it with and without Domain Auth checked.

Just now I have gone back through the steps assigning services to the certificate, but not completely removing and reinstalling it. (It complained that it was already there and done)  From management console I can view the cert and verify it is the same one on both machines.

I have also gone through the firewall access rules from both sites side by side, and they both have the same ports open.
0
 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
ID: 39941946
The receive connector doesn't need a trusted SSL certificate to work properly.
The FQDN on the connector in this scenario can only be one of the following:
- the real FQDN of the server
- the NETBIOS name of the server
- blank.

As you cannot have internal names on SSL certificates, the easiest way round this is to simply create a new internal certificate for SMTP traffic use only.

On each server, type new-exchangecertificate, no other switches required. It will prompt to replace the default SMTP certificate. Say yes to that. Leave the existing trusted certificate in place. You should find TLS works at that point.

Simon.
0
 
LVL 3

Author Comment

by:billherde
ID: 39943071
Thanks Simon, but it is still not working.
The self-signed cert that was there was still good.  I renewed it anyway, and the results are the same.

The only other thing that I am finding different between the two servers is for the bad one MXtoolbox SMTP reverse DNS mismatch says that reverse DNS does not match the SMTP banner.  This is curious to me since the response to ehlo first comes back with the same name that displays when doing a RDNS lookup. The SMTP Reverse banner check also confirms the IP resolves to the same name.

Is this possibly a clue?
0
 
LVL 38

Expert Comment

by:Adam Brown
ID: 39943249
Ah. If you're using a self-signed cert, attempts to validate the certificate will fail, which is something the MXToolbox tool checks. If it doesn't trust the cert you're using for TLS on your Receive connector it will tell you TLS is not enabled. There are a couple requirements for TLS certificates to be validated:

1. The certificate must have a Common Name or Subject Alternate name that exactly matches the FQDN used to connect to the server.
2. The Certificate Authority that issued the certificate must be trusted by the server that initiates the session (The sending server in this case).

If either of these requirements are not met, the sender can't authenticate the receiving server, meaning it has no way of knowing for sure that the server it's sending to is an authorized server.

That said, TLS will still work if your certificate is not properly validated. TLS sessions will still be encrypted, but they won't be authenticated, which means you won't be able to force TLS communication between your environment or anyone else's. You will only be able to take advantage of Opportunistic TLS, which means that if both servers in a mail exchange have TLS enabled, they'll use it, but if one does not it won't reject the session.

If you want MXToolbox to show that TLS is valid, you have to purchase a third party CA Certificate from someone like godaddy or network solutions.
0
 
LVL 3

Author Comment

by:billherde
ID: 39943277
The self signed cert is in addition to the public trusted cert.  It is installed by default and I believe is needed for the two servers to talk to each other and keep the DAG in sync. The cert that is presented by the working server is the correct public cert.  The non-working server does not present a cert at all.

The public cert meets the requirements above.

I am wondering if this might have anything to do with this being a failover setup with the DAG and the one that works happens to be the one with the active copy of the database?

Yes I am pulling straws......
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 
LVL 3

Author Comment

by:billherde
ID: 39943335
Okay it is possible the issue may be right in front of my nose.

I was looking into the possible issue with the banner, and while both servers connect, only the working one responds with a banner that says 'service ready'.  Is this normal for a 2 server failover DAG configuration?
0
 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
ID: 39943617
Transport is independent to the DAG. Therefore the fact that the servers are in a DAG is completely immaterial. They should both response to SMTP queries and both should be able to accept email.

Simon.
0
 
LVL 3

Author Comment

by:billherde
ID: 39943937
Simon
I was hoping that was the situation.
I am still unable to get a proper banner from this server, and just for fun I deleted and recreated the receive connector.  I also tried to set the banner response using set-receiveconnector ... -banner and did not get the expected results.  MXtoolbox is returning a "220 *******************************" when running the smtp test, and interestingly the number of stars decreased to the correct number of characters when the banner was manually set. It appears something may be garbling the response.  Placed the call to MSFT and spent the money, now waiting for callback.
0
 
LVL 3

Author Comment

by:billherde
ID: 39944066
Well a few $$$ later it looks like the issue has nothing to do with MSFT.
We are using Cisco ASA firewalls at both locations and one of them appears to have a feature enabled.

http://support.microsoft.com/kb/320027
0
 
LVL 3

Accepted Solution

by:
billherde earned 0 total points
ID: 39944112
Disable mailguard on Cisco ASA firewall.

Open ASDM applet and go to configuration tab.
Select Service Policy Rules and double-click inspection policy.
Select rule actions tab and uncheck ESMTP
OK and save configuration.
Write to flash

Works now
0
 
LVL 3

Author Closing Comment

by:billherde
ID: 39952716
Thanks to all those who contributed.  Turns out I was looking in all the wrong places.
0

Featured Post

What Security Threats Are You Missing?

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

Join & Write a Comment

"Migrate" an SMTP relay receive connector to a new server using info from an old server.
Following basic email etiquette rules will help you write a professional email and achieve a good, lasting impression with your contacts.
In this video we show how to create a Contact in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Recipients >> Contact ta…
This video discusses moving either the default database or any database to a new volume.

758 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

Need Help in Real-Time?

Connect with top rated Experts

19 Experts available now in Live!

Get 1:1 Help Now