CRES email delay

[KFrank]

Is anyone else having an issue with encrypted email responses? An example is you send a CRES email to a user. They get the email in the normal amounnt of time but when they open the email and respond it takes a abnormal amount of time to receive the response? I did a test this morning sending an email to myself and I still haven't received the response. It's been over an hour.

There also seems to be something messed up with a listener that was created. This listener would prevent response to encrypted emails from being put back in aCRES envelope. This was great because wouldn't have to go through the login process to read responses to encrypted emails you've sent. This is no longer working.

[Robert Sherwin]

How are you sending/replying -- is this from Outlook -- or are you logging in and doing the creation/reply directly from the CRES interface (https://res.cisco.com)?

-Robert

[KFrank]

I sent and encrypted email to a gmail address. Then opened it and responed. The response took over an hour to show up back in Outlook.

[Robert Sherwin]

I have tried both methods, using my @cisco.com to @gmail.com addreses:

• directly with only creating and replying via https://res.cisco.com --- no issues, no delays.
• directly with creating and replying in Outlook with the Outlook Plug-in --- no issues, no delays.

With the reply that took over an hour to show back up --- what are the full header hops showing between the res.cisco.com servers back to your end (Exchange?)

[KFrank]

Here is the traffic from the last one.

Received: from mta3.cfi.org (192.168.18.53) by
  with Microsoft SMTP Server id 14.3.174.1; Wed, 12 Mar 2014
 09:05:42 -0400
X-IronPort-AV: E=Sophos;i="4.97,638,1389762000"; 
   d="html'217?scan'217,208,217";a="5105197"
Received: from esa2.cres.iphmx.com (HELO mx6.res.cisco.com) ([68.232.140.57])
  by mta3.cfi.org with ESMTP/TLS/AES256-SHA; 12 Mar 2014 09:05:40 -0400
Received: from mxnat3.res.cisco.com ([184.94.241.96])  by mx6.res.cisco.com
 with ESMTP/TLS/RC4-MD5; 12 Mar 2014 05:43:01 -0700
Return-Path: <@gmail.com>
Received: from localhost ([127.0.0.1])          by mxnat3.res.cisco.com (PostX
 Enterprise 4.1.5 SMTP Adaptor) with SMTP ID 912          for
 <@cfi.org>;          Wed, 12 Mar 2014 05:05:35 -0700 (PDT)
Received: from mxnat3.res.cisco.com ([184.94.241.96])  by mx5.res.cisco.com
 with ESMTP/TLS/RC4-MD5; 12 Mar 2014 04:50:00 -0700
Received: from esa1.cres.iphmx.com ([68.232.140.79])          by
 mxnat3.res.cisco.com (PostX Enterprise 4.1.5 SMTP Adaptor) with SMTP ID 94
          for <@cfi.org>;          Wed, 12 Mar 2014 05:05:35 -0700
 (PDT)
Date: Wed, 12 Mar 2014 05:05:35 -0700
From: "@gmail.com" <@gmail.com>
To: <@cfi.org>
Message-ID: <|1__f86ec0f600000144b665f7040a089e887bee1003@prod-cres-app2.sv4.ironport.com>
Subject: RE: Test2 Confidential
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----Part-0-488201446-1394629539808"

 

[Robert Sherwin · Accepted solution]

I worked direct w/ Kevin on this.  The stem of the issue was a recently updated certificate.  The cert had out-of-order intermediate certificate in use... and with CRES communicating over TLS - CRES was seeing this out-of-order and not properly communicating back once the reply was created and sent -- thus causing the delay in replies, and also the inabilty to do clean TLS communication back.

Corrective action taken - review of the certificate in use, and then editing and updating of the associated intermediate certificates associated to the master certificate in use.

Testing after the update shows CRES communicated cleanly to the domain with TLS... and the send/reply happen in timely fashion as expected.

-Robert