none
WMSvc Certificate - SMTP RRS feed

  • Question

  • Just for some background first... I am on a development team for an application that will access/send mail on an Exchange server through IMAP and SMTP. The exchange server sits on a completely private network, so I don't have to worry about getting a Verisign (or other vendor) certificate, or even producing my own (or so I've been told).

    The server is Exchange 2007, and as it is delivered to me by the CM folks, it already has an Exchange-generated self-signed certificate called "WMSvc-myserver". The actual server's FQDN is "myserver.company.com".

    I have exported this certificate and placed it into the truststore of my application. At this point, I can successfully access an account via IMAP, but SMTP fails. Looking at the Exchange server's event logs, I see this error:

    "Microsoft Exchange could not find a certificate that contains the domain name myserver.company.com in the personal store..."

    The message then goes on about being unable to perform START TLS SMTP due to this error.

    I performed a "Get-ExchangeCertificate" command, and saw a list of one certificate (this same WMSvc-myserver), and it is set for the following services: IP.WS (I'm assuming that's IMAP, POP, WEB, and SMTP).

    Looking at the certificate itself, it says that the Common Name (CN) is "WMSvc-myserver". With my admittedly novice knowledge of PKI certificates and SSL, doesn't the CN field need to match the FQDN? But then IMAP is working over SSL without a hitch...

    Anyway, does anyone have any input here? This project has been the first contact that I have had with Exchange, so I am at a loss as to what to do next. I would just disable TLS for SMTP altogether, but we have a requirement for it.

    Thanks!

    Monday, October 15, 2012 10:17 PM

Answers

  • On Mon, 15 Oct 2012 23:00:35 +0000, dougman82 wrote:
     
    >
    >
    >Update:
    >
    >On the receive connector (Client myserver), I set the FQDN value to the certificate's CN (WMSvc-myserver), and then rebooted the Exchange server. Now, that error does not come up in the event logs anymore.
    >
    >
    >
    >However, SMTP is still failing from the client. In the same receive connector settings window (in the Exchange Management Console), on the Authentication tab, I have the following boxes checked:
    >
    >- Transport Layer Security (TLS) - Basic Authentication - Offer Basic authentication only after starting TLS
    >
    >If I uncheck that third option, SMTP access works fine. When I check it, no go, without any message in the Exchange event log.
     
    Check the SMTP Receive protocol log. Is the STARTTLS keyword being
    offered after your client sends the EHLO command to Exchange?
     
    Note that the SMTP client has to use ESMTP (i.e. issue the EHLO
    command), not SMTP (i.e. issue the HELO command) when it initiates the
    session.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Tuesday, October 16, 2012 7:24 PM

All replies

  • Ok, further searching, I finally found this page:

    http://www.mikepfeiffer.net/2010/04/troubleshooting-event-id-12014-in-exchange-20072010/

    On that page, it says to compare the results of the following two commands: "Get-SendConnector | fl fqdn" and "Get-ExchangeCertificate | fl CertificateDomains"

    Doing so, I noticed that with the first command, the FQDN field is blank. For the second command, "WMSvc-myserver" is listed.

    So, I went into the Exchange Management Console and navigated to the "Client myserver" receive connector under Hub Transport (this is where I have verfied such settings as port numbers, and enabling TLS and basic authentication). Under the "General" tab, there is a field for "Specify the FQDN this connector will provide in response to HELO or EHLO". For this, I have "myserver.company.com". I have attempted to change this value to "WMSvc-myserver" (the CN of the certificate), but that made no difference.

    Why would the fqdn field be blank? Or was that webpage incorrect to direct me to use "Get-SendConnector" instead of "Get-ReceiveConnector"?

    Monday, October 15, 2012 10:37 PM
  • Update:

    On the receive connector (Client myserver), I set the FQDN value to the certificate's CN (WMSvc-myserver), and then rebooted the Exchange server. Now, that error does not come up in the event logs anymore.

    However, SMTP is still failing from the client. In the same receive connector settings window (in the Exchange Management Console), on the Authentication tab, I have the following boxes checked:

    - Transport Layer Security (TLS)
    - Basic Authentication
    - Offer Basic authentication only after starting TLS

    If I uncheck that third option, SMTP access works fine. When I check it, no go, without any message in the Exchange event log.

    Monday, October 15, 2012 11:00 PM
  • On Mon, 15 Oct 2012 23:00:35 +0000, dougman82 wrote:
     
    >
    >
    >Update:
    >
    >On the receive connector (Client myserver), I set the FQDN value to the certificate's CN (WMSvc-myserver), and then rebooted the Exchange server. Now, that error does not come up in the event logs anymore.
    >
    >
    >
    >However, SMTP is still failing from the client. In the same receive connector settings window (in the Exchange Management Console), on the Authentication tab, I have the following boxes checked:
    >
    >- Transport Layer Security (TLS) - Basic Authentication - Offer Basic authentication only after starting TLS
    >
    >If I uncheck that third option, SMTP access works fine. When I check it, no go, without any message in the Exchange event log.
     
    Check the SMTP Receive protocol log. Is the STARTTLS keyword being
    offered after your client sends the EHLO command to Exchange?
     
    Note that the SMTP client has to use ESMTP (i.e. issue the EHLO
    command), not SMTP (i.e. issue the HELO command) when it initiates the
    session.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Tuesday, October 16, 2012 7:24 PM