[Last Call] Learn how to a build a cloud-first strategyRegister Now

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

Exchange 2007 apparent certificate error

Hi,
This is Exchange Server 2007 running on Windows Server 2003 R2 Standard SP2 x64.
The system has been running since late 2007
In October 2009 I installed a GlobalSign ssl certificate so that mobile workers could use Outlook, some using the https connection to Exchange, some preferring to use Outlook Web Access.
This is still working fine.

However, recently I am getting errors in the Application Event log telling me that the current certificate for this server has expired, and yet the expiry date is clearly marked as October 2011

I should also add here that the status of the certificate has always appeared as 'Invalid' in the managment shell listing from the day it was installed (as shown in one of the attached screen shots)

Because of the recent errors appearing I am now concerned that the system may stop working, so I would like to find and correct this anomaly .

I did of course try to sort this out with Global Sign when the certificate was originally installed, but we failed. I eventually left it because the system was actually working fine.

As always any suggestions are welcomed.
 Management shell listing showing the Invalid status Screen shot showing the certificate status as OK Screen shot confirming the dates for the certificate This Application log entry is now appearing regularly
0
Nick Brown
Asked:
Nick Brown
  • 8
  • 5
1 Solution
 
BusbarCommented:
this is done because the FQDN of the certificate doesn't mach server.bleplantsales.com so either change that name to a name included in the cert or include that name in the cert
0
 
losipCommented:
@busbar: Difficult to tell thru the yellow marker but the name looks right to me: bte-server.bteplantsales.com
0
 
Nick BrownDirectorAuthor Commented:
Hello busbar,

Thanks for your comment.

Actualy the server name is not 'server...'  Is this a special name that has to be used?
In all the places above, the server name listed is the same.

Nick
0
A Cyber Security RX to Protect Your Organization

Join us on December 13th for a webinar to learn how medical providers can defend against malware with a cyber security "Rx" that supports a healthy technology adoption plan for every healthcare organization.

 
BusbarCommented:
in the image it is bte-server.bteplantsales.com :) there is a missing name that wasn't highlighted :D
in both cases the name in the receive connector must be included in the cert
0
 
Nick BrownDirectorAuthor Commented:
Thanks for your comments, to be honest I was actually trying to hide the exact name, but I don't suppose it really matters :)

As far as I can see it is bte-server.bteplantsales.com everywhere.
However, there is also the internal name, which is bte-server.bteplantsales.local
Is this possibly causing the problem?

Nick
0
 
BusbarCommented:
what i the FQDN on the receive connector
0
 
Nick BrownDirectorAuthor Commented:
The receive connector is using the internal name, i.e. bte-server.bteplantsales.local
0
 
BusbarCommented:
then make it one of the names included in the certificate.
0
 
Nick BrownDirectorAuthor Commented:
ok, will that not 'break' the connection to all the internal PCs with Outlook which are also using the internal name?
They can't use the .com name because DNS points to the correct public IP.
0
 
Nick BrownDirectorAuthor Commented:
Sorry, I meant to that there is a spearate self generated certificate coverin the .local name
0
 
BusbarCommented:
this is the FQDN on the receive connector presented to users when sending the hello message, it has nothing related to which name users are connecting
0
 
Nick BrownDirectorAuthor Commented:
I must apologise for my lack of understanding here. But please bear with me. There is another connector that says the response to HELO is the .com name.
This is in the HUB transport under 'Organisation Configuration'

The .local name is in the 'Server Configuration' section, also under HUB transport.

0
 
Nick BrownDirectorAuthor Commented:
Ok, I changed the name on the 'Receive Connector' in the 'Server Configuration' section to match all the others above, i.e. the one ending with .com, which also matches the domain named in the commercial certificate from GlobalSign.

There are other places in 'Server Configuration' where the name used is the .local name. Specifically in Server Properties, on the General TAB the name of the Domain controller servers and catalog servers. This information was automatically inserted at install time.

Everything is still working correctly, just as it was, but of course the errors are still just the same too, i.e. the system says the certificate has expired.

So, I took a closer look myself and I have the solution here. Probably there are many good Exchange Admins out there moderately amused by this, but never mind, here's what was wrong and what fixed it:-

First, the error, as shown above is specific about two things: it says expired, and it refers to the public FQDN (...com)
Fair enough, one of the 4 certificates was indeed expired, and referred to the public FQDN - the last one in the list issued by StartCom.

This, and the further clue that the short listing of get-ExchangeCertificate showed that the currently valid certificate from GlobalSign was only intended for IIS, shown as 'W' in the listing.

So the following three commands were all that were required. Two to remove the expired certificates, and one to generate a new, self signed certificate for the public FQDN. The GlobalSign was, and still is, working for Outlook Web Access and mobile devices.

Remove-ExchangeCertificate -Thumbprint FE69FECE056F3677999052EB67A7757D85447EED
Remove-ExchangeCertificate -Thumbprint BB0E89F501C7837AE5796B86444F785EB877A6A4
new-ExchangeCertificate -DomainName bte-server.bteplantsales.com

No more errors :)
0
 
Nick BrownDirectorAuthor Commented:
I should have looked more carefully at my own question before posting. It wasn't really difficult. And the answer is straightforward, as I've shown it.
The experts probably assumed that I would have done this so were looking at lass obvious solutions.
0

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

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