none
454 4.7.5 certificate validation failure

    Question

  •  

    Hi,

     

    I am using DynDns as my smarthost and everything was working fine....I was able to send and receive from internet addresses....now today, i am receiving internet email, but when I try to send, it fails, and when i look in queue viewer it shows the below error

     

    "451 4.4.0 Primary Target IP address responded with 454 4.7.5 Certificate Validation Failure....Attempted failover to alternative host but that did not succeed. Either there are no alternative hosts or delivery failed to all alternative hosts"

     

    I just don't get it.....the only thing that changed was I added CCR....which shouldnt cause a problem, but since I am in a test lab, i just recreated my entire org over again and still get the same error.

     

    Could it be DynDns.com? could it be my cable internet provider?

     

    Please help!

     

    Thanks,

    Saturday, September 06, 2008 10:24 PM

Answers

  • Dear customer:

     

    I am so glad to know the issue has been solved.

     

    Domain Security uses Transport Layer Security (TLS) with mutual authentication to provide session-based authentication and encryption .With mutual TLS

    authentication, each server verifies the identity of the other server by validating a certificate that is provided by that other server, so when we are not be able to validate the remote certificate , mail flow is interrupted.

     

    1. Disable Domain secure on the Required Send connector.

     

    a).On a Hub Transport server, open the Exchange Management Console, click Organization Configuration, click Hub Transport, and then in the result pane, click

    the Send Connectors tab.

    b).Select the Send connector that sends mail to the domain from which you want to send domain-secured e-mail, and then, in the action pane, click Properties.

    c).On the Network tab, Uncheck Enable Domain Security (Mutual Auth TLS), click Apply, and then click OK.

     

    2. We need to figure out the Issue with our's or remote server's SMTP TLS certificate as a validate failure is causing the mailflow to break .

     

    3. At our end we can verify that certificate is Valid, Trusted, enabled for SMTP & indeed the FQDN on the Send connector is same as Certificate's to ensure that

    Certificate is being picked up by send connector.

     

    4. For detail Pre-requesites & troubleshooting, please refer to the Domain secure whitepaper at http://technet.microsoft.com/en-us/library/bb266978.aspx.

     

    Hope it help.

     

    Rock Wang - MSFT

    Monday, September 08, 2008 1:47 AM

All replies

  •  

    hi all,

     

    turns out today my system is back up and running.....my smarthost(dyndns) was having problems with their name servers yesterday.....I am assuming that was the cause of my problem.

     

    I just was wondering if someone can share some info on the best way to troubleshoot that kind of error.....I couldn't find anything online about a 4.7.5 certificate validation failure.

     

    Thanks,

     

    Mike

    Sunday, September 07, 2008 5:13 PM
  • Dear customer:

     

    I am so glad to know the issue has been solved.

     

    Domain Security uses Transport Layer Security (TLS) with mutual authentication to provide session-based authentication and encryption .With mutual TLS

    authentication, each server verifies the identity of the other server by validating a certificate that is provided by that other server, so when we are not be able to validate the remote certificate , mail flow is interrupted.

     

    1. Disable Domain secure on the Required Send connector.

     

    a).On a Hub Transport server, open the Exchange Management Console, click Organization Configuration, click Hub Transport, and then in the result pane, click

    the Send Connectors tab.

    b).Select the Send connector that sends mail to the domain from which you want to send domain-secured e-mail, and then, in the action pane, click Properties.

    c).On the Network tab, Uncheck Enable Domain Security (Mutual Auth TLS), click Apply, and then click OK.

     

    2. We need to figure out the Issue with our's or remote server's SMTP TLS certificate as a validate failure is causing the mailflow to break .

     

    3. At our end we can verify that certificate is Valid, Trusted, enabled for SMTP & indeed the FQDN on the Send connector is same as Certificate's to ensure that

    Certificate is being picked up by send connector.

     

    4. For detail Pre-requesites & troubleshooting, please refer to the Domain secure whitepaper at http://technet.microsoft.com/en-us/library/bb266978.aspx.

     

    Hope it help.

     

    Rock Wang - MSFT

    Monday, September 08, 2008 1:47 AM
  • I am so glad to know the issue has been solved??

    how to solve it ?

    Friday, August 13, 2010 5:57 AM
  • Dear Mike,

    Currently i'm facing the same problem, i will contact DYNDNS for clarification.  All my mail are in the Queues Error message 451 4.4.0 Primary Target IP Address responed with 454 4.7.5  Certificate Validation failure. 

    arnelp

    Monday, October 03, 2011 12:36 PM
  • Dear Mike,

    Currently i'm facing the same problem, i will contact DYNDNS for clarification.  All my mail are in the Queues Error message 451 4.4.0 Primary Target IP Address responed with 454 4.7.5  Certificate Validation failure. 

    arnelp

    I also have the same problem so there's definitely an issue with DynDns. Have turned TLS off for now and they're sending OK :)
    • Proposed as answer by rich120 Monday, October 03, 2011 2:59 PM
    • Unproposed as answer by rich120 Monday, October 03, 2011 2:59 PM
    Monday, October 03, 2011 12:49 PM
  • Dear Mike,

    Currently i'm facing the same problem, i will contact DYNDNS for clarification.  All my mail are in the Queues Error message 451 4.4.0 Primary Target IP Address responed with 454 4.7.5  Certificate Validation failure. 

    arnelp

    I also have the same problem so there's definitely an issue with DynDns. Have turned TLS off for now and they're sending OK :)
    OK, DYNDNS is having issue - Just turn off TLS for the moment and all will be well.
    • Proposed as answer by rich120 Monday, October 03, 2011 2:59 PM
    Monday, October 03, 2011 2:59 PM
  • Aha! And I thought it was me being stupid (I'd changed the IP address of a test server I have, and noticed that outbound emails were queuing...). I also use DynDNS as a smarthost - looks like they're not so smart today! :-D

    David C.

    Monday, October 03, 2011 4:45 PM
  • I am also having this problem today with dyndns mailhop outbound.

    Oli.

    Monday, October 03, 2011 8:49 PM
  • Same here right now. Disabled TLS temporarly, now mails go out without problems. Still I hope they fix it soon, don't want my user data to go out unencrypted.

    Markus, Austria


    • Edited by stoneeh Tuesday, October 04, 2011 8:22 AM
    Tuesday, October 04, 2011 8:16 AM
  • I am having the same too. I was tired enough since morning because of this! I will disable TLS now.
    Tuesday, October 04, 2011 1:38 PM
  • On Tue, 4 Oct 2011 08:16:27 +0000, stoneeh wrote:
     
    >Same here right now. Disabled TLS temporarly, now mails go out without problems. Still I hope they fix it soon, don't want my user data to go out unencrypted.
     
    Their certificate expired. It was replaced yesterday.
     
    They don't even use a trusted cert on their own web page!
    https://status.dyn.com/
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Tuesday, October 04, 2011 6:30 PM
  • Hi Guys,

    I don't have DyDNS. I have the same problem. But in my case I have configured TLS. I know if I disable TLS it will work but there is no option to disable as this is required for sending email to Bank. I have forced the TLS for all the Bank domain (They have 13 Domains). I have added these domain to my Secure send and receive domain list.

    There was already an old CA certificate in exchange with message This certificate is not valid for exchange so that's why I  have bought new SSL certificate for TLS and imported into exchange.. And my old certificate is still in the exchange I haven't removed it from the exchange until I'm sure my new certificate is working fine. . My new certificate is the default certificate.

    I receive the same message in Queue:  "451 4.4.0 Primary Target IP address responded with 454 4.7.5 Certificate Validation Failure....Attempted failover to alternative host but that did not succeed. Either there are no alternative hosts or delivery failed to all alternative hosts"


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.Or please vote as helpful.
    Friday, October 28, 2011 2:05 PM
  • On Fri, 28 Oct 2011 14:05:48 +0000, Mshak wrote:
     
    >
    >
    >Hi Guys,
    >
    >I don't have DyDNS. I have the same problem. But in my case I have configured TLS. I know if I disable TLS it will work but there is no option to disable as this is required for sending email to Bank. I have forced the TLS for all the Bank domain (They have 13 Domains). I have added these domain to my Secure send and receive domain list.
    >
    >There was already an old CA certificate in exchange with message This certificate is not valid for exchange so that's why I have bought new SSL certificate for TLS and imported into exchange.. And my old certificate is still in the exchange I haven't removed it from the exchange until I'm sure my new certificate is working fine. . My new certificate is the default certificate.
    >
    >I receive the same message in Queue: "451 4.4.0 Primary Target IP address responded with 454 4.7.5 Certificate Validation Failure....Attempted failover to alternative host but that did not succeed. Either there are no alternative hosts or delivery failed to all alternative hosts"
     
    That should be telling you there's a problem with THEIR certificate,
    not yours.
     
    In your SMTP Send protocol log you should see the information after
    the "Received certificate". You should be able to use the
    certificate's information to erify (if you know the issuing CA) the
    details of the certificate.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Friday, October 28, 2011 9:59 PM
  • Update

    Thanks Guys for reply, It was weekend here so couldn't test anything.

    We have changed something in our Certificate I think something subject Alternative name. I have enabled the TLS again, and seen some logs in send Connector. I can see the ehlo and other messages between mail servers. Then it asks for TLS and starts the TLS and send the certificate and I can see our certificate CA name and our server names or Alternative names and then certificate received message. But this is with our tired party company not with bank domain. I am not sure in logs if anything happening or it worked fine, I don't know if this is working or not.

    Is there any chance I can you the logs and you can have look?

     


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.Or please vote as helpful.
    Monday, October 31, 2011 12:32 PM
  • On Mon, 31 Oct 2011 12:32:24 +0000, Mshak wrote:
     
    >We have changed something in our Certificate I think something subject Alternative name. I have enabled the TLS again, and seen some logs in send Connector. I can see the ehlo and other messages between mail servers. Then it asks for TLS and starts the TLS and send the certificate and I can see our certificate CA name and our server names or Alternative names and then certificate received message. But this is with our tired party company not with bank domain. I am not sure in logs if anything happening or it worked fine, I don't know if this is working or not.
    >
    >Is there any chance I can you the logs and you can have look?
     
    If ou're sendng your mail through a 3rd-party (i.e. a smart host) then
    the only certificate exchange you'll see is between your server and
    the smart host. It's up to the smart host to send that e-mail using
    TLS to the bank.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Monday, October 31, 2011 6:01 PM
  • HI Rich,

    Thanks for the reply. No I am not using tired party No smart host. I have Exchange 2010 with MB,CAS and HT installed. I used this article to configure TLS

      http://technet.microsoft.com/en-us/library/bb123543.aspx if this will help.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.Or please vote as helpful.
    Tuesday, November 01, 2011 9:12 AM
  • On Tue, 1 Nov 2011 09:12:01 +0000, Mshak wrote:
     
     
    >Thanks for the reply. No I am not using tired party No smart host.
     
    That's what I though you meant when you said "But this is with our
    tired party company not with bank domain".
     
    >I have Exchange 2010 with MB,CAS and HT installed. I used this article to configure TLS
    >
    > http://technet.microsoft.com/en-us/library/bb123543.aspx if this will help.
     
    If, as you say, "I have added these domain to my Secure send and
    receive domain list", try removing them. If their server sends
    STARTTLS as a keyword then your server should send the e-mail using
    TLS.
     
    The KB article describes how to set up mutual TLS and that only works
    if the certificate you're using is trusted by the other MTA and the
    certificate the other MTA is using is trusted by your MTA.
     
    This warning, I think, is important and it isn't emphasized strongly
    enough in that KB article:
     
    "Do not enable strong-key protection on certificates that are intended
    for TLS. Strong-key protection prompts the user every time that the
    private key is accessed. With Domain Security, the user is the SMTP
    service on the Edge Transport server."
     
    Did you note the comment at the end of the page?
     
    "Permission Groups with Mutual Auth TLS"
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Tuesday, November 01, 2011 2:08 PM
  • Hi Rich,

    Thanks for staying with me much appreciated. I have removed those domains from the secure list but my manager is getting a bit annoyed because if I enable TLS then messages don't go out so he said disable it. I have disabled TLS for temp.

    I just enabled the TLS so I can get some logs and post them here. Luckily the same time someone sent an email to the bank. Can you please have a look at this log and tell me if TLS is happening and it’s working. Remember this is not forced TLS. Yes I did notice the note under that article and I have change the permissions.

    This THE BANK email on my send connector.

     

    2011-11-01T15:08:16.139Z,To Internet,08CE66BCB62C56E9,36,10.0.0.16:23261,194.73.118.72:25,-,,Local
    2011-11-01T15:08:55.446Z,To Internet,08CE66BCB62C56F9,0,,193.108.72.62:25,*,,attempting to connect
    2011-11-01T15:08:55.463Z,To Internet,08CE66BCB62C56F9,1,10.0.0.16:23271,193.108.72.62:25,+,,
    2011-11-01T15:08:55.500Z,To Internet,08CE66BCB62C56F9,2,10.0.0.16:23271,193.108.72.62:25,<,220 symailserver.hsbc.co.uk,
    2011-11-01T15:08:55.500Z,To Internet,08CE66BCB62C56F9,3,10.0.0.16:23271,193.108.72.62:25,>,EHLO mail.icwuk.com,
    2011-11-01T15:08:55.516Z,To Internet,08CE66BCB62C56F9,4,10.0.0.16:23271,193.108.72.62:25,<,250-ESMTP Server Ready,
    2011-11-01T15:08:55.516Z,To Internet,08CE66BCB62C56F9,5,10.0.0.16:23271,193.108.72.62:25,<,250-SIZE 52428800,
    2011-11-01T15:08:55.516Z,To Internet,08CE66BCB62C56F9,6,10.0.0.16:23271,193.108.72.62:25,<,250-DSN,
    2011-11-01T15:08:55.516Z,To Internet,08CE66BCB62C56F9,7,10.0.0.16:23271,193.108.72.62:25,<,250-STARTTLS,
    2011-11-01T15:08:55.516Z,To Internet,08CE66BCB62C56F9,8,10.0.0.16:23271,193.108.72.62:25,<,250 TLS,
    2011-11-01T15:08:55.517Z,To Internet,08CE66BCB62C56F9,9,10.0.0.16:23271,193.108.72.62:25,>,STARTTLS,
    2011-11-01T15:08:55.532Z,To Internet,08CE66BCB62C56F9,10,10.0.0.16:23271,193.108.72.62:25,<,220 Server ready Ready to start TLS,
    2011-11-01T15:08:55.532Z,To Internet,08CE66BCB62C56F9,11,10.0.0.16:23271,193.108.72.62:25,*,,Sending certificate
    2011-11-01T15:08:55.532Z,To Internet,08CE66BCB62C56F9,12,10.0.0.16:23271,193.108.72.62:25,*,"CN=icwuk.com, OU=Domain Control Validated, O=icwuk.com",Certificate subject
    2011-11-01T15:08:55.532Z,To Internet,08CE66BCB62C56F9,13,10.0.0.16:23271,193.108.72.62:25,*,"SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O=""GoDaddy.com, Inc."", L=Scottsdale, S=Arizona, C=US",Certificate issuer name
    2011-11-01T15:08:55.532Z,To Internet,08CE66BCB62C56F9,14,10.0.0.16:23271,193.108.72.62:25,*,,Certificate serial number
    2011-11-01T15:08:55.532Z,To Internet,08CE66BCB62C56F9,15,10.0.0.16:23271,193.108.72.62:25,*,7B55B6748B64DF8F63FF,Certificate thumbprint
    2011-11-01T15:08:55.533Z,To Internet,08CE66BCB62C56F9,16,10.0.0.16:23271,193.108.72.62:25,*,icwuk.com;www.icwuk.com;owa.icwuk.com;mail.icwuk.com;autodiscover.icwuk.com;autodiscover.icwuk.local;autodiscover.incorporatewear.co.uk;icwuk.local;inworkwear.com;incorporatewear.co.uk;exchange2010.icwuk.local,Certificate alternate names
    2011-11-01T15:08:55.575Z,To Internet,08CE66BCB62C56F9,17,10.0.0.16:23271,193.108.72.62:25,*,,Received certificate
    2011-11-01T15:08:55.575Z,To Internet,08CE66BCB62C56F9,18,10.0.0.16:23271,193.108.72.62:25,*,0241A7ED0C2E620EB313ADD0486B759F31686C4D,Certificate thumbprint
    2011-11-01T15:08:55.575Z,To Internet,08CE66BCB62C56F9,19,10.0.0.16:23271,193.108.72.62:25,>,EHLO mail.icwuk.com,
    2011-11-01T15:08:55.591Z,To Internet,08CE66BCB62C56F9,20,10.0.0.16:23271,193.108.72.62:25,<,250-ESMTP Server Ready,
    2011-11-01T15:08:55.591Z,To Internet,08CE66BCB62C56F9,21,10.0.0.16:23271,193.108.72.62:25,<,250-SIZE 52428800,
    2011-11-01T15:08:55.591Z,To Internet,08CE66BCB62C56F9,22,10.0.0.16:23271,193.108.72.62:25,<,250 DSN,
    2011-11-01T15:08:55.593Z,To Internet,08CE66BCB62C56F9,23,10.0.0.16:23271,193.108.72.62:25,*,2952458,sending message
    2011-11-01T15:08:55.593Z,To Internet,08CE66BCB62C56F9,24,10.0.0.16:23271,193.108.72.62:25,>,MAIL FROM:<my.user@icwuk.com> SIZE=64578,
    2011-11-01T15:08:55.610Z,To Internet,08CE66BCB62C56F9,25,10.0.0.16:23271,193.108.72.62:25,<,250 +OK Sender OK,
    2011-11-01T15:08:55.610Z,To Internet,08CE66BCB62C56F9,26,10.0.0.16:23271,193.108.72.62:25,>,RCPT TO:<bank.user@hsbc.com>,

    some other company

    2011-11-01T14:57:29.410Z,To Internet,08CE66BCB62C5685,0,,194.73.118.73:25,*,,attempting to connect
    2011-11-01T14:57:29.430Z,To Internet,08CE66BCB62C5685,1,10.0.0.16:23178,194.73.118.73:25,+,,
    2011-11-01T14:57:29.458Z,To Internet,08CE66BCB62C5685,2,10.0.0.16:23178,194.73.118.73:25,<,220 smtp2.thomascook.com ESMTP (ad33c0edf50e5029d30b26a2332eb4db),
    2011-11-01T14:57:29.458Z,To Internet,08CE66BCB62C5685,3,10.0.0.16:23178,194.73.118.73:25,>,EHLO mail.icwuk.com,
    2011-11-01T14:57:29.479Z,To Internet,08CE66BCB62C5685,4,10.0.0.16:23178,194.73.118.73:25,<,"250-smtp2.thomascook.com Hello mail.icwuk.com [94.72.253.212], pleased to meet you",
    2011-11-01T14:57:29.479Z,To Internet,08CE66BCB62C5685,5,10.0.0.16:23178,194.73.118.73:25,<,250-STARTTLS,
    2011-11-01T14:57:29.479Z,To Internet,08CE66BCB62C5685,6,10.0.0.16:23178,194.73.118.73:25,<,250-SIZE 30000000,
    2011-11-01T14:57:29.479Z,To Internet,08CE66BCB62C5685,7,10.0.0.16:23178,194.73.118.73:25,<,250-PIPELINING,
    2011-11-01T14:57:29.479Z,To Internet,08CE66BCB62C5685,8,10.0.0.16:23178,194.73.118.73:25,<,250-8BITMIME,
    2011-11-01T14:57:29.479Z,To Internet,08CE66BCB62C5685,9,10.0.0.16:23178,194.73.118.73:25,<,250 HELP,
    2011-11-01T14:57:29.479Z,To Internet,08CE66BCB62C5685,10,10.0.0.16:23178,194.73.118.73:25,>,STARTTLS,
    2011-11-01T14:57:29.499Z,To Internet,08CE66BCB62C5685,11,10.0.0.16:23178,194.73.118.73:25,<,220 Ready to start TLS,
    2011-11-01T14:57:29.499Z,To Internet,08CE66BCB62C5685,12,10.0.0.16:23178,194.73.118.73:25,*,,Sending certificate
    2011-11-01T14:57:29.499Z,To Internet,08CE66BCB62C5685,13,10.0.0.16:23178,194.73.118.73:25,*,"CN=icwuk.com, OU=Domain Control Validated, O=icwuk.com",Certificate subject
    2011-11-01T14:57:29.499Z,To Internet,08CE66BCB62C5685,14,10.0.0.16:23178,194.73.118.73:25,*,"SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O=""GoDaddy.com, Inc."", L=Scottsdale, S=Arizona, C=US",Certificate issuer name
    2011-11-01T14:57:29.499Z,To Internet,08CE66BCB62C5685,15,10.0.0.16:23178,194.73.118.73:25,*,,Certificate serial number
    2011-11-01T14:57:29.499Z,To Internet,08CE66BCB62C5685,16,10.0.0.16:23178,194.73.118.73:25,*,763FF,Certificate thumbprint
    2011-11-01T14:57:29.499Z,To Internet,08CE66BCB62C5685,17,10.0.0.16:23178,194.73.118.73:25,*,icwuk.com;www.icwuk.com;owa.icwuk.com;mail.icwuk.com;autodiscover.icwuk.com;
    autodiscover.icwuk.local;autodiscover.incorporatewear.co.uk;icwuk.local;inworkwear.com;incorporatewear.co.uk;exchange2010.icwuk.local,Certificate alternate names
    2011-11-01T14:57:29.552Z,To Internet,08CE66BCB62C5685,18,10.0.0.16:23178,194.73.118.73:25,*,,Received certificate
    2011-11-01T14:57:29.552Z,To Internet,08CE66BCB62C5685,19,10.0.0.16:23178,194.73.118.73:25,*,0E3427,Certificate thumbprint
    2011-11-01T14:57:29.552Z,To Internet,08CE66BCB62C5685,20,10.0.0.16:23178,194.73.118.73:25,>,EHLO mail.icwuk.com,
    2011-11-01T14:57:29.579Z,To Internet,08CE66BCB62C5685,21,10.0.0.16:23178,194.73.118.73:25,<,"250-smtp2.thomascook.com Hello mail.icwuk.com [94.72.253.212], pleased to meet you",
    2011-11-01T14:57:29.579Z,To Internet,08CE66BCB62C5685,22,10.0.0.16:23178,194.73.118.73:25,<,250-SIZE 30000000,
    2011-11-01T14:57:29.579Z,To Internet,08CE66BCB62C5685,23,10.0.0.16:23178,194.73.118.73:25,<,250-PIPELINING,
    2011-11-01T14:57:29.579Z,To Internet,08CE66BCB62C5685,24,10.0.0.16:23178,194.73.118.73:25,<,250-8BITMIME,
    2011-11-01T14:57:29.579Z,To Internet,08CE66BCB62C5685,25,10.0.0.16:23178,194.73.118.73:25,<,250 HELP,
    2011-11-01T14:57:29.580Z,To Internet,08CE66BCB62C5685,26,10.0.0.16:23178,194.73.118.73:25,*,2952345,sending message
    2011-11-01T14:57:29.580Z,To Internet,08CE66BCB62C5685,27,10.0.0.16:23178,194.73.118.73:25,>,MAIL FROM:<my.user1@icwuk.com> SIZE=18777,
    2011-11-01T14:57:29.580Z,To Internet,08CE66BCB62C5685,28,10.0.0.16:23178,194.73.118.73:25,>,RCPT TO:<external.user1@Thomascook.com>,
    2011-11-01T14:57:29.581Z,To Internet,08CE66BCB62C5685,29,10.0.0.16:23178,194.73.118.73:25,>,RCPT TO:<external.user2@thomascook.com>,
    2011-11-01T14:57:29.606Z,To Internet,08CE66BCB62C5685,30,10.0.0.16:23178,194.73.118.73:25,<,250 Sender <my.user1@icwuk.com> OK,
    2011-11-01T14:57:29.828Z,To Internet,08CE66BCB62C5685,31,10.0.0.16:23178,194.73.118.73:25,<,250 Recipient <external.user1@Thomascook.com> OK,
    2011-11-01T14:57:29.829Z,To Internet,08CE66BCB62C5685,32,10.0.0.16:23178,194.73.118.73:25,<,250 Recipient <external.user2@thomascook.com> OK,
    2011-11-01T14:57:29.831Z,To Internet,08CE66BCB62C5685,33,10.0.0.16:23178,194.73.118.73:25,>,DATA,
    2011-11-01T14:57:29.853Z,To Internet,08CE66BCB62C5685,34,10.0.0.16:23178,194.73.118.73:25,<,354 Start mail input; end with <CRLF>.<CRLF>,
    2011-11-01T14:57:30.142Z,To Internet,08CE66BCB62C5685,35,10.0.0.16:23178,194.73.118.73:25,<,250 Ok: queued as 23B6D1BAC754,
    2011-11-01T14:57:30.144Z,To Internet,08CE66BCB62C5685,36,10.0.0.16:23178,194.73.118.73:25,>,QUIT,
    2011-11-01T14:57:30.167Z,To Internet,08CE66BCB62C5685,37,10.0.0.16:23178,194.73.118.73:25,<,"221 smtp2.thomascook.com Goodbye mail.icwuk.com, closing connection",
    2011-11-01T14:57:30.167Z,To Internet,08CE66BCB62C5685,38,10.0.0.16:23178,194.73.118.73:25,-,,Local

    SECOND EMAIL

    2011-11-01T15:02:19.918Z,To Internet,08CE66BCB62C56B6,1,10.0.0.16:23223,207.126.147.10:25,+,,
    2011-11-01T15:02:19.935Z,To Internet,08CE66BCB62C56B6,2,10.0.0.16:23223,207.126.147.10:25,<,220 Postini ESMTP 108 y6_44_0c6 ready.  CA Business and Professions
    Code Section 17538.45 forbids use of this system for unsolicited electronic mail advertisements.,
    2011-11-01T15:02:19.935Z,To Internet,08CE66BCB62C56B6,3,10.0.0.16:23223,207.126.147.10:25,>,EHLO mail.icwuk.com,
    2011-11-01T15:02:19.952Z,To Internet,08CE66BCB62C56B6,4,10.0.0.16:23223,207.126.147.10:25,<,250-Postini says hello back,
    2011-11-01T15:02:19.952Z,To Internet,08CE66BCB62C56B6,5,10.0.0.16:23223,207.126.147.10:25,<,250-STARTTLS,
    2011-11-01T15:02:19.952Z,To Internet,08CE66BCB62C56B6,6,10.0.0.16:23223,207.126.147.10:25,<,250-8BITMIME,
    2011-11-01T15:02:19.952Z,To Internet,08CE66BCB62C56B6,7,10.0.0.16:23223,207.126.147.10:25,<,250 HELP,
    2011-11-01T15:02:19.953Z,To Internet,08CE66BCB62C56B6,8,10.0.0.16:23223,207.126.147.10:25,>,STARTTLS,
    2011-11-01T15:02:19.970Z,To Internet,08CE66BCB62C56B6,9,10.0.0.16:23223,207.126.147.10:25,<,220 Go ahead,
    2011-11-01T15:02:19.970Z,To Internet,08CE66BCB62C56B6,10,10.0.0.16:23223,207.126.147.10:25,*,,Sending certificate
    2011-11-01T15:02:19.970Z,To Internet,08CE66BCB62C56B6,11,10.0.0.16:23223,207.126.147.10:25,*,"CN=icwuk.com, OU=Domain Control Validated, O=icwuk.com",Certificate subject
    2011-11-01T15:02:19.970Z,To Internet,08CE66BCB62C56B6,12,10.0.0.16:23223,207.126.147.10:25,*,"SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O=""GoDaddy.com, Inc."", L=Scottsdale, S=Arizona, C=US",Certificate issuer name
    2011-11-01T15:02:19.970Z,To Internet,08CE66BCB62C56B6,13,10.0.0.16:23223,207.126.147.10:25,*,05,Certificate serial number
    2011-11-01T15:02:19.970Z,To Internet,08CE66BCB62C56B6,14,10.0.0.16:23223,207.126.147.10:25,*,,Certificate thumbprint
    2011-11-01T15:02:19.970Z,To Internet,08CE66BCB62C56B6,15,10.0.0.16:23223,207.126.147.10:25,*,icwuk.com;www.icwuk.com;owa.icwuk.com;mail.icwuk.com;
    autodiscover.icwuk.com;autodiscover.icwuk.local;autodiscover.incorporatewear.co.uk;icwuk.local;inworkwear.com;incorporatewear.co.uk;exchange2010.icwuk.local,Certificate alternate names
    2011-11-01T15:02:20.014Z,To Internet,08CE66BCB62C56B6,16,10.0.0.16:23223,207.126.147.10:25,*,,Received certificate
    2011-11-01T15:02:20.015Z,To Internet,08CE66BCB62C56B6,17,10.0.0.16:23223,207.126.147.10:25,*,04C72D6264,Certificate thumbprint
    2011-11-01T15:02:20.015Z,To Internet,08CE66BCB62C56B6,18,10.0.0.16:23223,207.126.147.10:25,>,EHLO mail.icwuk.com,
    2011-11-01T15:02:20.032Z,To Internet,08CE66BCB62C56B6,19,10.0.0.16:23223,207.126.147.10:25,<,250-Postini says hello back,
    2011-11-01T15:02:20.032Z,To Internet,08CE66BCB62C56B6,20,10.0.0.16:23223,207.126.147.10:25,<,250-8BITMIME,
    2011-11-01T15:02:20.032Z,To Internet,08CE66BCB62C56B6,21,10.0.0.16:23223,207.126.147.10:25,<,250 HELP,
    2011-11-01T15:02:20.033Z,To Internet,08CE66BCB62C56B6,22,10.0.0.16:23223,207.126.147.10:25,*,2952396,sending message
    2011-11-01T15:02:20.033Z,To Internet,08CE66BCB62C56B6,23,10.0.0.16:23223,207.126.147.10:25,>,MAIL FROM:<my.user@icwuk.com>,
    2011-11-01T15:02:20.051Z,To Internet,08CE66BCB62C56B6,24,10.0.0.16:23223,207.126.147.10:25,<,250 Ok,
    2011-11-01T15:02:20.051Z,To Internet,08CE66BCB62C56B6,25,10.0.0.16:23223,207.126.147.10:25,>,RCPT TO:<external.user@barclays.com>,
    2011-11-01T15:02:20.260Z,To Internet,08CE66BCB62C56B6,26,10.0.0.16:23223,207.126.147.10:25,<,250 Ok,
    2011-11-01T15:02:20.260Z,To Internet,08CE66BCB62C56B6,27,10.0.0.16:23223,207.126.147.10:25,>,RCPT TO:<external.user2@barclays.com>,
    2011-11-01T15:02:20.301Z,To Internet,08CE66BCB62C56B6,28,10.0.0.16:23223,207.126.147.10:25,<,250 Ok,
    2011-11-01T15:02:20.305Z,To Internet,08CE66BCB62C56B6,29,10.0.0.16:23223,207.126.147.10:25,>,DATA,
    2011-11-01T15:02:20.322Z,To Internet,08CE66BCB62C56B6,30,10.0.0.16:23223,207.126.147.10:25,<,354 Feed me,
    2011-11-01T15:02:20.757Z,To Internet,08CE66BCB62C56B6,31,10.0.0.16:23223,207.126.147.10:25,<,250 Thanks,
    2011-11-01T15:02:20.759Z,To Internet,08CE66BCB62C56B6,32,10.0.0.16:23223,207.126.147.10:25,>,QUIT,
    2011-11-01T15:02:20.776Z,To Internet,08CE66BCB62C56B6,33,10.0.0.16:23223,207.126.147.10:25,<,221 Catch you later,
    2011-11-01T15:02:20.776Z,To Internet,08CE66BCB62C56B6,34,10.0.0.16:23223,207.126.147.10:25,-,,Local

    THANKS

     


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.Or please vote as helpful.
    • Edited by Mshak Thursday, November 03, 2011 1:32 PM Sec
    Tuesday, November 01, 2011 3:54 PM
  • On Tue, 1 Nov 2011 15:54:23 +0000, Mshak wrote:
     
    >Thanks for staying with me much appreciated. I have removed those domains from the secure list but my manager is getting a bit annoyed because if I enable TLS then messages don't go out so he said disable it. I have disabled TLS for temp.
    >
    >I just enabled the TLS so I can get some logs and post them here. Luckily the same time someone sent an email to the bank. Can you please have a look at this log and tell me if TLS is happening and it?s working. Remember this is not forced TLS. Yes I did notice the note under that article and I have change the permissions.
    >
    >This THE BANK email on my send connector.
     
    Okay. You're using TLS when you send to them.
     
    They say they accept TLS:
    >2011-11-01T15:08:55.516Z,To Internet,08CE66BCB62C56F9,7,10.0.0.16:23271,193.108.72.62:25,<,250-STARTTLS,
     
    And your server says it wants to use TLS:
    >2011-11-01T15:08:55.517Z,To Internet,08CE66BCB62C56F9,9,10.0.0.16:23271,193.108.72.62:25,>,STARTTLS,
     
    You then exchange certificates and send the message. There's nothing
    odd going on and TLS is used.
     
    The other two examples follow the same pattern. TLS is used to send
    those mails, too.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Tuesday, November 01, 2011 6:05 PM
  • Thanks Rich for all your help.

    Today I have tried with forced TLS for the Bank domains. There is out come in send connector's logs.

    After all those previous steps: like EHLO, 250-TLS, STARTTLS etc.  

    2011-11-02T11:46:19.550Z,To Internet,08CE6756E39EE860,17,10.0.0.16:13412,193.108.72.62:25,*,,Received certificate
    2011-11-02T11:46:19.550Z,To Internet,08CE6756E39EE860,18,10.0.0.16:13412,193.108.72.62:25,*,0241A7ED0C2E620EB313ADD0486B759F31686C4D,Certificate thumbprint
    2011-11-02T11:46:19.551Z,To Internet,08CE6756E39EE861,0,,91.214.7.40:25,*,,attempting to connect
    2011-11-02T11:46:19.552Z,To Internet,08CE6756E39EE860,19,10.0.0.16:13412,193.108.72.62:25,>,QUIT,
    2011-11-02T11:46:19.567Z,To Internet,08CE6756E39EE860,20,10.0.0.16:13412,193.108.72.62:25,<,221 Service closing transmission channel closing connection, 

    This is ends here no more steps after this no MAIL FROM or RCP TO or sending message or anything. This is repeating few times.

    When sending to any other domain and makes TLS everything goes fine I can see the MAIL FROM or RCP TO or sending message and then quit and close .

    Sorry to be a pain.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.Or please vote as helpful.
    More detail
    • Edited by Mshak Wednesday, November 02, 2011 1:29 PM More Detail
    Wednesday, November 02, 2011 12:22 PM
  • On Wed, 2 Nov 2011 12:22:19 +0000, Mshak wrote:
     
    >
    >
    >Thanks Rich for all your help.
    >
    >Today I have tried with forced TLS for the Bank domains. There is out come in send connector's logs.
    >
    >After all those previous steps: like EHLO, 250-TLS, STARTTLS etc.
    >
    >2011-11-02T11:46:19.550Z,To Internet,08CE6756E39EE860,17,10.0.0.16:13412,193.108.72.62:25,*,,Received certificate 2011-11-02T11:46:19.550Z,To Internet,08CE6756E39EE860,18,10.0.0.16:13412,193.108.72.62:25,*,0241A7ED0C2E620EB313ADD0486B759F31686C4D,Certificate thumbprint 2011-11-02T11:46:19.551Z,To Internet,08CE6756E39EE861,0,,91.214.7.40:25,*,,attempting to connect 2011-11-02T11:46:19.552Z,To Internet,08CE6756E39EE860,19,10.0.0.16:13412,193.108.72.62:25,>,QUIT, 2011-11-02T11:46:19.567Z,To Internet,08CE6756E39EE860,20,10.0.0.16:13412,193.108.72.62:25,<,221 Service closing transmission channel closing connection,
    >
    >This is ends here no more steps after this no MAIL FROM or RCP TO or sending message or anything. This is repeating few times.
    >
    >When sending to any other domain and makes TLS everything goes fine I can see the MAIL FROM or RCP TO or sending message and then quit and close .
    >
    >Sorry to be a pain.
     
    Does the certificate you're using have an exportable private key in
    the certificate store? Does the bank trust GoDaddy's CA? Do they have
    the correct certificates installed in their organization (they may
    have 1024-bit root/intermediate certs and you may be using a 2048-bit
    certificate)?
     
    Does your server trust the correct root/intermediate certificates for
    the certificate the bank uses? Have them send you the certificate
    chain (or a link to a download of the chained certificates).
     
    Can your server access the CRL for their certificate?
     
    Did you use the "import-exchangecertificate" or the MMC Certificate
    snap-in to get your certificate into the certificate store. You have
    to use the import-exchangecertificae cmdlet.
     
    Are you using an edge server or a hub transport server to sent e-mail?
     
    Does the FQDN of the send connector match the (or a) name in the
    certificate?
     
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Wednesday, November 02, 2011 10:00 PM
  • Hi Rich,

    Thanks for your time and support. I don't know much about Certificates, my manager done all the certificate stuff. I can tell few deatil about our certificate, but I have no idea about the Bank's certificate. I will contact them about the certificate detail.

    1. have an exportable private key in
      the certificate store?

             I am not sure about this. As I said not good with certificates. But here is the link if you want to see my certificate: https://owa.icwuk.com/owa

       Does the bank trust GoDaddy's CA?

    Does your server trust the correct root/intermediate certificates for
    the certificate the bank uses? Have them send you the certificate
    chain (or a link to a download of the chained certificates).
    Can your server access the CRL for their certificate?

    I don't know about that and their certificate but will get hold of that. Could you please advise me what kind of information do I need to get from them and where you put that.

    We are using 2048-bit

    Did you use the "import-exchangecertificate" or the MMC Certificate snap-in to get your certificate into the certificate store?

    He imported the certificate from MMC not the "import-exchangecertificate" Now can I use the cmlet to import? Will it effect the other certificate which I have already imported?

    We are using Hub Transport Server
    FQDN for internal is Exchange2010.icwuk.local which is on the certificate. But I have put mail.icwuk.com on the send connector which is also on the certificate. As you can see above in the send connector's log the both names are on the certificate.
    I have put exchange2010.icwuk.local on receive connector.
    As you can see from the logs above (and you said there is nothing odd with TLS) my server was sending TLS emails to other domains. I think we are close to that there is problem send TLS email to The Bank when I use Forced TLS with them and put them in domain secure list.
    Hopefully we will get there.
    Once again Thanks and much appreciated

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.Or please vote as helpful.
    • Edited by Mshak Thursday, November 03, 2011 1:16 PM more detail
    Thursday, November 03, 2011 1:14 PM
  • On Thu, 3 Nov 2011 13:14:30 +0000, Mshak wrote:
     
    >Thanks for your time and support. I don't know much about Certificates, my manager done all the certificate stuff. I can tell few deatil about our certificate, but I have no idea about the Bank's certificate. I will contact them about the certificate detail. 1. have an exportable private key in the certificate store?
    >
    > I am not sure about this. As I said not good with certificates. But here is the link if you want to see my certificate: https://owa.icwuk.com/owa
     
    That won't tell me (or you) if the private key is exportable from the
    certificate store. You have to use the MMC and start to export the
    certificate. If the private key is exportable you'll be asked if you
    want to export it.
     
    > Does the bank trust GoDaddy's CA? Does your server trust the correct root/intermediate certificates for the certificate the bank uses? Have them send you the certificate chain (or a link to a download of the chained certificates). Can your server access the CRL for their certificate?
    >
    >I don't know about that and their certificate but will get hold of that. Could you please advise me what kind of information do I need to get from them and where you put that.
    >
    >We are using 2048-bit
     
    Make sure the bank has the correct root and intermediate certs
    installed.
     
    >Did you use the "import-exchangecertificate" or the MMC Certificate snap-in to get your certificate into the certificate store?
    >
    >He imported the certificate from MMC not the "import-exchangecertificate" Now can I use the cmlet to import?
     
    Do you have the certificate file from the CA that you can use to
    import?
     
    You'll just use the import-exchangecertificate and provide the file
    name containing the certificate. Then you'll use
    "enable-exchangecertificate <thumbprint> -services SMTP,IIS".
     
    >Will it effect the other certificate which I have already imported?
     
    No. You'll only remove the one cert from the store and then import it
    again.
     
    >We are using Hub Transport Server FQDN for internal is Exchange2010.icwuk.local which is on the certificate.
     
    The time it takes to import the and enable the certificate is pretty
    short. You can stop the transport service before you remove the
    certificate and start it when you finish.
     
    >But I have put mail.icwuk.com on the send connector which is also on the certificate. As you can see above in the send connector's log the both names are on the certificate. I have put exchange2010.icwuk.local on receive connector. As you can see from the logs above (and you said there is nothing odd with TLS) my server was sending TLS emails to other domains.
     
    Yes, but you aren't asking the other MTAs to authenticate your
    certificate (or you theirs) when you use TLS. Any certificate, as long
    as it's valid, will work if all you're doing is exchanging keys to
    allow the data strem to be encrypted. When you enable Mutual TLS the
    certificates are used for more than just key exchanges.
     
    >I think we are close to that there is problem send TLS email to The Bank when I use Forced TLS with them and put them in domain secure list. Hopefully we will get there. Once again Thanks and much appreciated
    >Please remember to click ?Mark as Answer? on the post that helps you, and to click ?Unmark as Answer? if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.Or please vote as helpful.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Thursday, November 03, 2011 2:37 PM
  • Hi Rich, Thanks for the quick reply.

    I have tested the certificate and it is exportable with private key. Here what I did: MMC> Certificates > Computer Account > Personal Cert > My cername > Right Click > All Task > Export > On Wizard Page > Next > On the export private Key Page  there is Yes, Export Private Key option availiable.

    Interm CA: There is Go Daddy CA Availiable.

    Under Truted Root CA : Go Daddy Secure CA is availiable.

    Under Tired-Party CA: There is no Go Daddy CA.

    Do I have to send them my certificate? Do I have to get their certificate and do something with that? Because I haven't sent them my Cert and received their  Cert. I didn't import their Cert.

    I will import the Cert into Exchange with the Shell.

    When I enable TLS here is settings on my Receive connector: Under Authantication Tab: I have TLS box Checked, Enable domain security (M A TLS)

    Under Permission Group: All the boxes are Checked.

    When I enable TLS here is settings on my Send connector: Under Network Tab Use DNS.... box is checked and Enable DomainSecurity (M A TLS) is checked.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.Or please vote as helpful.
    Thursday, November 03, 2011 3:24 PM
  • On Thu, 3 Nov 2011 15:24:28 +0000, Mshak wrote:
     
    >I have tested the certificate and it is exportable with private key. Here what I did: MMC> Certificates > Computer Account > Personal Cert > My cername > Right Click > All Task > Export > On Wizard Page > Next > On the export private Key Page there is Yes, Export Private Key option availiable.
     
    So this warning applies to your situation:
     
    "Do not enable strong-key protection on certificates that are intended
    for TLS. Strong-key protection prompts the user every time that the
    private key is accessed. With Domain Security, the user is the SMTP
    service on the Edge Transport server."
     
    >Interm CA: There is Go Daddy CA Availiable.
    >Under Truted Root CA : Go Daddy Secure CA is availiable.
    >Under Tired-Party CA: There is no Go Daddy CA.
    >
    >Do I have to send them my certificate?
     
    No. But if they don't have the necessary root and intermediate
    certificates installed on they server then things may not go well with
    the mutual TLS (it'll work okay for just using TLS).
     
    >Do I have to get their certificate and do something with that? Because I haven't sent them my Cert and received their Cert. I didn't import their Cert.
     
    If their certificate is issued by a CA you trust then there's no need
    for you to do anything at all with their certificate. If you don't
    have the issuing CA's root and intermediate certs in your certificate
    store you should add them (but not the bank's certificate).
     
    >I will import the Cert into Exchange with the Shell.
    >
    >When I enable TLS here is settings on my Receive connector: Under Authantication Tab: I have TLS box Checked, Enable domain security (M A TLS)
     
    Follow the steps on the web page (i.e. the link you sent earlier).
     
    >Under Permission Group: All the boxes are Checked.
    >
    >When I enable TLS here is settings on my Send connector: Under Network Tab Use DNS.... box is checked and Enable DomainSecurity (M A TLS) is checked.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Thursday, November 03, 2011 3:58 PM
  • Hi Rich and Mshak

    I am having a similar issue with enabling Mutual TLS to HSBC and other banks.  I purchased a certificate via http://certificatesforexchange.com which I believe is a subsidiary of Go Daddy.  I have installed the certificate on our SBS 2008/Exchange 2007 server and enabled Mutual TLS to HSBC.  The emails sit in the mail queue with the same 454 4.7.5 Certificate Validation Failure message that you have seen.

    SMTP Send log looks like this when Mutual TLS is configured:

    2011-10-26T20:54:41.849Z,Secure Email,08CE62386BC77CBA,0,,203.112.90.3:25,*,,attempting to connect
    2011-10-26T20:54:42.009Z,Secure Email,08CE62386BC77CBA,1,192.168.40.12:32233,203.112.90.3:25,+,,
    2011-10-26T20:54:42.171Z,Secure Email,08CE62386BC77CBA,2,192.168.40.12:32233,203.112.90.3:25,<,220 SMTP Proxy Server Ready,
    2011-10-26T20:54:42.171Z,Secure Email,08CE62386BC77CBA,3,192.168.40.12:32233,203.112.90.3:25,>,EHLO mail.bankomb.org.nz,
    2011-10-26T20:54:42.329Z,Secure Email,08CE62386BC77CBA,4,192.168.40.12:32233,203.112.90.3:25,<,250-ESMTP Server Ready,
    2011-10-26T20:54:42.329Z,Secure Email,08CE62386BC77CBA,5,192.168.40.12:32233,203.112.90.3:25,<,250-SIZE 83886080,
    2011-10-26T20:54:42.329Z,Secure Email,08CE62386BC77CBA,6,192.168.40.12:32233,203.112.90.3:25,<,250-DSN,
    2011-10-26T20:54:42.329Z,Secure Email,08CE62386BC77CBA,7,192.168.40.12:32233,203.112.90.3:25,<,250-STARTTLS,
    2011-10-26T20:54:42.329Z,Secure Email,08CE62386BC77CBA,8,192.168.40.12:32233,203.112.90.3:25,<,250 TLS,
    2011-10-26T20:54:42.329Z,Secure Email,08CE62386BC77CBA,9,192.168.40.12:32233,203.112.90.3:25,>,STARTTLS,
    2011-10-26T20:54:42.487Z,Secure Email,08CE62386BC77CBA,10,192.168.40.12:32233,203.112.90.3:25,<,220 Server ready Ready to start TLS,
    2011-10-26T20:54:42.487Z,Secure Email,08CE62386BC77CBA,11,192.168.40.12:32233,203.112.90.3:25,*,,Sending certificate
    2011-10-26T20:54:42.487Z,Secure Email,08CE62386BC77CBA,12,192.168.40.12:32233,203.112.90.3:25,*,"CN=mail.bankomb.org.nz, OU=Domain Control Validated, O=mail.bankomb.org.nz",Certificate subject
    2011-10-26T20:54:42.487Z,Secure Email,08CE62386BC77CBA,13,192.168.40.12:32233,203.112.90.3:25,*,"SERIALNUMBER=10688435, CN=Starfield Secure Certification Authority, OU=http://certificates.starfieldtech.com/repository, O=""Starfield Technologies, Inc."", L=Scottsdale, S=Arizona, C=US",Certificate issuer name
    2011-10-26T20:54:42.487Z,Secure Email,08CE62386BC77CBA,14,192.168.40.12:32233,203.112.90.3:25,*,0780700EA92B66,Certificate serial number
    2011-10-26T20:54:42.487Z,Secure Email,08CE62386BC77CBA,15,192.168.40.12:32233,203.112.90.3:25,*,896DA63E533FE9E89810E9822C32DE88D956F434,Certificate thumbprint
    2011-10-26T20:54:42.488Z,Secure Email,08CE62386BC77CBA,16,192.168.40.12:32233,203.112.90.3:25,*,mail.bankomb.org.nz;www.mail.bankomb.org.nz;remote.bankomb.org.nz;mail.bankombudsman.org.nz;bocwlgsbs.bocdom.bankombudsman.org.nz,Certificate alternate names
    2011-10-26T20:54:43.184Z,Secure Email,08CE62386BC77CBA,17,192.168.40.12:32233,203.112.90.3:25,*,,Received certificate
    2011-10-26T20:54:43.184Z,Secure Email,08CE62386BC77CBA,18,192.168.40.12:32233,203.112.90.3:25,*,F9AAEEAADDC6E76C75F8AECF9142DA2E23107CD8,Certificate thumbprint
    2011-10-26T20:54:43.187Z,Secure Email,08CE62386BC77CBA,0,,203.112.84.3:25,*,,attempting to connect
    2011-10-26T20:54:43.188Z,Secure Email,08CE62386BC77CBA,19,192.168.40.12:32233,203.112.90.3:25,>,QUIT,
    2011-10-26T20:54:43.346Z,Secure Email,08CE62386BC77CBA,20,192.168.40.12:32233,203.112.90.3:25,<,221 Service closing transmission channel closing connection,
    2011-10-26T20:54:43.346Z,Secure Email,08CE62386BC77CBA,21,192.168.40.12:32233,203.112.90.3:25,-,,Local

    If I allow Opportunistic TLS instead, then the email goes through ok and the recipient has confirmed that it was TLS encrypted.  SMTP log for Opportunistic:

    2011-10-26T20:55:52.337Z,Secure Email,08CE6238C805C876,2,192.168.40.12:32292,203.112.90.3:25,<,220 SMTP Proxy Server Ready,
    2011-10-26T20:55:52.338Z,Secure Email,08CE6238C805C876,3,192.168.40.12:32292,203.112.90.3:25,>,EHLO mail.bankomb.org.nz,
    2011-10-26T20:55:52.496Z,Secure Email,08CE6238C805C876,4,192.168.40.12:32292,203.112.90.3:25,<,250-ESMTP Server Ready,
    2011-10-26T20:55:52.496Z,Secure Email,08CE6238C805C876,5,192.168.40.12:32292,203.112.90.3:25,<,250-SIZE 83886080,
    2011-10-26T20:55:52.496Z,Secure Email,08CE6238C805C876,6,192.168.40.12:32292,203.112.90.3:25,<,250-DSN,
    2011-10-26T20:55:52.496Z,Secure Email,08CE6238C805C876,7,192.168.40.12:32292,203.112.90.3:25,<,250-STARTTLS,
    2011-10-26T20:55:52.497Z,Secure Email,08CE6238C805C876,8,192.168.40.12:32292,203.112.90.3:25,<,250 TLS,
    2011-10-26T20:55:52.497Z,Secure Email,08CE6238C805C876,9,192.168.40.12:32292,203.112.90.3:25,>,STARTTLS,
    2011-10-26T20:55:52.656Z,Secure Email,08CE6238C805C876,10,192.168.40.12:32292,203.112.90.3:25,<,220 Server ready Ready to start TLS,
    2011-10-26T20:55:52.656Z,Secure Email,08CE6238C805C876,11,192.168.40.12:32292,203.112.90.3:25,*,,Sending certificate
    2011-10-26T20:55:52.656Z,Secure Email,08CE6238C805C876,12,192.168.40.12:32292,203.112.90.3:25,*,"CN=mail.bankomb.org.nz, OU=Domain Control Validated, O=mail.bankomb.org.nz",Certificate subject
    2011-10-26T20:55:52.656Z,Secure Email,08CE6238C805C876,13,192.168.40.12:32292,203.112.90.3:25,*,"SERIALNUMBER=10688435, CN=Starfield Secure Certification Authority, OU=http://certificates.starfieldtech.com/repository, O=""Starfield Technologies, Inc."", L=Scottsdale, S=Arizona, C=US",Certificate issuer name
    2011-10-26T20:55:52.656Z,Secure Email,08CE6238C805C876,14,192.168.40.12:32292,203.112.90.3:25,*,0780700EA92B66,Certificate serial number
    2011-10-26T20:55:52.656Z,Secure Email,08CE6238C805C876,15,192.168.40.12:32292,203.112.90.3:25,*,896DA63E533FE9E89810E9822C32DE88D956F434,Certificate thumbprint
    2011-10-26T20:55:52.657Z,Secure Email,08CE6238C805C876,16,192.168.40.12:32292,203.112.90.3:25,*,mail.bankomb.org.nz;www.mail.bankomb.org.nz;remote.bankomb.org.nz;mail.bankombudsman.org.nz;bocwlgsbs.bocdom.bankombudsman.org.nz,Certificate alternate names
    2011-10-26T20:55:53.381Z,Secure Email,08CE6238C805C876,17,192.168.40.12:32292,203.112.90.3:25,*,,Received certificate
    2011-10-26T20:55:53.381Z,Secure Email,08CE6238C805C876,18,192.168.40.12:32292,203.112.90.3:25,*,AE7777243943FA1207237DD69660E7CBEA9106E8,Certificate thumbprint
    2011-10-26T20:55:53.382Z,Secure Email,08CE6238C805C876,19,192.168.40.12:32292,203.112.90.3:25,>,EHLO mail.bankomb.org.nz,
    2011-10-26T20:55:53.541Z,Secure Email,08CE6238C805C876,20,192.168.40.12:32292,203.112.90.3:25,<,250-ESMTP Server Ready,
    2011-10-26T20:55:53.541Z,Secure Email,08CE6238C805C876,21,192.168.40.12:32292,203.112.90.3:25,<,250-SIZE 83886080,
    2011-10-26T20:55:53.541Z,Secure Email,08CE6238C805C876,22,192.168.40.12:32292,203.112.90.3:25,<,250 DSN,
    2011-10-26T20:55:53.543Z,Secure Email,08CE6238C805C876,23,192.168.40.12:32292,203.112.90.3:25,*,941,sending message
    2011-10-26T20:55:53.543Z,Secure Email,08CE6238C805C876,24,192.168.40.12:32292,203.112.90.3:25,>,MAIL FROM:<myuser@bankomb.org.nz> SIZE=3918,
    2011-10-26T20:55:53.702Z,Secure Email,08CE6238C805C876,25,192.168.40.12:32292,203.112.90.3:25,<,250 +OK Sender OK,
    2011-10-26T20:55:53.702Z,Secure Email,08CE6238C805C876,26,192.168.40.12:32292,203.112.90.3:25,>,RCPT TO:<bankuser@hsbc.com.cn>,
    2011-10-26T20:55:53.880Z,Secure Email,08CE6238C805C876,27,192.168.40.12:32292,203.112.90.3:25,<,250 +OK Recipient OK,
    2011-10-26T20:55:53.881Z,Secure Email,08CE6238C805C876,28,192.168.40.12:32292,203.112.90.3:25,>,DATA,
    2011-10-26T20:55:54.040Z,Secure Email,08CE6238C805C876,29,192.168.40.12:32292,203.112.90.3:25,<,"354 Start mail input, end with '<CR><LF>.<CR><LF>'  ",
    2011-10-26T20:55:54.804Z,Secure Email,08CE6238C805C876,30,192.168.40.12:32292,203.112.90.3:25,<,250 +OK message queued for delivery.,
    2011-10-26T20:55:54.817Z,Secure Email,08CE6238C805C876,31,192.168.40.12:32292,203.112.90.3:25,>,QUIT,
    2011-10-26T20:55:54.976Z,Secure Email,08CE6238C805C876,32,192.168.40.12:32292,203.112.90.3:25,<,221 Service closing transmission channel closing connection,
    2011-10-26T20:55:54.976Z,Secure Email,08CE6238C805C876,33,192.168.40.12:32292,203.112.90.3:25,-,,Local

    The strange thing is that I can enabled Mutual TLS to other organisations fine:

    011-10-26T20:41:46.592Z,Secure Email,08CE6236BF837656,2,192.168.40.12:6066,203.96.50.26:25,<,"220 LWXAKLVMS04.LWXDOMAIN.LANWORX.CO.NZ Microsoft ESMTP MAIL Service ready at Thu, 27 Oct 2011 09:42:48 +1300",
    2011-10-26T20:41:46.592Z,Secure Email,08CE6236BF837656,3,192.168.40.12:6066,203.96.50.26:25,>,EHLO mail.bankomb.org.nz,
    2011-10-26T20:41:46.610Z,Secure Email,08CE6236BF837656,4,192.168.40.12:6066,203.96.50.26:25,<,250-LWXAKLVMS04.LWXDOMAIN.LANWORX.CO.NZ Hello [203.97.154.19],
    2011-10-26T20:41:46.610Z,Secure Email,08CE6236BF837656,5,192.168.40.12:6066,203.96.50.26:25,<,250-SIZE,
    2011-10-26T20:41:46.610Z,Secure Email,08CE6236BF837656,6,192.168.40.12:6066,203.96.50.26:25,<,250-PIPELINING,
    2011-10-26T20:41:46.610Z,Secure Email,08CE6236BF837656,7,192.168.40.12:6066,203.96.50.26:25,<,250-DSN,
    2011-10-26T20:41:46.610Z,Secure Email,08CE6236BF837656,8,192.168.40.12:6066,203.96.50.26:25,<,250-ENHANCEDSTATUSCODES,
    2011-10-26T20:41:46.610Z,Secure Email,08CE6236BF837656,9,192.168.40.12:6066,203.96.50.26:25,<,250-STARTTLS,
    2011-10-26T20:41:46.610Z,Secure Email,08CE6236BF837656,10,192.168.40.12:6066,203.96.50.26:25,<,250-X-ANONYMOUSTLS,
    2011-10-26T20:41:46.610Z,Secure Email,08CE6236BF837656,11,192.168.40.12:6066,203.96.50.26:25,<,250-AUTH NTLM,
    2011-10-26T20:41:46.610Z,Secure Email,08CE6236BF837656,12,192.168.40.12:6066,203.96.50.26:25,<,250-X-EXPS GSSAPI NTLM,
    2011-10-26T20:41:46.610Z,Secure Email,08CE6236BF837656,13,192.168.40.12:6066,203.96.50.26:25,<,250-8BITMIME,
    2011-10-26T20:41:46.610Z,Secure Email,08CE6236BF837656,14,192.168.40.12:6066,203.96.50.26:25,<,250-BINARYMIME,
    2011-10-26T20:41:46.610Z,Secure Email,08CE6236BF837656,15,192.168.40.12:6066,203.96.50.26:25,<,250-CHUNKING,
    2011-10-26T20:41:46.610Z,Secure Email,08CE6236BF837656,16,192.168.40.12:6066,203.96.50.26:25,<,250-XEXCH50,
    2011-10-26T20:41:46.610Z,Secure Email,08CE6236BF837656,17,192.168.40.12:6066,203.96.50.26:25,<,250-XRDST,
    2011-10-26T20:41:46.610Z,Secure Email,08CE6236BF837656,18,192.168.40.12:6066,203.96.50.26:25,<,250 XSHADOW,
    2011-10-26T20:41:46.610Z,Secure Email,08CE6236BF837656,19,192.168.40.12:6066,203.96.50.26:25,>,STARTTLS,
    2011-10-26T20:41:46.628Z,Secure Email,08CE6236BF837656,20,192.168.40.12:6066,203.96.50.26:25,<,220 2.0.0 SMTP server ready,
    2011-10-26T20:41:46.628Z,Secure Email,08CE6236BF837656,21,192.168.40.12:6066,203.96.50.26:25,*,,Sending certificate
    2011-10-26T20:41:46.628Z,Secure Email,08CE6236BF837656,22,192.168.40.12:6066,203.96.50.26:25,*,"CN=mail.bankomb.org.nz, OU=Domain Control Validated, O=mail.bankomb.org.nz",Certificate subject
    2011-10-26T20:41:46.628Z,Secure Email,08CE6236BF837656,23,192.168.40.12:6066,203.96.50.26:25,*,"SERIALNUMBER=10688435, CN=Starfield Secure Certification Authority, OU=http://certificates.starfieldtech.com/repository, O=""Starfield Technologies, Inc."", L=Scottsdale, S=Arizona, C=US",Certificate issuer name
    2011-10-26T20:41:46.628Z,Secure Email,08CE6236BF837656,24,192.168.40.12:6066,203.96.50.26:25,*,0780700EA92B66,Certificate serial number
    2011-10-26T20:41:46.628Z,Secure Email,08CE6236BF837656,25,192.168.40.12:6066,203.96.50.26:25,*,896DA63E533FE9E89810E9822C32DE88D956F434,Certificate thumbprint
    2011-10-26T20:41:46.629Z,Secure Email,08CE6236BF837656,26,192.168.40.12:6066,203.96.50.26:25,*,mail.bankomb.org.nz;www.mail.bankomb.org.nz;remote.bankomb.org.nz;mail.bankombudsman.org.nz;bocwlgsbs.bocdom.bankombudsman.org.nz,Certificate alternate names
    2011-10-26T20:41:46.749Z,Secure Email,08CE6236BF837656,27,192.168.40.12:6066,203.96.50.26:25,*,,Received certificate
    2011-10-26T20:41:46.749Z,Secure Email,08CE6236BF837656,28,192.168.40.12:6066,203.96.50.26:25,*,52EAD98A097F81F3FEC1017702429FDFF78A7B46,Certificate thumbprint
    2011-10-26T20:41:47.943Z,Secure Email,08CE6236BF837656,29,192.168.40.12:6066,203.96.50.26:25,*,SendRoutingHeaders,Set Session Permissions
    2011-10-26T20:41:47.943Z,Secure Email,08CE6236BF837656,30,192.168.40.12:6066,203.96.50.26:25,*,,Secure domain certificate
    2011-10-26T20:41:47.943Z,Secure Email,08CE6236BF837656,31,192.168.40.12:6066,203.96.50.26:25,*,"E=hostmaster@lanworx.co.nz, CN=mailakl.lanworx.co.nz, OU=StartCom Verified Certificate Member, O=Christopher Hoffmann, L=Auckland, S=Auckland, C=NZ, Description=238728-7A0889ap0y64XS07",Certificate subject
    2011-10-26T20:41:47.943Z,Secure Email,08CE6236BF837656,32,192.168.40.12:6066,203.96.50.26:25,*,"CN=StartCom Class 2 Primary Intermediate Server CA, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL",Certificate issuer name
    2011-10-26T20:41:47.943Z,Secure Email,08CE6236BF837656,33,192.168.40.12:6066,203.96.50.26:25,*,2EB4,Certificate serial number
    2011-10-26T20:41:47.943Z,Secure Email,08CE6236BF837656,34,192.168.40.12:6066,203.96.50.26:25,*,52EAD98A097F81F3FEC1017702429FDFF78A7B46,Certificate thumbprint
    2011-10-26T20:41:47.943Z,Secure Email,08CE6236BF837656,35,192.168.40.12:6066,203.96.50.26:25,*,mailakl.lanworx.co.nz;lanworx.co.nz;lwxaklvms04.lwxdomain.lanworx.co.nz,Certificate alternate names
    2011-10-26T20:41:47.943Z,Secure Email,08CE6236BF837656,36,192.168.40.12:6066,203.96.50.26:25,>,EHLO mail.bankomb.org.nz,
    2011-10-26T20:41:47.973Z,Secure Email,08CE6236BF837656,37,192.168.40.12:6066,203.96.50.26:25,<,250-LWXAKLVMS04.LWXDOMAIN.LANWORX.CO.NZ Hello [203.97.154.19],
    2011-10-26T20:41:47.973Z,Secure Email,08CE6236BF837656,38,192.168.40.12:6066,203.96.50.26:25,<,250-SIZE,
    2011-10-26T20:41:47.973Z,Secure Email,08CE6236BF837656,39,192.168.40.12:6066,203.96.50.26:25,<,250-PIPELINING,
    2011-10-26T20:41:47.973Z,Secure Email,08CE6236BF837656,40,192.168.40.12:6066,203.96.50.26:25,<,250-DSN,
    2011-10-26T20:41:47.973Z,Secure Email,08CE6236BF837656,41,192.168.40.12:6066,203.96.50.26:25,<,250-ENHANCEDSTATUSCODES,
    2011-10-26T20:41:47.973Z,Secure Email,08CE6236BF837656,42,192.168.40.12:6066,203.96.50.26:25,<,250-AUTH NTLM LOGIN,
    2011-10-26T20:41:47.973Z,Secure Email,08CE6236BF837656,43,192.168.40.12:6066,203.96.50.26:25,<,250-X-EXPS GSSAPI NTLM,
    2011-10-26T20:41:47.973Z,Secure Email,08CE6236BF837656,44,192.168.40.12:6066,203.96.50.26:25,<,250-8BITMIME,
    2011-10-26T20:41:47.973Z,Secure Email,08CE6236BF837656,45,192.168.40.12:6066,203.96.50.26:25,<,250-BINARYMIME,
    2011-10-26T20:41:47.973Z,Secure Email,08CE6236BF837656,46,192.168.40.12:6066,203.96.50.26:25,<,250-CHUNKING,
    2011-10-26T20:41:47.973Z,Secure Email,08CE6236BF837656,47,192.168.40.12:6066,203.96.50.26:25,<,250-XEXCH50,
    2011-10-26T20:41:47.973Z,Secure Email,08CE6236BF837656,48,192.168.40.12:6066,203.96.50.26:25,<,250-XRDST,
    2011-10-26T20:41:47.973Z,Secure Email,08CE6236BF837656,49,192.168.40.12:6066,203.96.50.26:25,<,250 XSHADOW,
    2011-10-26T20:41:47.974Z,Secure Email,08CE6236BF837656,50,192.168.40.12:6066,203.96.50.26:25,*,939,sending message
    2011-10-26T20:41:47.974Z,Secure Email,08CE6236BF837656,51,192.168.40.12:6066,203.96.50.26:25,>,MAIL FROM:<myuser@bankomb.org.nz> SIZE=3537,
    2011-10-26T20:41:47.975Z,Secure Email,08CE6236BF837656,52,192.168.40.12:6066,203.96.50.26:25,>,RCPT TO:<user1@lanworx.co.nz>,
    2011-10-26T20:41:47.997Z,Secure Email,08CE6236BF837656,53,192.168.40.12:6066,203.96.50.26:25,<,250 2.1.0 Sender OK,
    2011-10-26T20:41:47.997Z,Secure Email,08CE6236BF837656,54,192.168.40.12:6066,203.96.50.26:25,<,250 2.1.5 Recipient OK,
    2011-10-26T20:41:47.998Z,Secure Email,08CE6236BF837656,55,192.168.40.12:6066,203.96.50.26:25,>,BDAT 2862 LAST,
    2011-10-26T20:42:09.845Z,Secure Email,08CE6236BF837656,56,192.168.40.12:6066,203.96.50.26:25,<,250 2.6.0 <944F276CADB0FC4F928F5292352E1A9F095054D6E7@BOCWLGSBS.BOCDOM.BANKOMBUDSMAN.ORG.NZ> [InternalId=149268] Queued mail for delivery,
    2011-10-26T20:42:09.848Z,Secure Email,08CE6236BF837656,57,192.168.40.12:6066,203.96.50.26:25,>,QUIT,
    2011-10-26T20:42:09.868Z,Secure Email,08CE6236BF837656,58,192.168.40.12:6066,203.96.50.26:25,<,221 2.0.0 Service closing transmission channel,
    2011-10-26T20:42:09.868Z,Secure Email,08CE6236BF837656,59,192.168.40.12:6066,203.96.50.26:25,-,,Local

     

    It only seems to be emails to the banks which are showing this issue.  Initially I thought that our certificate might not be trusted by their organisation but their techs seem to think otherwise. 

    I have also run tests using www.checktls.com and everything comes back ok. 

    The private key for our certificate was marked as exportable and I have worked through each of the settings you have described to no avail. 

    Ryan

    Thursday, November 03, 2011 10:00 PM
  • Hi Rich, Ryan,

    Ryan I am configuring with HSBC Bank as well and have problem with that. I'm getting same error messages as well.

    Rich a bit updat. I've spoken to my Manager and he said he imported the Cert from EMC not from MMC. Does it make any diffrence if you import from EMC or EMS?

    How can I disable strong-key protection?

    How can I disable Export Private Key option?

     


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.Or please vote as helpful.
    Friday, November 04, 2011 10:12 AM
  • On Fri, 4 Nov 2011 10:12:22 +0000, Mshak wrote:
     
    >Ryan I am configuring with HSBC Bank as well and have problem with that. I'm getting same error messages as well.
    >
    >Rich a bit updat. I've spoken to my Manager and he said he imported the Cert from EMC not from MMC. Does it make any diffrence if you import from EMC or EMS?
    >
    >How can I disable strong-key protection?
     
    According to MS, using the import-exchangecertificate makes the
    private key non-exportable. That's why they recommend keeping a copy
    of the certificate in a .pfx file (where the private key is present
    and "importable".
     
    >How can I disable Export Private Key option?
     
    Export the cert and keep the private key. Then import the cert and
    don't mark the private key as exportable.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Friday, November 04, 2011 3:54 PM
  • Hi Mshak.

    I was just wondering if importing the certificate with the private key non-exportable has made any difference for you?

    Ryan

    Tuesday, November 29, 2011 6:26 PM
  • Hi Ryan,

    I still haven't tried to Import from EMS, because we are waiting from HSBC to respond to us so that's why I have not enabled the TLS at the moment. What we are thinking is that we are forcing the TLS on their domains and they are not forcing TLS on our domain maybe that's why it is not working.

     But yesterday one wired thing happened a user from HSBC received a couple of emails from our user and on her email it showed the TLS Pad Lock and when she opened the email and Pan lock opened even though we did not enabled the TLS on our side. Then I tried to enable the TLS and forced for their domains it stuck in the queue with the following message

    "451 4.4.0 Primary Target IP address responded with 454 4.7.5 Certificate Validation Failure....Attempted failover to alternative host but that did not succeed. Either there are no alternative hosts or delivery failed to all alternative hosts"

    I checked the send connectors logs and same as above, servers start communication and send receive Certificate and quit the session but do not deliver the message.

    I will keep you guys up to date when I hear from HSBC and start the configuration.

    Thank you very much for all your support guys.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.Or please vote as helpful.
    Wednesday, November 30, 2011 9:14 AM
  • Sorry if this posts twice - it didn't seem to work the first time.

    Hi Mshak

    I believe that I have found the source of the issue after reading the Microsoft White Paper on Domain Security for Exchange 2007 (http://technet.microsoft.com/en-us/library/bb266978%28EXCHG.80%29.aspx).

    Under Opportunistic TLS, Exchange validates the other parties certificate and ensures that it is valid (hostname, date range and if the source is trusted) then uses it for TLS encryption.  Under Mutual TLS it seems that Exchange takes this a step further by validating that the domain you are sending to (or receiving from) is listed on the certificate.  If the domain isn't listed, Exchange drops the connection.

    To quote the article:

      Name Matching Logic for the Domain Security Feature

    The certificate name matching logic for the Domain Security feature checks whether a domain name in the received certificate matches the domain name when it sends mail to that domain. For the purposes of example, consider the FQDN of the recipient domain, woodgrovebank.com. The certificate name matching logic searches through all DNS names in the certificates, and as long as one DNS name matches, the certificate is verified as a match for the specified domain.



    In this example, the certificate name matching logic accepts a certificate with an exact domain match, such as woodgrovebank.com. It also supports using wildcard character domain names in certificates so that a certificate with a DNS name of *.woodgrovebank.com is accepted as a match. For more information about wildcard character domain names, see "Wildcard Character Domain Names" later in this white paper.

    The certificate name matching logic also searches DNS one node deep. Therefore, mail1.woodgrovebank.com is also accepted as a match for woodgrovebank.com. However, DNS names more than two nodes deep are not accepted. Therefore, mail1.us.woodgrovebank.com, for example, would not be accepted as a match for woodgrovebank.com.


    In my case the cert I was receiving from HSBC was for hsbc.com.hk but I was trying to send to hsbc.com.cn or hsbc.co.nz.  I've had the same issue with a number of banks where the domain(s) on the certificate doesn't match the domains they use for email.  We are working with them now to see if they will accept Opportunistic TLS as I think they find a request to change their SSL certificate unreasonable.

    Ryan

    Friday, December 16, 2011 2:48 AM
  •  

    Hi Guys,

    In the end I had to log a call with Microsoft and found the problem.

    I was using the default send connector to send TLS email which was causing problem to stay in the queue and this error Delivery is delayed to these recipients or groups: Diagnostic-Code: smtp;400 4.4.7.  Or 454 4.7.5 certificate validation failure

    After creating new send connector and putting all the Bank's domains in new connector everything was working fine.

    Bank received the email in TLS which very good BUT when they were trying to send an email or (make a telnet session) they were getting the message that my domain doesn't support TLS the reason is why my client (the domain I am working on) they were using 3rd party (I think eclipse or something) for spam filtering which was the first contact the emails go and they deliver the email after the filter and they do not support TLS so that's why the Bank had problem sending us TLS email.

    So how did we fix this problem:

    I sent the Bank my public IP address so they created a new send connector in there side so they can send the email directly to my exchange Server not to 3rd party spam filter company. ( If you want to do this make sure you TRUST that company and know they will not send spams).

    Everything is working fine.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.Or please vote as helpful.

    • Proposed as answer by Mshak Wednesday, March 28, 2012 9:24 AM
    Wednesday, March 28, 2012 9:24 AM