If you were about to ask one of the questions from the list below, this topic is for you:

My SSL/TLS components used to work fine but suddenly stopped working for no apparent reason.

I was able to connect to the TLS (FTPS, SMTPS, POP3S) server with SBB 11/10/9/… just fine, but I can't connect after upgrading to SBB12 any more.

My server provider has upgraded their TLS endpoint (or updated their certificate) and I can't connect any more.

I'm just unable to connect to a TLS server I need to connect to.

Being fairly general terms, 'can't connect' and 'stopped working' can be represented by a variety of symptoms, from socket errors (100XX, e.g. 10060) and SecureBlackbox SSL errors (75xxx, e.g. 75782) to 'control channel transfer error'-like exceptions.

After major shake-up in global SSL/TLS ecosystem that followed a row of vulnerabilities discovered in different versions of the protocol during a period of 2012-2015, the compatibility balance that was being built up between the implementations for years was challenged. To counteract the attacks, TLS users and administrators were advised to implement a variety of measures in their environments, including as ground breaking as complete cease of support for particular protocol versions – SSL 2.0 and SSL 3.0, to be specific. While most of those measures are fairly friendly compatibility-wise, the others are not and may need specific tune-up to overcome connectivity problems, which sometimes may involve a certain level of a trade-off. This particularly concerns the protocol versions issue – on one hand, an SSL3-capable client just won't connect to a TLS 1.x-only server, while a TLS 1.x-only client won’t connect to an older server that only supports SSL 3.0. Therefore you need to choose whether you want your SSL/TLS client to be compatible to newer or older servers – and you can't be compatible to both at the same time.

The positive side of these perturbations is that we could probably expect the whole TLS world to implement support for the newest arrangements in TLS 1.x in short term to be able to resist the discovered attacks and be compatible to the others in the boat. However, a small share of implementations that just can't be upgraded (e.g. based on hardware or exotic embedded solutions) is likely to remain alive for quite some time and will need special handling from parties that need to communicate to them.

So, let's go down to the problem. Your SecureBlackbox-powered application just won't connect to an SSL/TLS-capable server (you can add a variety of endings here - 'that it was able to connect before', 'that it was able to connect to with earlier version of SecureBlackbox', or 'whereas IE, Mozilla, Google Chrome, FileZilla or OpenSSL connect just fine' – or just can leave it as it is). If you are reading this in 2015, 95 out of 100, the issue is caused by a compatibility problem that can be resolved by tuning the client component up. The underlying reason is either (1) the server having employed the new TLS guidelines recently (by e.g. ceasing SSL 3.0 support) and not being able to accept connections from your 'less secure' (sic) client any more, or (2) the client having employed the same guidelines and failing to connect to an older and 'less secure' server.

It should be noted that during the life time of SecureBlackbox 12 the default configurations of the SSL/TLS components (primarily client-side) were progressively tuned-up to cater for new 'best practices' suggested by TLS experts and the actual course of events in the ecosystem. We did our best to keep the components as compatible as possible at the same time, yet in certain cases (like versions example above) 100% compatibility just couldn't be achieved. Therefore different builds of version 12 may expose different behaviours even when connecting to the same server - this is normal and is not an indicator of any problem or bug. This is due to a different default setup of the components in different version 12 builds which makes them behave differently out of the box. Yet, each newer product build is expected to be more compatible than the preceding ones, so it makes sense to upgrade to the freshest available version first when coming across an issue and checking if the updated component addresses the issue out of the box.

You are expected to follow the steps described below in order, trying to re-establish the connection after each step and checking if it helps. Each step aims to increase the compatibility level of the client component bit by bit by switching off the parameters that might affect connections to certain exotic servers (but not trading off too much of security). Each following step assumes that you preserve the changes you've made on a previous step, unless explicitly instructed otherwise. If you followed all the steps and still can't connect, you are welcome to create a dedicated forum or help desk topic for your problem where our engineers will try to have a deeper look into it and come up with some bespoke solution.

Before you go with the steps:

Pre-Step 1. Check that you are using the latest version 12 build (check here).

Pre-Step 2. Switch off certification validation by simply returning Valid = true from the OnCertificateValidate event handler (REMEMBER TO RESTORE IT BACK LATER).

Step 4. If using higher-level SSL component, such as TElSimpleSSLClient or TElHTTPSClient, remove the ssloAutoAddServerNameExtension flag from the Options flag set.

Step 5. Enable the following set of versions only: [SSL 3.0, TLS 1.0]. If you manage to connect fine after this adjustment, please note that this mode is insecure and should not be used as a default mode for your software. The server you are connecting to is old, insecure and is likely to be upgraded soon. Please use this mode as an exception and always try to connect to other servers with SSL 3.0 switched off first.

If after this step you still can't connect, please create a separate topic in the forum or help desk.

Remember to restore your certificate validation handler after finding the working configuration!

Generally, it might make good sense to start supporting SSL setting profiles in your SBB-driven software and allow your users to choose a profile from the list in case of a problem. This will help you reach the highest levels of compatibility and provide your customers with a high quality, adjustable and stable solution.

As of March 2015 we would recommend the following set of profiles for HTTPS connections. As FTPS, SMTPS and POP3S servers worldwide are upgraded less operatively than HTTPS, it is a good idea to provide a specific compatible profile for them:

The above set of preset profiles only reflects our view of the situation in SSL/TLS ecosystem as of March 2015. As the environments are changing extremely quickly, the list might need updating in future. We will try to do our best to maintain it in the up-to-date state, so it is a good idea to check this page for updates from time to time and adjust your code as suggested.

We use cookies to help provide you with the best possible online experience. By using this site, you agree that we may store and access cookies on your device. You can find out more about and set your own preferences here.