none
Exchange 2007 Certificate - Incorrect RRS feed

  • Question

  • Hi People,

    I have a customer with an old exchange 2007 server.

    Recently, when clients attempt to connect they received the autodiscover.domain.co.uk certificate error.

    The name of the security certificate is invalid or does not match the name of the site"

    I have found lots of articles on fixes for this but my problem is slightly different.

    The name on my certificate actually looks incorrect and it is completly different to what my domain is.
    As we do not use OWA i believed I could simply create a new certificate.

    I created a certificate succesfully but I was not sure how I tell Outlook clients and the server to forget the old incorrectly named cert and use the new one.  I tried this article also but with no luck:

    http://support.microsoft.com/kb/940726

    Any ideas?

    Monday, August 19, 2013 11:53 AM

Answers

  • Hi MrNewbie,

    In order to let Outlook use the new certificate, we just need to bind it to the IIS service by the following command:

    Enable-ExchangeCertificate -Thumbprint newcertificatethumbprint -Services " IMAP, POP, IIS"

    For more details:

    http://technet.microsoft.com/en-us/library/aa997231(v=exchg.80).aspx .

    Regards,

    Rebecca

    Tuesday, August 20, 2013 7:01 AM
  • Rich,

    Thanks again for input.

    A few moments ago, I resolved the issue.

    A massive amount of detective work found the following but your comment prompted me to look again and the information that I was being shown:

    https://server.domain.local/autodiscover/autodiscover.xml failed (0x800C8203) 
    This shows up for pretty much all of them. 

    I think i may have another symptom that may mean something to someone. 
    When I attempt to browse ANY of the entries under my default web site within IIS I can ONLY do it by IP address and not by the hostname. 

    e.g 
    If i try to browse to : 
    https://ipaddress/owa - I get the page 
    https://ipaddress/oab - I get the page 
    https://ipaddress/autodiscover/autodiscover.xml - I get the page. 

    HOWEVER 

    If i try to browse to: 

    https://servername/owa - I get no page displayed with a typical error on page message. 
    https://servername/oab - I get no page displayed with a typical error on page message. 
    https://servername/autodiscover/autodiscover.xml - - I get no page displayed with a typical error on page message. 

    First thoughts were DNS so I checked that there was A records and there were. 

    I have tried pinging the hostnames and i get replies 
    I do not have much experience with IIS so not sure what I checks I can run in order to get this working but believe that i need to get this working in order to resolve my autodiscover possibly? 

    I restarted ISS, I have flushed DNS. 

    Then i found that I could access HTTP sites which prompted me to look at bindings and HTTPS.

    That lead me to the following article:

    http://support.microsoft.com/?id=290391

    Although the command line did not work, i went through IIS and deleted the bindings for HTTPS and re-created them and up it all came. Working across the board.

    I suspect the last IT people incorrectly configured it or that some went wrong when the certificate expired.

    Thank you for your input and taking the time to come back with further comments.
    Its is people like you that make the web work! :)

    • Marked as answer by MrNewbie Friday, November 15, 2013 11:29 AM
    Friday, August 23, 2013 8:41 PM

All replies

  • You need to use the "Enable-ExchangeCertificate" cmdlet.

    --- Rich Matheisen MCSE&I, Exchange MVP

    Tuesday, August 20, 2013 3:18 AM
  • Hi MrNewbie,

    In order to let Outlook use the new certificate, we just need to bind it to the IIS service by the following command:

    Enable-ExchangeCertificate -Thumbprint newcertificatethumbprint -Services " IMAP, POP, IIS"

    For more details:

    http://technet.microsoft.com/en-us/library/aa997231(v=exchg.80).aspx .

    Regards,

    Rebecca

    Tuesday, August 20, 2013 7:01 AM
  • Thank you for the reply Rich and Rebecca.

    I followed the steps detailed and successfully ran the Enable-ExchangeCertificate -Thumbprint newcertificatethumbprint -Services " IMAP, POP, IIS" command ensuring that my thumbprint matched.  

    Unfortunately I still appear to have the problem though as when I go into Outlook the clients all receive the name on the certificate does not match.  autodiscover.emildomain.co.uk

    Should the autodiscover.xml file actually contain anything?  Mine appears to show a placeholder??

    Any further advice greatly received!

    Tuesday, August 20, 2013 7:45 AM
  • Also another observation.... the certificate that the client receives does not appear to be internally signed as it actually talks about it being issued in January this year.  Should this not say something about it being internally generated today?
    Tuesday, August 20, 2013 7:48 AM
  • Also another observation.... the certificate that the client receives does not appear to be internally signed as it actually talks about it being issued in January this year.  Should this not say something about it being internally generated today?
    Steps Taken:

    Get-ExchangeCertificate |fl
    This displayed a number of certificates with recent dates which are the result of my attempt to get the certificate to be accepted.

    One of these certificates had expired around the date that I started to encounter issues.  Therefore i decided that I would copy this certificates settings and create a new one.  
    I did this by running the following command and the thumbprint of the expired certificate.

    Get-ExchangeCertificate –Thumbprint “9E6DD4B4EA2865CA9E6C34B42329A9AC994EBF63” | New-ExchangeCertificate

    This succesfully created a new certifcate which I noted down the thumbprint of.

    I then wanted to apply the certificate to exchange so I ran the following:

    Enable-ExchangeCertificate -Thumbprint newcertificatethumbprint -Services " IMAP, POP, IIS"

    Having succesfully ran this command I opened my outlook client to see if the I received the security alert which stated 'autodiscover.domain.co.uk' - The name on the security certificate is invalid or does not match the name of the site.

    On selecting 'View Certificate' I can see that the valid from date is from January and expires in 2015.  I can also see that it says it was issued by COMODO SSL CA.  Clearly this is not the self signed cert.

    Any advice or comments welcome, I will happily investigate!
    Tuesday, August 20, 2013 10:29 AM
  • If you run "get-exchangecertificate newcertificatethumbprint | fl CertificateDomains, Services" do you see IMAP, POP, and IIS in the "Services" property?

    Verify that the thumbprint you're supplying in the cmdlet is the right one.

    This should show you any certificate that's self-signed:

    get-exchangecertificate | where {$_.IsSelfSigned} | ft Thumbprint,Services,Issuer,NotAfter -auto


    --- Rich Matheisen MCSE&I, Exchange MVP

    Wednesday, August 21, 2013 1:06 AM
  • Hi Rich,

    Thanks again for coming back I ran the command and it shows IMAP,POP,IIS, SMTP

    I have since discovered that the users have two issues:

    1. pop up certificate message - this could be related to something else as it is not for the correct domain ag all.  I think this might be confusing the issue.

    2. The clients cannot put out of office on as the server is not available.  I think this is the key!.  What can i do to ensure that the certificate being used has all the entries relating to the server?

    Wednesday, August 21, 2013 7:31 AM
  • Yet another update....

    I was looking at an article that seems to refer to an error that I am seeing and it says to resolve the issue that you should run the following commands:

    value="3082">Spanish</option>  </select>
    Details
    Product: Exchange
    Event ID: 12014
    Source: MSExchangeTransport
    Version: 8.0
    Symbolic Name: CannotLoadSTARTTLSCertificateFromStore
    Message: Microsoft Exchange couldn't find a certificate that contains the domain name %1 in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector %2 with a FQDN parameter of %1. If the connector's FQDN is not specified, the computer's FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.
       
    Explanation

    This Warning event indicates that there is a problem loading a certificate to be used for STARTTLS purposes. Generally, this problem occurs if one or both of the following conditions is true:

    • The fully qualified domain name (FQDN) that is specified in the Warning event has been defined on a Receive connector or Send connector on a Microsoft Exchange Server 2007 transport server, and no certificate is installed on the same computer that contains the FQDN in the Subject or Subject Alternative Name fields.

    • A third-party or custom certificate has been installed on the server and it contains a matching FQDN. However, the certificate is not enabled for the SMTP service.

    Transport Layer Security (TLS) functionality requires that a valid certificate is installed in the computer's personal certificate store.

       
    User Action

    To resolve this warning, perform the following steps:

    1. Examine the configuration of the certificates installed on the Exchange server and the configuration of all Receive connectors and Send connectors installed on the server. The following commands are used to view the configuration:

      Get-ExchangeCertificate | FL *

      Get-ReceiveConnector | FL name, fqdn, objectClass

      Get-SendConnector | FL name, fqdn, objectClass

    </form>

    When I do this the receive connector comes back with the name of the server.domain.local

    However, when I run the sendConnector i get just a name that does not relate to anything.  Could this be the problem?

    I then browsed into Exchange Mangement Console > Organisation Configuration>Send Connectors and found the entry but the question is, should I change this to match server.domain.local??


    • Edited by MrNewbie Wednesday, August 21, 2013 12:01 PM
    Wednesday, August 21, 2013 12:00 PM
  • If you use OWA do you get a certificate warning, too? If so, use the browser and examine the certificate. Does it have the same thumbprint? The same serial number? The same subject? What's the URL you browsed to to get to OWA?

    Is the certificate a SAN/UCC certificate? What are the Subject Alternative Names on the certificate?

    You need to find out what cert is being used, not just what certs are installed on the machine.

    Do you have your own certificate authority? If so you can create the CSR on the Exchange server and have the CA issue the certificate. You can put as many SANs on the cert as you like.


    --- Rich Matheisen MCSE&I, Exchange MVP

    Thursday, August 22, 2013 1:17 AM
  • That has nothing to do with the problems your users are having. It only means that you can't use TLS when you send e-mail using SMTP.

    The name on your send connector is what it sends in the HELO/EHLO command when it initiates a SMTP session.

    If your server is named x.domain.local and the name on the send connector is y.domain.com the y.domain.com may match the name in the PTR record for your external IP address, or it may match the "A" record you use in your MX record.


    --- Rich Matheisen MCSE&I, Exchange MVP

    Thursday, August 22, 2013 1:35 AM
  • If you use OWA do you get a certificate warning, too? If so, use the browser and examine the certificate. Does it have the same thumbprint? The same serial number? The same subject? What's the URL you browsed to to get to OWA?

    Is the certificate a SAN/UCC certificate? What are the Subject Alternative Names on the certificate?

    You need to find out what cert is being used, not just what certs are installed on the machine.

    Do you have your own certificate authority? If so you can create the CSR on the Exchange server and have the CA issue the certificate. You can put as many SANs on the cert as you like.


    --- Rich Matheisen MCSE&I, Exchange MVP

    OK some further information as I have found out more information:

    The company in question (companyA) did not have a website until fairly recently and therefore pointed website traffic to another company (companyB).  When i was running the exchange connectivity test I found that it failed and after much investigation I discovered that there is a wildcard setup for all traffic to go to (companyB).  So in effect:  autodiscover.companyA.com would actually go to (companyB).

    (company A) now has its own website and traffic going to (companyA.co.uk) reaches the site as expected.
    We are in the process of gaining all the details to remove the wildcard from public DNS.

    This is part was what i was getting confused with. The prompt being received by the user that a certificate name was incorrect when opening Outlook internally was the result of Outlook querying autodiscover.companya.com and getting a wildcard redirect to (companyB). 

    I currently understand the process that a locally installed copy of office 2007 follows is:

    1. Query from Outlook 2007 goes to Connection Point (SCP) Object on AD.

    2. Autodiscover service returns URL

    3. Outlook 2007 connects using HTTPS

    4. Autodiscover service returns addresses of available services.

    ============

    At the moment 'out of office' does not work for clients.

    Am i correct in saying that this should work for clients if the internal certificate is setup EVEN if the external DNS is wrong.

    If so, what are the steps I should perform in order to confirm the internal certificate has been created successfully as something is clearly not correctly configured at the moment?

    I am confident to create a certificate manually and edit it accordingly but my attempts so far have not fixed the out of office issue so I am wondering if I am still missing something. 


    Thursday, August 22, 2013 10:07 AM
  • Have a look at the data returned for a client connected internally to their mailbox when they Ctrl+Right-Click on the Outlook icon in their "tray" (aka notification area) and then on "Test E-mail AutoConfiguration". Uncheck the two "Guessmart" boxes and click "Test". Is the OOF URL what you expected it to be? The "XML" tab has even more detailed information.

    Really, it looks like you have mismatched expectations. Do you have an internal and external DNS? Do the direct e-mail clients to the correct IP addresses based on their location (internal vs. eternal)?


    --- Rich Matheisen MCSE&I, Exchange MVP

    Thursday, August 22, 2013 10:10 PM
  • Rich,

    Thanks again for input.

    A few moments ago, I resolved the issue.

    A massive amount of detective work found the following but your comment prompted me to look again and the information that I was being shown:

    https://server.domain.local/autodiscover/autodiscover.xml failed (0x800C8203) 
    This shows up for pretty much all of them. 

    I think i may have another symptom that may mean something to someone. 
    When I attempt to browse ANY of the entries under my default web site within IIS I can ONLY do it by IP address and not by the hostname. 

    e.g 
    If i try to browse to : 
    https://ipaddress/owa - I get the page 
    https://ipaddress/oab - I get the page 
    https://ipaddress/autodiscover/autodiscover.xml - I get the page. 

    HOWEVER 

    If i try to browse to: 

    https://servername/owa - I get no page displayed with a typical error on page message. 
    https://servername/oab - I get no page displayed with a typical error on page message. 
    https://servername/autodiscover/autodiscover.xml - - I get no page displayed with a typical error on page message. 

    First thoughts were DNS so I checked that there was A records and there were. 

    I have tried pinging the hostnames and i get replies 
    I do not have much experience with IIS so not sure what I checks I can run in order to get this working but believe that i need to get this working in order to resolve my autodiscover possibly? 

    I restarted ISS, I have flushed DNS. 

    Then i found that I could access HTTP sites which prompted me to look at bindings and HTTPS.

    That lead me to the following article:

    http://support.microsoft.com/?id=290391

    Although the command line did not work, i went through IIS and deleted the bindings for HTTPS and re-created them and up it all came. Working across the board.

    I suspect the last IT people incorrectly configured it or that some went wrong when the certificate expired.

    Thank you for your input and taking the time to come back with further comments.
    Its is people like you that make the web work! :)

    • Marked as answer by MrNewbie Friday, November 15, 2013 11:29 AM
    Friday, August 23, 2013 8:41 PM