TLSVERIFY results on Ironport ESA

[SeanWatmore]

I'm trying to setup a TLS connection from my Ironport to a 3rd party.

I perform a TLSVERIFY to the 3rd parties mail server, as I have done successfully to many other domains and mail servers, and receive the following result:

Connecting to <Address removed> on port 25.
Connected to <Address removed> from interface <Address removed>.
Checking TLS connection.
Certificate verification failed: unable to get local issuer certificate.
TLS connection to <Address removed> failed: verify error.
TLS was required but could not be successfully negotiated.

Failed to connect to <server name removed>.
TLS verification completed.

When I do a check on checktls.com to the same mail server, it reports everything is OK.

So as I see it this is the far-end mail server failing to send the full certificate chain. Hopefully I'm correct in the reading of the situation?

If, however, this is advising me that the ironport is missing an intermediate certificate or similar, how do I go about identifying which cert is missing, and applying that cert to the Ironport ESA?

Many Thanks

Sean

[Greg.Howley]

Check with the other end.

I had a similar problem with a business partner that only advertised TLS if you had already contacted them: checkTLS said everything was good, preffered TLS from my Ironport went in the clear, telnetting to their gateway refused the STARTTLS command.

[Mathew Huynh]

Hello Greg,

Thanks for the update.

On the ESA you can find the current list of CAs in GUI > Network > Certificates > Edit settings on the bottom and load in your custom list or to view the current existing system list.

Regards,

Matthew

[SeanWatmore]

Matthew,

Thanks for you comment.

I tried this yesterday (delay caused by change control measures).

I applied the full CA chain ( the root authority and the domain authority) for the destination site I need TLS to work on.

When I tested I received the same result.

I guess I now have to raise a TAC case to see if this is an issue at the ironport or not.

Regards

Sean

[Mathew Huynh]

Hey Sean,

I believe the TLSverify action is very strict on the ESA and if the destination side is using a SAN or wildcard cert the verify may fail using the TLS verify command for checking.

Regards,

Matthew

[SeanWatmore]

Matthew,

Do you have the constraints which have to be matched?

Maybe the 3rd parties cert isn't providing sufficient information, however I am unable to diagnose this using the tools to hand.

Sean

[Mathew Huynh]

Hey Sean, 

I believe it needs to be properly chained and the Ca signed needs to be within the list the esa supports.  Additionally to ensure there is no interruptions during the ssl negotiations. 

I personally use checktls for verification more so than tlsverify due to the strict nature of it. 

However I'll see if I can get some further details to this 

Regards 

Matthew 

[SeanWatmore]

Matthew,

Thanks for getting back to me.

checktls tests OK. But still the TLSVERIFY fails.

I found another resource through, Co-Pibot (www.tbs-internet.com), where I ran the TLS check there also.

This returned that there was error:

DIAGNOSIS:
• Error 41: DOMAIN VALIDATED = This certificate is a Domain Validated certificate which provides no authentication security

I have now raised a TAC case, hopefully we'll be able to work through to a solution.

I'll update the forum, once I have a result.

Regards

Sean

[Mathew Huynh]

Hey Sean,

Ensure the domain you're looking at with the TLSverify, their certificate chain where the authorities are listed, is within the trusted CAs on the ESA.

If they are not within this list, more often than not, TLSverify command will fail.

Else you may need to manually add a custom certificate authority list to use as well if not listed.

1) Please go to the the CA's website to obtain the Root CA certificate so you can add it to your ESA

2) Access the Graphical User Interface of the appliance and use the 'Network >
Certificates' page and click on "Edit Settings"

3) Click "Export List" and select the type of list you are currently using (custom or
system). The filename will be set automatically, and you can then export the list to your
local PC.

4) Open the exported list with a text editor. Then copy and paste the .pem certificate
retrieved in step 1 just into the opened file, and save it under a different filename like
CA_list_modified.txt

5) Go back to 'Network > Certificates' page and click on "Edit Settings":
- Disable the system list
- Enable the custom list, and click browse to upload the modified file
- Submit and commit your new setting.

6) Re-run the tlsverify command on the Command Line Interface, and certificate
verification should succeed.

Regards,

Matthew

[SeanWatmore]

Thank you Matthew and Greg,

Currently we believe the issue is one related to the CAs on the ESA not being all that current.

We are therefore looking to install Custom CA file with the missing CA for the cert being presented by the 3rd party.  We figure having tested elsewhere that this should resolve the issue.

I will update once this has been tried and tested.

Sean