openssl s_client で SSL/TLS通信での接続テスト(接続のみ)をしてみる

#openssl

#TLS

中村健一

2024.07.07

こんにちは。中村です。

概要

openssl s_client で SSL/TLS通信での接続テストを実施してみる

証明書を設定したけれど、あれ繋がらないな？安全でない接続先？とか
証明書に関連した作業では入門者にとっては何かと引っかかるポイントがあるかと思います。
今回は、１歩目としてサーバへの接続のみを実施してみます。

前提条件

下記ライブラリ・バージョンを利用

nakamura-kenichi@classmethod ~ % openssl version
LibreSSL 3.3.6

やってみた

まずは、利用するコマンドを確認してみます。

openssl s_client -connect <接続先サーバ情報(ドメインorIPアドレス)>:<ポート番号>

開発環境などでドメイン設定をしていないサーバの場合は、IPアドレスを入力します。
ドメインを設定されている場合でも、特定のIPアドレスを持つサーバに接続したい場合はIPアドレスを指定して接続します。

nakamura-kenichi@classmethod ~ % openssl s_client -connect dev.classmethod.jp:443
CONNECTED(00000005)
(略):SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 287 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Start Time: 1720237841
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

あれ？

SSL/TLSハンドシェイクに失敗しているぞ？
アラート番号40は、ハンドシェイクに失敗した際のレスポンスになります。

（参考）アラート番号について

アラートの内容は番号毎ににて決められています。
アラート番号には互換性があるように見受けられますが、TLSのバージョンによって、新規や廃止があるため、詳しくはRFCにて確認をお願いします。

接続先サーバの構成を知らない場合、稀によくある状況ですよね。
「先輩！証明書が設定されていません！」
とか。
ちょっと待ってください。

https://dev.classmethod.jp/

上記コマンドで指定した接続先である弊社ブログに
ブラウザから接続すると、確かに証明書が設定されており、
TLS通信もできています。

では、なぜエラーとなったのか。

ここでSNI（Server Name Indication）という仕様について
調べてみましょう。

サーバの中で仮想サーバが複数立ち上がっている場合があります。
その仮想サーバに割り当てられたサーバ名を指定しないとdefaultの仮想サーバに接続して意図しない接続先に通信することもあるのです。

SNIを考慮すると、ドメイン名も指定して接続するとよかったのですね。

openssl s_client -connect <接続先サーバ情報(ドメインorIPアドレス)>:<ポート番号>  -servername <ドメイン>

では、再度接続してみます。

nakamura-kenichi@classmethod ~ % openssl s_client -connect dev.classmethod.jp:443 -servername dev.classmethod.jp
CONNECTED(00000005)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 3
verify return:1
depth=1 C = US, O = Amazon, CN = Amazon ECDSA 256 M02
verify return:1
depth=0 CN = *.classmethod.jp
verify return:1
write W BLOCK
---
Certificate chain
 0 s:/CN=*.classmethod.jp
   i:/C=US/O=Amazon/CN=Amazon ECDSA 256 M02
 1 s:/C=US/O=Amazon/CN=Amazon ECDSA 256 M02
   i:/C=US/O=Amazon/CN=Amazon Root CA 3
 2 s:/C=US/O=Amazon/CN=Amazon Root CA 3
   i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
 3 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
   i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
(略)
-----END CERTIFICATE-----
subject=/CN=*.classmethod.jp
issuer=/C=US/O=Amazon/CN=Amazon ECDSA 256 M02
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 4330 bytes and written 378 bytes
---
New, TLSv1/SSLv3, Cipher is AEAD-AES128-GCM-SHA256
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : AEAD-AES128-GCM-SHA256
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Start Time: 1720237865
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

はい。接続ができましたね。
レスポンスから証明書のパス（Certificate chainの部分）など細かい情報が確認できます。
レスポンスの読み方は、後日改めて記事にしたいと思います！

最後に

今回は、接続テストの一例を紹介してみました。
s_clientには、さまざまなオプションが用意されています。
テストケースによっては、特定の暗号スイート接続可否を検証することも、通信できるTLSのバージョンをテストすることもあるかと思います。
必要に応じてオプションを付与し、ご自身が管理されているサーバに対して接続検証をしてみてください。

なお、お使いのライブラリやバージョンによって、実際に利用できるオプションが異なる場合があります。
公式サイトをご確認の上、お試しください。