I have a client with a SBS2008 server, so Exchange 2007 is the email software. Everything was running fine until a self-signed TLS cert expired and then we rebooted the server for maintenance, the Exchange Transport service would not start. When the server came back up, everything worked except outbound mail. Users were getting messages that their outbound emails were delayed on the server. Server logs showed:
"There is no valid SMTP Transport Layer Security (TLS) certificate for the FQDN of <server.domain.local>. The existing certificate for that FQDN has expired."
- (I changed the domain name to protect client anonymity)
- Outbound email uses Postini via Private DNS

I renewed the self signed cert through Exchange Management Shell and I believe that part worked without a problem. Rebooted the server and I'm still not getting any outbound mail flowing. Postini reports they see no problem on their end.

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.

No. the old cert is still there. Actually, there were two certs that had expired. One that was "remote.domain.com" and the other was the fqdn of "sbs.domain.local". I renewed them both just in case, even though I know we're not using the name "remote" anywhere.

when you run get-exchangecertificate I'm guessing there are multi thumbprints there. Is the new cert enabled for IIS

0

AJ524Author Commented: 2011-09-09

The new cert is not enabled for IIS, but then again, neither was the old one. The IIS cert is a 3rd party cert which we purchased so that mobile devices and web browsers wouldn't panic when connecting for remote mail, etc.

0

AJ524Author Commented: 2011-09-09

The new cert is set up for IMAP, POP and SMTP

0

AJ524Author Commented: 2011-09-09

Quick update... ran the mail flow troubleshooter and it says that Cannot contact the external DNS server. Postini's outbound email filtering relies on private DNS and a valid TLS cert to complete the connection, so just another sign pointing the cert.

[PS] C:\Users\exchadmin\Desktop>Enable-ExchangeCertificate THUMB-PRINT-4F6CFB
cmdlet Enable-ExchangeCertificate at command pipeline position 1
Supply values for the following parameters:
Services: smtp, pop, imap
WARNING: This certificate will not be used for external TLS connections with an
FQDN of 'sbs08.domain.local' because the CA-signed certificate with
thumbprint 'THUMB-PRINT-0F646A' takes precedence. The
following connectors match that FQDN: Default sbs08, Reinjection.

So it turns out, the cable company had supplied the client with a new commercial cable modem late last night and I was not informed. The cable company misconfigured the cable-modem with a set of rules usually applied to residential clients, particularly, the blocking of outbound port 25.

This became apparent to me when I removed the private DNS configuration and tried connecting to recipient mail servers directly using the exchange mail flow test suite and was still unable to connect. I then did what I should have done from the beginning... open a command line and telnet to one of those recipient mail servers directly. My connection attempt was blocked and when I then tried connecting to the ISP's own SMTP server, that worked, so the source of my misery was then obvious.

I called the ISP, explained the problem, they confirmed my suspicion and re-provisioned the cable-modem properly and the mail queue immediately emptied. Thank you very much for your help, JohnGrunwell.

Andrew

0

AJ524Author Commented: 2011-09-09

Short version: It was the ISP blocking port 25 after setting up a new cable modem the night before. Wish the client had mentioned that.