STARTTLS issue, related to "Invalid" certificate

Question

Hi,
We have an issue on one of our CAS servers that is not allowing STARTTLS. We have tracked this down to an invalid certificate. In fact I believe it is the certificate that is created when you install Exchange.
On each server we have two certificates, the second of which is the one that we use for Exchange web services etc. This one is working fine and mail flow and webmail etc. are not affected.
However when one of our Linux boxes lands on this server it does not offer TLS. The other two services do.
A screenshot from a working server
And one from the non-working server.
The receive connectors are configured with the servers "internal" DNS name i.e. WSR-EXCAS-101.mrc-cbsu.local and therefore does not find a valid certificate.
So the questions for me are:
1. Why would this certificate, that has not expired, become invalid?
2. How do I create a new self signed certificate for only SMTP while leaving the other certificate in place for all other services such as webmail?
My apologies if these seem like easy questions but I always feel a certain amount of unease when dealing with certificate questions! :-)
Howard Gyton

Answer 1

Hi,
Yes, I spoke to my colleague and he said he installed no certificates on that web server. He would have had to have installed 3 as well as you would need each of the self signed certs on each CAS server. He distinctly remembers not doing that.
Ordinarily they would use the FQDN of the CAS array. However for now we are pointing it at one of the individual hosts instead as it will sometimes land on the server with the issue.
So whether they connect to the CAS array DNS name or the individual servers host name it still works for 2 of the three, even without a cert installed on the web server.
As a quick test to prove this hypothesis I created a new Receive Connector on the server with the issue. Configured the same way as the other one that it would be using but I configured its remote server settings to only be the IP address of my desktop and
I also altered its FQDN from what it would ordinarily be, wsr-excas-101.mrc-cbsu.local to cas.mrc-cbu.cam.ac.uk, which is the FQDN of the CAS array and has a matching cert on the server. I then connected via PuTTY to port 25 on that server. It announces
itself as cas.mrc-cbu.cam.ac.uk and when I type EHLO I get the following:
250-cas.mrc-cbu.cam.ac.uk Hello [172.31.x.x]
250-SIZE 10485760
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH NTLM
250-8BITMIME
250-BINARYMIME
250 CHUNKING
Hey presto, STARTTLS is now available, simply because it has a matching cert and since I am using PuTTY to connect it wouldn't matter if I had the cert installed on my desktop or not because PuTTY would not be aware of it.
EDIT: Just a quick update. I found another article regarding the creation of self-signed certificates for Exchange and it was easier than I suspected it would be. I had originally looked to go down the route of creating a CSR and having one of our Linux
boxes create it but it was easier than that.
I opened a Powershell session on the Exchange server and ran the command:
New-ExchangeCertificate
It then asks me if I want to overwrite the existing certificate, the OWA one that we use, and I say no. It then creates a new certificate, with exactly the right name which is only assigned to SMTP.
When I now telnet to that box I get the following:
250-WSR-EXCAS-101.mrc-cbsu.local Hello [172.31.x.x]
250-SIZE
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-X-ANONYMOUSTLS
250-AUTH NTLM
250-X-EXPS GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250-XEXCH50
250-XRDST
250 XSHADOW
TLS is now available once more. I still have no explanation as to why it became invalid in the first place but this also shows that you don't need to have the certificate installed anywhere else either. We have yet to test this in anger on our Linux server
as we need to wait for a maintenance window but I am reasonably confident that this will have fixed the issue.