Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Messaging Gateway 10.0.3 Cannot register specified license file, unable to communicate errno, 104

Created: 06 Nov 2013 • Updated: 19 Nov 2013 | 3 comments
This issue has been solved. See solution.

Messaging Gateway Version 10.0.3 (Virtual appliance running on VMWare ESXi 5.1.0)

Getting error:

Cannot register the specified license file.
Unable to communicate with Symantec to register. Please check your connection settings, and try again. Connection error 52: SSL read: error:00000000:lib(0):func(0):reason(0), errno 104

Tested dns:

Scanmail> nslookup register.brightmail.com
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
Name:   register.brightmail.com
Address: 143.127.103.14
Name:   register.brightmail.com
Address: 216.250.24.63

Tested connectivity:

scanmail> telnet register.brightmail.com 443
Trying 216.250.24.63...
Connected to register.brightmail.com.
Escape character is '^]'.

Time and date are correct.  Any suggestions?

 

Operating Systems:

Comments 3 CommentsJump to latest comment

sjelinek's picture

From searching on the web I came across this article:

http://drjohnstechtalk.com/blog/2013/07/the-it-detective-agency-strange-ssl-error-explained/

He received a very similar error message.  His system is running on an F5 BigIP loadbalancer with the F5 as ssl accelerator.  His testing of SSL showed that the SSL was working but...

OK, so, SSL is handled by the F5 itself we were saying. That leaves the origin server. Bingo!

In F5 you have virtual servers and pools. You configure the SSL CERTs and the public-facing IP and the pool on the virtual server. The pool is where you configure your origin server(s).

I had forgotten to associate a default pool with my virtual server! So the F5 had nowhere to go really with the request after handling the initial SSL dialog.
<snip>
So I associated a pool with my virtual server and immediately the problem went away

Can anyone from Symantec check to see if this is the problem?

sjelinek's picture

Continuing the search for a solution, I came across an article that mentions a Symantec site to check if your certificates are properly installed.

From:

https://ssltools.websecurity.symantec.com/checker/views/certCheck.jsp

Certificate installation check failed
register.brightmail.com
You have 1 error
Certificates installed in the wrong order.
Some certificates in the chain are installed in the wrong order. See details below. Reinstall the certificates in the proper order.
Recommendations
Certificate informationCommon name: register.brightmail.com
SAN: REGISTER.BRIGHTMAIL.COM
Valid from: 2013-Aug-14 00:00:00
Valid to: 2015-Nov-10 23:59:59
Organization: Symantec Corporation
Organizational unit: IT Security
City/locality: Mountain View
State/province: California
Country: USSerial number: 298831b424f3a6f6eaeffe2ed9ce4c4c
Algorithm type: SHA1withRSA
Key size: 2048
Certificate chain
Show details
register.brightmail.com
Tested certificate
VeriSign Class 3 Public Primary Certification Authority - G5Intermediate certificate
VeriSign Class 3 International Server CA - G3Intermediate certificate

Would someone from Symantec check this, please?

 

sjelinek's picture

Ok,  got this worked out.

With the assistance of Stephen (sorry, all I have of the name) from Symantec Technical Support we got this figured out.

It isn't the certificates on the register.brightmail.com site. They should be fixed, but they aren't the cause.

When Stephen said the problem is often firewalls, I didn't think so, but I went ahead and brought up the real time logs, and tried to register the Gateway again.  Sure enough, a list of warnings that the packet was 1420 bytes  and greater than the effective MTU of 1380.

The problem was the MTU on the WAN port of my Cisco ASA 5515.  It was set to 1380, (someone was testing something, don't ask) I reset it to the default 1500, and attempted the registration again and, voila! the gateway is registered. 

If you can't access your firewall or other appliance directly, get your network admin to watch the logs while you attempt to connect--you might find your problem.

 

SOLUTION