Есть много предложений, но я нашел два наиболее распространенных.

Re. JAVA_OPTS

Я сначала попробовал export JAVA_OPTS="-Dhttps.protocols=SSLv3,TLSv1,TLSv1.1,TLSv1.2" в командной строке перед запуском программы, но у меня это не сработало.

Re. конструктор

Затем я добавил следующий код в конструктор класса запуска, и у меня он сработал.

try {
        SSLContext ctx = SSLContext.getInstance("TLSv1.2");
        ctx.init(null, null, null);
        SSLContext.setDefault(ctx);
} catch (Exception e) {
        System.out.println(e.getMessage());
}

Честно говоря, я не знаю подробно, почему ctx.init(null, null, null);, но все (SSL / TLS) у меня работают нормально.

Re. System.setProperty

Есть еще один вариант: System.setProperty("https.protocols", "SSLv3,TLSv1,TLSv1.1,TLSv1.2");. Это тоже войдет в код, но я не пробовал.

Вы можете обновить версию Java 7 до 1.7.0_131-b31

Для JRE 1.7.0_131-b31 на сайте Oracle:

TLSv1.2 и TLSv1.1 теперь включены по умолчанию на конечных точках клиентов TLS. Это похоже на то, что уже происходит в выпусках JDK 8.

Добавьте следующую опцию для Java-приложения:

-Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2  

Добавьте этот параметр в JAVA_OPTS или в командную строку в Maven: -Dhttps.protocols=TLSv1.2

System.setProperty("https.protocols", "TLSv1.2"); работал в моем случае. Вы проверили это в приложении?

Заявленные ответы верны, но я просто поделюсь одним дополнительным подвохом, который был применим к моему случаю: помимо использования _1 _ / _ 2_, у вас могут быть неприятные банки, которые не исчезнут, даже если у вас есть правильные банки плюс Старый:

Удалять

<dependency>
    <groupId>commons-httpclient</groupId>
    <artifactId>commons-httpclient</artifactId>
    <version>3.1</version>
</dependency>

Удерживать

<dependency>
    <groupId>org.apache.httpcomponents</groupId>
    <artifactId>httpclient</artifactId>
    <version>4.5.2</version>
</dependency>

<dependency>
    <groupId>org.apache.httpcomponents</groupId>
    <artifactId>httpcore</artifactId>
    <version>4.4.6</version>
</dependency>

Java имеет обратную совместимость, но большинство библиотек - нет. С каждым днем ​​мне все больше хочется, чтобы общие библиотеки были объявлены вне закона из-за отсутствия подотчетности.

Дополнительная информация

java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)

Чтобы принудительно включить TLSv1.2 в JRE7u_80, мне пришлось использовать следующий фрагмент кода перед созданием соединения JDBC.

import java.security.NoSuchAlgorithmException;
import java.security.Provider;
import javax.net.ssl.SSLContextSpi;
import sun.security.jca.GetInstance;
import sun.security.jca.ProviderList;
import sun.security.jca.Providers;

public static void enableTLSv12ForMssqlJdbc() throws NoSuchAlgorithmException
{
    ProviderList providerList = Providers.getProviderList();
    GetInstance.Instance instance = GetInstance.getInstance("SSLContext", SSLContextSpi.class, "TLS");
    for (Provider provider : providerList.providers())
    {
        if (provider == instance.provider)
        {
            provider.put("Alg.Alias.SSLContext.TLS", "TLSv1.2");
        }
    }
}

Возможность подключения к Windows 10 с ОС SQL Server 2017 и TLSv1.2.

Вероятно, вам следует обратить внимание на конфигурацию, которая управляет реализацией TLS базовой платформы через -Djdk.tls.client.protocols=TLSv1.2.

Я решил эту проблему, используя

Service.setSslSecurityProtocol(SSLSecurityProtocol.TLSv1_2);

У меня была аналогичная проблема при подключении к RDS Oracle, даже когда клиент и сервер были настроены на TLSv1.2, сертификаты были правильными, а java - 1.8.0_141. Итак, наконец, мне пришлось применить патч на Файлы политики юрисдикции неограниченной надежности Java Cryptography Extension (JCE)

После применения патча проблема исчезла, и соединение прошло нормально.