There is no valid SMTP Transport Layer Security (TLS) certificate
Hi We are running Exchange 2007 SP1 on Windows 2008 SP2 servers. Our HQ is SiteA, and contains Mailbox, Hub Transport and CAS servers. We have multiple AD sites, each with their own Hub Transports, and the HQ Hubs also have legacy routing group connectors to 2003 Bridgehead servers. I have noticed the following error on some of the Hubs: There is no valid SMTP Transport Layer Security (TLS) certificate for the FQDN of Hub1.domain.com. The existing certificate for that FQDN has expired. The continued use of that FQDN will cause mail flow problems. A new certificate that contains the FQDN of Hub1.domain.com should be installed on this server as soon as possible. You can create a new certificate by using the New-ExchangeCertificate task. However, we aren't having any mail flow issues from what I can see. Do we need to do anything and, if so, what? :-)
April 28th, 2010 11:57pm

Yes, run the new-exchangecertificate command whick will automatically create and apply the Exchange Self-signed to the SMTP service. You arent using 3rd party certs on the hubs yes?
Free Windows Admin Tool Kit Click here and download it now
April 29th, 2010 12:17am

Hi We aren't using 3party certs yet, no - we are using just the Exchange self signed one. Couple of questions on this: i) Can we keep using the Exchange self-signed certificate but set the duration of use for longer than one year (e.g. 2 years etc) ii) How can I find out when the self-signed certificate will actually run out (the error message I am recv'ing indicates that the cert has already run out). iii) What is the effect of this certificate expiring? iv) How can I use a 3rd party one? Thanks Andy!
May 5th, 2010 5:57pm

1) Exchange 2007 SP2 is required. The default cert period for self-signed Exchange Certs is now 5 years ( only after applying SP2!) 2) Issue a get-exchangecertificate |FL and filter on the NotAfter attribute. 3) No SSL - and traffic MAY fail 4) You would have to generate a request and send to the 3rd party. But if this is just for the Hubs and they only do internal traffic, you probably dont need it. http://technet.microsoft.com/en-us/library/bb851505(EXCHG.80).aspx
Free Windows Admin Tool Kit Click here and download it now
May 6th, 2010 11:00pm

Thanks Andy. Just a couple of final questions if that's ok :) i) We have multiple Hub Transports over several AD sites. Am I right in thinking that if we decided to implement 3rd Party certs, then we would have to change them on ALL HT's at the SAME time? ii) Would I be right in thinking that if some HT's are using the Exchange self-signed certs and some 3rd party ones, then the two types won't be able to communicate (i.e. send/recv email) with each other? iii) Are these certs for use only between Hub Transports and other Hub Transports (we don't have Edge). Or are other types of servers/clients involved here as well? Thanks again for the great help!
May 10th, 2010 8:54pm

1) No, you wouldnt have to as long as the certificate is valid. 2) They could communicate with each other as long as the cert was valid :) 3) The cert is used for only those services assigned to it, so if these are HT role only servers, then the cert will only be used for SMTP. Just as reminder, you probably do not need 3rd party certificates on the Hub Transport ONLY role servers unless it is internet facing and you are sending and receiving to external orgs over TLS and you want mutual trust between the servers. HTs that are in sending only to internal HTs are fine with the self-signed Exchange certificate that doesnt cost a thing :) ( Or with an internally created cert using Windows CA services - that doesnt cost a thing)
Free Windows Admin Tool Kit Click here and download it now
May 10th, 2010 9:29pm

Thanks Andy, but I'm not sure I understand how we can use different types of certificates on the Hub Transports in the org? Or perhaps I am not understanding how certificates work with Hub Transport servers?
May 10th, 2010 9:39pm

Because message traffic between HTs is using the certificates simply for encryption. The servers authenticate between themselves using their connectors, but the certs are there for encryption. So when a cert expires, the servers can still authenticate to each other, they just can't use the cert for encryption.
Free Windows Admin Tool Kit Click here and download it now
May 10th, 2010 9:58pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics