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

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 319
  • Last Modified:

Cert problem on Exchange 2010

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
billherde
Asked:
billherde
  • 8
  • 2
  • 2
1 Solution
 
Adam BrownSr Solutions ArchitectCommented:
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
 
billherdeAuthor Commented:
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
 
Simon Butler (Sembee)ConsultantCommented:
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
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

 
billherdeAuthor Commented:
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
 
Adam BrownSr Solutions ArchitectCommented:
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
 
billherdeAuthor Commented:
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
 
billherdeAuthor Commented:
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
 
Simon Butler (Sembee)ConsultantCommented:
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
 
billherdeAuthor Commented:
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
 
billherdeAuthor Commented:
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
 
billherdeAuthor Commented:
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
 
billherdeAuthor Commented:
Thanks to all those who contributed.  Turns out I was looking in all the wrong places.
0

Featured Post

Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

  • 8
  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now