We have two jobs that send a periodical email to our mail server using TLS. Both of these worked fine until 1JAN15, then they suddenly started failing with an error 75777. I've read a few other posts that mention that error and tried everything we can, but it still fails. Extended server debug is shown below for one of the jobs (but it's useless). Looking at the mail server, we see VC connecting, but then VC closes the connection immediately afterward.

1/2/2015 6:38:26 PM Debug Job (106) was added to processlist: Transition Patient Services
1/2/2015 6:38:26 PM Debug Next action: ActionContinue
1/2/2015 6:38:26 PM Debug Next Task is: Send Test Print Job via Email
1/2/2015 6:38:26 PM Debug Calling StartTaskProcess() with Task: Send Test Print Job via Email (0)
1/2/2015 6:38:26 PM Debug Task (106) was added to processlist: Send Test Print Job via Email
1/2/2015 6:38:26 PM Info Task started: Send Test Print Job via Email (106)
1/2/2015 6:38:26 PM Debug Entering wait loop. Send Test Print Job via Email (106)
1/2/2015 6:38:26 PM Err Exception in Task: Connection failed (error code is 75777)
1/2/2015 6:38:26 PM Info Task completed: Send Test Print Job via Email (106)
1/2/2015 6:38:26 PM Debug Process status - About to RemoveTaskProcess (106)
1/2/2015 6:38:26 PM Debug Setting previous task in TaskProcessCompleted: Send Test Print Job via Email (251c93a9-2ee7-4cb3-b24b-0b631ca1aa01) in job: Transition Patient Services
1/2/2015 6:38:26 PM Debug Process status - About to SendTaskProcess (106)
1/2/2015 6:38:26 PM Debug Process status - About to RemoveTaskProcess (106)
1/2/2015 6:38:26 PM Debug Task (106) was removed from processlist: Send Test Print Job via Email
1/2/2015 6:38:26 PM Debug Sleep ended because Task ended.Send Test Print Job via Email (106)
1/2/2015 6:38:26 PM Debug TaskWaitQueue.Dequeued.Send Test Print Job via Email (106)
1/2/2015 6:38:27 PM Debug Job (106) was removed from processlist: Transition Patient Services
1/2/2015 6:38:27 PM Debug Next execution (2) for job 'Transition Patient Services' is: 1/2/2015 7:00:00 PM
1/2/2015 6:38:27 PM Info Job completed: Transition Patient Services

PS - We are able to get it to work (or not) by selecting SSL encryption vs TLS. However, the server supports TLS from other clients with no problem. Could there be some issue with VC that prevents TLS encryption from working properly?

I do not see any other reason that something was changed on Email server side. Otherwise why would it suddenly stop working.

---

OK. But for the sake of argument, let's say that nothing has changed on the email server (we're pretty confident in this, since no one touched the running server between the time it works and the time it failed). But regardless, how can we troubleshoot this? I've tried using an SMTP mail client from the same server that VC is running on, to the same email sever, and it works just fine. The logs (even detailed logs) that VC provides are not helpful.

A lot of email servers are being upgraded because of the SSL bug right now. But what error do you get in the log_serverDATE.txt when trying to a Task (or click test button) on the Connection when you use properties that do not work?

Update: Searched on 75777 and it seems to point to that there no way connect securely on this authentication method. Like there is no secure server listening.

---

The output from the log_server file was included in the initial post. Other than this line, there is nothing else to go on:
1/2/2015 6:38:26 PM Err Exception in Task: Connection failed (error code is 75777)

As mentioned in the update of the post the selected service seems to have been disabled. This is the typical response code for that when initiating the authentication.

---

OK, but a simple SMTP client running on the same server as VC is able to connect to and send to the same email server using both SSL and TLS.

Normally different ports are used for SSL and TLS. So, maybe port is different.

Or, the other client tries to fallback to the other when failing why VisualCron is more "strict" to the settings.

---

Note that the specific difference of whether it works or fails from VC is which encryption method I choose in the Connection: SSL works and TLS fails. However, we know that the email server can support both of these methods, and the SMTP test client works both ways (as do other email clients connecting to the same email server). So it's likely that VC "doesn't like something" about the TLS connection, but there is no way to "externally" troubleshoot this, which is why I'm looking for some additional detail from VC as to what it doesn't like.

Hmmm. I don't think so. The port is explicitly set to 587, which the server uses to require an encrypted connection and authentication. The client (or VC) does't know about any other port number.

I am guessing. But another thing, by judging on the date it could be a certificate that has expired on server side.

If this is a problem in VC we will get feedback pretty fast as all of our users are using Email Tasks or Notifications in some form. Right now, especially as you have workaround, it is to time consuming for us to start testing on against this specific server.

---

Yes, that was our thought, too. But we've checked the certificates and tested the server in every way we know how (including probing it from checktls.com, for example). Everything works (except VC). The workaround we have in place isn't great (we really do need to disable SSL 3.0 for security purposes). What I'm looking for is additional "trace" from VC (just reporting error 75777 doesn't give us anything to go on--VC must "know" more about what is failing during the TLS negotiation). Also, the failure happens instantly, so it's not like it's trying to access a non-responsive server or a port that isn't being listened to, etc., it has to be something that VC's SMTP client is deciding is "wrong". Is no more detail available from VC than what currently appears in the log files (with "detailed logging" enabled)?

Here is a response from one of our developers, as detailed as possible:

"Unexpected Message" error usually happens when the other party sends garbage and not TLS packets. The most common reason is misconfiguration, when you try to connect with non-TLS client to TLS port or vice versa.

You could try to switch between port 465 and 587 when using TLS.

---

I am having the same problem. Connection to Exchange server 2013 on port 587 to a receive connector with TLS enabled and basic authentication only after TLS. TLS connectivity works from other clients and I have tested successfully with openSSL to confirm that TLSv1 is working on that port. When I try a test from Visualcron, however, it fails with "Connection test failed. Error: Unhandled error: Connection failed (error code is 75777)"

I am using the following settings:
Port: 587
Code page: Windows-1252
Authentication: (user and password)
Cryptographic protocol: TLS
Security mode: Explicit
Proxy: none

My exchange logs show a connection attempt from the client, bu as soon as the exchange server responds, the client resets the connection:



If I switch to the SSL cipher, the connection succeeds using SSLv3, but I can find no way to successfully send using the TLS cipher.

As I mentioned, I have confirmed that TLSv1 is enabled and functional on this connector:

This should have been resolved in later version.

---

Thanks for the update. I'm running version 7.5.1, but I'm unable to upgrade at this time. Can anyone else confirm if the issue is truly resolved in the newer version? The only thing I see in the Changelog  that appears related is a new feature in 7.6.2, but it looks like it just gives the ability to specify supported cipher versions. I don't see any reference to a bugfix for this TLS issue:

[FEATURE] Client/Server: SMTP Task->Added support for setting supported SSL/TLS versions

Thanks for the update. I'm running version 7.5.1, but I'm unable to upgrade at this time. Can anyone else confirm if the issue is truly resolved in the newer version? The only thing I see in the Changelog  that appears related is a new feature in 7.6.2, but it looks like it just gives the ability to specify supported cipher versions. I don't see any reference to a bugfix for this TLS issue:

[FEATURE] Client/Server: SMTP Task->Added support for setting supported SSL/TLS versions

I suggest installing latest version on your desktop or other server. You have full functionality for 45 days so you should be able to test.

---