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.
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.
ASKER
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.
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.
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.
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.
ASKER
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?
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?
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.
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.
ASKER
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......
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......
ASKER
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?
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?
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.
Simon.
ASKER
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 **************************
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 **************************
ASKER
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
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks to all those who contributed. Turns out I was looking in all the wrong places.
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)