javax.net.ssl.SSLHandshakeExceptionの主な原因と解決方法をエラーパターン別に解説

2026年3月23日

例外処理・デバッグ

Javaアプリケーションを開発・運用する中で、外部のAPIやWebサイトとセキュアな通信を行う際に、最も頻繁に遭遇するトラブルの一つがjavax.net.ssl.SSLHandshakeExceptionです。

この例外は、HTTPS通信などのSSL/TLSプロトコルを用いた通信において、接続の確立段階（ハンドシェイク）で何らかの問題が発生し、安全な経路を確保できなかったことを示しています。

セキュリティが重視される現代のシステムにおいて、SSL/TLSの重要性は増すばかりですが、その仕組みが複雑であるため、一度エラーが発生すると原因の特定に苦労することも少なくありません。

本記事では、プロのテクニカルライターの視点から、この例外が発生する根本的なメカニズムを解き明かし、エラーパターン別の具体的な原因と解決策を網羅的に解説します。

Java 11やJava 17、Java 21といったモダンな環境でも通用する最新の知見をもとに、トラブルシューティングの決定版となるガイドを提供します。

目次 [ close ]

SSL/TLSハンドシェイクの基礎知識

解決策を詳しく見る前に、まずはSSLHandshakeExceptionがどのタイミングで発生するのかを理解しておく必要があります。

SSL/TLSハンドシェイクとは、クライアント（Javaアプリケーション）とサーバーがデータをやり取りする前に、互いの身元を確認し、暗号化に使用する共通鍵を生成するための一連の儀式です。

通常のハンドシェイクは以下のステップで行われます。

STEP1

Client Hello

クライアントがサポートしているTLSバージョンや暗号スイート（Cipher Suites）のリストをサーバーに送ります。

STEP2

Server Hello

サーバーが使用するTLSバージョンと暗号スイートを決定し、自身のデジタル証明書をクライアントに送ります。

STEP3

証明書の検証

クライアントは、サーバーから送られてきた証明書が信頼できる機関（認証局）によって発行されたものか、有効期限が切れていないかなどを確認します。

STEP4

鍵交換

双方が安全に共通鍵を作成するための情報を交換します。

SSLHandshakeExceptionは、このステップのいずれかが失敗したときにスローされます。

原因は多岐にわたりますが、大きく分けると「証明書の不備」「プロトコル・暗号スイートの不一致」「ネットワーク構成の問題」の3つに分類できます。

原因1：証明書の信頼性に関するエラー（PKIX path building failed）

JavaにおけるSSLエラーの中で最も一般的なのが、ValidatorException: PKIX path building failedというメッセージを伴うものです。

これは、Javaの実行環境（JRE/JDK）が、接続先サーバーの証明書を信頼できないと判断したことを意味します。

具体的な原因

Javaはデフォルトでcacertsというファイル（信頼済みルート証明書ストア）を保持しています。

サーバーが提示した証明書、あるいはその証明書を発行した中間認証局・ルート認証局の証明書がこのcacertsに含まれていない場合、Javaは「このサーバーは怪しい」と判断して接続を遮断します。

自社運用のプライベートCA（認証局）で発行した証明書を使用している。
自己署名証明書（いわゆるオレオレ証明書）を使用している。
サーバー側で中間一致証明書の設定が漏れている。

解決方法

この問題を解決する正攻法は、サーバーの公開鍵（証明書）をJavaのcacertsにインポートすることです。

手順1：サーバー証明書の取得

ブラウザやopensslコマンドを使用して、サーバーから証明書ファイルをエクスポートします。

Shell

# opensslを使用して証明書を取得する例
openssl s_client -connect example.com:443 < /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > example.crt

手順2：JavaのTrustStoreへのインポート

keytoolコマンドを使用して、取得した証明書をインポートします。

実行には管理者権限が必要です。

Shell

# keytoolを使用したインポート例
# $JAVA_HOME は実際のJavaインストールパスに置き換えてください
keytool -import -alias example-server -file example.crt -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit

注意点：デフォルトのパスワードは changeit です。

また、本番環境ではシステム全体の cacerts を書き換えるのではなく、アプリケーション専用の TrustStore を作成し、起動引数 -Djavax.net.ssl.trustStore で指定することが推奨されます。

原因2：プロトコルバージョンの不一致

次に多いのが、クライアントとサーバーがサポートしているTLSのバージョンが噛み合わないケースです。

具体的な原因

古いJavaバージョン（Java 7や古いJava 8など）を使用している場合、デフォルトでTLS 1.2が有効になっていないことがあります。

一方で、最新のサーバーはセキュリティ上の理由からTLS 1.0や1.1を廃止し、TLS 1.2以上のみを許可していることが一般的です。

逆に、非常に古いシステムへ最新のJava 17などから接続しようとする際、サーバーが古いプロトコル（SSLv3やTLS 1.0）しかサポートしていない場合も、Java側で脆弱なプロトコルを無効化しているためにハンドシェイクが失敗します。

解決方法

Javaの起動オプションで、使用するTLSプロトコルを明示的に指定することで解決できる場合があります。

Shell

# TLS 1.2を強制する例
java -Dhttps.protocols=TLSv1.2 -jar your-app.jar

また、Java 11以降ではTLS 1.3がデフォルトでサポートされています。

もし古いプロトコルをどうしても使用しなければならない場合は、java.security ファイル内の jdk.tls.disabledAlgorithms セクションを確認し、無効化されているプロトコルの設定を編集する必要があります。

ただし、これはセキュリティリスクを伴うため、サーバー側のアップデートを優先的に検討すべきです。

原因3：暗号スイート（Cipher Suites）の不一致

ハンドシェイク中に、暗号化アルゴリズムの組み合わせである「暗号スイート」が合意に至らない場合に発生します。

具体的な原因

Java 8（以前の古いアップデート版）などでは、使用できる暗号の強度が制限されていることがあります（輸出管理の制限の名残）。

また、サーバー側が非常に限定的な暗号スイート（例えば楕円曲線暗号のみなど）を指定しており、Java側がそれをサポートしていない、あるいは優先順位が低いために選択されないといった状況が考えられます。

解決方法

まずは、使用しているJava環境の暗号制限を解除します。

最新のJDKであれば問題ありませんが、古いJDK 8などの場合は「JCE (Java Cryptography Extension) Unlimited Strength Jurisdiction Policy Files」を適用する必要があります。

また、どのような暗号スイートが試行されているかをデバッグログで確認することが重要です。

Shell

# SSLハンドシェイクのデバッグログを出力する
java -Djavax.net.debug=ssl,handshake -jar your-app.jar

このログを解析することで、ClientHelloで提示したリストと、サーバーが要求しているリストの乖離を特定できます。

原因4：ホスト名の不一致（Hostname Mismatch）

証明書自体は有効であっても、アクセスしようとしているURLのホスト名と、証明書に記載されているコモンネーム（CN）やサブジェクト代替名（SAN）が一致しない場合に発生します。

具体的な原因

例えば、証明書が example.com に対して発行されているにもかかわらず、プログラム内でIPアドレス 192.168.1.10 を指定して接続しようとすると、この検証エラーが発生します。

また、ワイルドカード証明書の適用範囲外のサブドメインにアクセスした場合も同様です。

解決方法

最も正しい解決策は、証明書に記載された正しいホスト名を使用してアクセスすることです。

開発環境などでIPアドレスによる接続が避けられない場合は、一時的にホストファイルを書き換えるか、Javaのコード側でホスト名検証をカスタマイズする仕組みを導入します。

プログラムによるデバッグと回避策の例

実際に SSLHandshakeException を調査・デバッグするためのJavaプログラムの例を紹介します。

TLS接続テストプログラム

以下のコードは、特定のURLに対してSSL接続を試み、失敗した場合に詳細なスタックトレースを出力する簡単なテスターです。

Java

import javax.net.ssl.HttpsURLConnection;
import java.net.URL;
import java.io.InputStream;

public class SSLTester {
    public static void main(String[] args) {
        // テストしたいURL
        String targetUrl = "https://self-signed.badssl.com/";

        try {
            URL url = new URL(targetUrl);
            HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
            
            // 接続試行
            conn.connect();
            
            try (InputStream in = conn.getInputStream()) {
                System.out.println("Connection successful!");
                System.out.println("TLS Protocol in use: " + conn.getCipherSuite());
            }
        } catch (Exception e) {
            System.err.println("--- SSL Handshake Error Detected ---");
            e.printStackTrace();
            // ここで例外の型を確認する
            if (e instanceof javax.net.ssl.SSLHandshakeException) {
                System.err.println("Cause: SSL handshake failed. Check certificates or TLS versions.");
            }
        }
    }
}

開発用：すべての証明書を信頼する設定（※非推奨）

注意：このコードはセキュリティを完全に無効化するため、本番環境では絶対に実行しないでください。

証明書のインポートがどうしても間に合わない開発初期段階などで、原因が「証明書の信頼性」にあることを切り分けるためにのみ使用します。

Java

import javax.net.ssl.*;
import java.security.cert.X509Certificate;

public class SSLInsecureUtils {
    public static void disableCertificateValidation() {
        try {
            TrustManager[] trustAllCerts = new TrustManager[]{
                new X509TrustManager() {
                    public X509Certificate[] getAcceptedIssuers() { return null; }
                    public void checkClientTrusted(X509Certificate[] certs, String authType) {}
                    public void checkServerTrusted(X509Certificate[] certs, String authType) {}
                }
            };

            SSLContext sc = SSLContext.getInstance("TLS");
            sc.init(null, trustAllCerts, new java.security.SecureRandom());
            HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
            
            // ホスト名検証も無視する場合
            HttpsURLConnection.setDefaultHostnameVerifier((hostname, session) -> true);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

エラーパターン別：解決チェックリスト

トラブルシューティングを迅速に行うために、以下の表を確認してください。

エラーメッセージの断片	推測される原因	優先される対策
`PKIX path building failed`	信頼されていない証明書	`keytool`で`cacerts`に証明書を追加
`handshake_failure`	暗号スイートの不一致	`javax.net.debug`で共通の暗号があるか確認
`protocol_version`	TLSバージョンの不一致	`https.protocols`でバージョンを指定
`No subject alternative names`	ホスト名不一致	正しいホスト名を使用するかSAN付き証明書を再発行
`Received fatal alert: close_notify`	サーバー側での強制切断	サーバー側のログを確認。接続制限やWAFの可能性

まとめ

javax.net.ssl.SSLHandshakeException は、一見すると難解なエラーに見えますが、その原因の多くは「証明書の信頼」か「プロトコルの互換性」のどちらかに集約されます。

エラーが発生した際は、まずJVMのシステムプロパティ -Djavax.net.debug=ssl,handshake を有効にして、詳細なログを観察することから始めてください。

どのステップで、どのようなメッセージとともに通信が途絶えたのかを知ることが、解決への最短ルートとなります。

また、セキュリティの観点から、安易に証明書検証をスキップするコードを本番環境に持ち込まないよう注意しましょう。

正しく証明書を管理し、適切なTLSバージョンを選択することは、堅牢なシステムを構築する上で不可欠なスキルです。

この記事が、複雑なSSLトラブルを迅速に解決するための一助となれば幸いです。

SSL/TLSハンドシェイクの基礎知識

原因1：証明書の信頼性に関するエラー（PKIX path building failed）

具体的な原因

解決方法

手順1：サーバー証明書の取得

手順2：JavaのTrustStoreへのインポート

原因2：プロトコルバージョンの不一致

具体的な原因

解決方法

原因3：暗号スイート（Cipher Suites）の不一致

具体的な原因

解決方法

原因4：ホスト名の不一致（Hostname Mismatch）

具体的な原因

解決方法

プログラムによるデバッグと回避策の例

TLS接続テストプログラム

開発用：すべての証明書を信頼する設定（※非推奨）

エラーパターン別：解決チェックリスト

まとめ

こちらもおすすめ