状況の説明

下記の投稿を確認してください。

環境

ローカルOS: WSLのUbuntu-24.04
リモートOS: Amazon Linux 2023
vsftpd: version 3.0.5
openssl 3.0.8

仮説 1

サーバー側のOpenSSLで設定している暗号化スイートとは異なる暗号化スイートを使用し、lftpがGnuTLSでFTPS接続しようとしているため、再ネゴシエーションが拒否される

確認すること (その 1)

暗号化スイート（vsftpd、httpd)と TLSプロトコルバージョン (gnutls)の設定を確認

Step1. opensslコマンドで確認

サーバー側でopenssl s_server コマンドを使用し、サーバー証明書と秘密鍵を指定し、特定の暗号化スイートをテストします。

.bash

sudo openssl s_server -cert /etc/pki/tls/certs/localhost.pem -key /etc/pki/tls/private/localhost.key -port 443 -ciphersuites ECDHE-ECDSA-AES128-GCM-SHA256
-www
Call to SSL_CONF_cmd(-ciphersuites, ECDHE-ECDSA-AES128-GCM-SHA256) failed
805BBA0CB77F0000:error:0A0000B9:SSL routines:set_ciphersuites:no cipher match:ssl/ssl_ciph.c:1345:

右記、man openssl s_server によるこのコマンドの説明です。「このコマンドは、SSL/TLS を使用して指定されたポートで接続をListenする汎用 SSL/TLS サーバーを実装します。」

This command implements a generic SSL/TLS server which listens for connections on a given port using SSL/TLS.

今回暗号化スイートは ECDHE-ECDSA-AES128-GCM-SHA256 を指定しました。上記のopenssl s_serverの実行結果を見ると、failedとなっています。その下の行には、no cipher match (一致する暗号化スイートがありません)というエラーメッセージが表示されているのが分かります。

Step2. サーバーの設定を確認

暗号化スイートを確認します。openssl s_server はhttpdのポート番号443を指定して確認しましたので、まずはhttpdの設定ファイルで暗号化スイートを確認してみます。

/etc/httpd/conf.d/ssl.conf

# みやすいように改行していますが、実際にはコロンで連結し、一行で設定しています。
SSLCipherSuite          
          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
          :ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
          :DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
          :DHE-RSA-CHACHA20-POLY1305

httpdの設定では ECDHE-ECDSA-AES128-GCM-SHA256が設定されています。これはさきほどopensslコマンドでテストしてfailedとなった暗号化スイートです。なのでこの暗号化スイートでのTLS接続が失敗している、ということになります。コロン (:) で後ろに連結して設定しているほかの暗号化スイートも総当たりで openssl s_serverコマンドで確認してみましたが、すべてfailedとなりました。

httpsではじまるURLにブラウザからアクセスはできているのに、openssl s_serverで確認したら failedになっているのは、何かがおかしいということです。暗号化スイートあたりの設定が原因かもしれません。
no cipher match (一致する暗号化スイートがありません)ということですので、上記の/etc/httpd/conf.d/ssl.confとは別に、設定が必要なファイルがある（設定ファイルじたいが違うとか）か、設定ファイルのパスが違うとかなのかもしれません。

Step3. vsftpdの設定を確認

ついでに、vsftpdも同じように設定されているのか、確認してみます。

/etc/vsftpd/vsftpd.conf

ssl_ciphers=kEECDH+AESGCM+AES128:kEECDH+AESGCM:kEECDH+AES128:kEECDH+AES:!aNULL:!eNULL:!LOW:!EXP

こちらはECDHや AES128、GCMなどの文字列は見えますが、ECDSAやSHA256の文字列は見えません。そのあたりの設定が必要なのかもしれません。この場合、次の節でvsftpdの設定を修正する必要があります。

openssl s_serverでvsftpd.confのkEECDH+AESGCMに対応させて暗号化スイートをECDHE-AES-GCMと指定してみましたが、やはりこちらもfailedとなってしまいます。また、Step1で-port 443 に対してテストしたのと同様、no cipher match (一致する暗号化スイートがありません)というエラーメッセージが表示されています。

.bash

sudo openssl s_server -cert /etc/pki/tls/certs/localhost.pem -key /etc/pki/tls/private/localhost.key -port 21 -ciphersuites ECDHE-AES-GCM -www
Call to SSL_CONF_cmd(-ciphersuites, ECDHE-AES-GCM) failed
809BEA0DFB7F0000:error:0A0000B9:SSL routines:set_ciphersuites:no cipher match:ssl/ssl_ciph.c:1345:

Step 4. 【任意】gnutlsの設定を確認 (クライアントがgnutlsを使用している場合)

gnutlsの設定ファイルのdisabled-versionでtls1.2以外を無効化します(TLS v1.2の暗号化スイートを使用する場合)。また、default-priority-stringで優先するプロトコルバージョンを指定します。※ただし、すでにvsftpdやopensslなどで同様の設定をしていると仮定します

/etc/gnutls/config.ini

[overrides]
disabled-version = tls1.0
disabled-version = tls1.1
disabled-version = tls1.3
disabled-version = dtls0.9
disabled-version = dtls1.0
default-priority-string = NORMAL:-VERS-TLS-ALL:+VERS-TLS1.

上記設定で、openssl s_serverでTLS v1.2以外がはじかれるかどうか見てみました。error:80000062:system library:BIO_bind:Address already in use:crypto/bio/bio_sock2.cや error:10000075:BIO routines:BIO_bind:unable to bind socket:crypto/bio/bio_sock2.cというメッセージが表示されています。

ちなみに下記の対処法 (その 1)を行った結果も、同じエラーが出てきます。その対処法で、解決できましたのでそちらを確認してください。

タイトルとは別のエラーになりますので、このエラーメッセージについて詳しいことは割愛します。

.bash

sudo openssl s_server -cert /etc/pki/tls/certs/localhost.pem -key /etc/pki/tls/private/localhost.key -port 21 -no_tls1_2 -www
Using default temp DH parameters
805BC68C8D7F0000:error:80000062:system library:BIO_bind:Address already in use:crypto/bio/bio_sock2.c:176:calling bind()
805BC68C8D7F0000:error:10000075:BIO routines:BIO_bind:unable to bind socket:crypto/bio/bio_sock2.c:178:
   0 items in the session cache
   0 client connects (SSL_connect())
   0 client renegotiates (SSL_connect())
   0 client connects that finished
   0 server accepts (SSL_accept())
   0 server renegotiates (SSL_accept())
   0 server accepts that finished
   0 session cache hits
   0 session cache misses
   0 session cache timeouts
   0 callback cache hits
   0 cache full overflows (128 allowed)

対処法 (その 1)

httpdとvsftpdの暗号化スイートの設定を見直す

Step 1. httpdの暗号化スイートの設定

HTTPSの設定でまず思ったのが、Apacheのmod_sslの設定が十分なのかということ。そもそも httpdのSSLの設定(/etc/httpd/conf.d/ssl.conf)と、mod_sslの設定がリンクしているのかが分かっていませんでした。
Copilot (MicrosoftのChatgpt)にきくと、その認識でいいということでした。（詳しくは調べていません）なのでこれはスルーします。

Step 2. vsftpdの暗号化スイートの設定を確認

FTPSの方は、以下のようにvsftpd.confに OpenSSL方式で指定していますが、その文法や一つ一つの要素がちゃんと理解できていませんでした。

vsftpd.conf

# 元々設定ファイルに記載していた内容
# ※ 不十分のため本投稿で修正します (後述)
ssl_ciphers=kEECDH+AESGCM+AES128:kEECDH+AESGCM:kEECDH+AES128:kEECDH+AES:!aNULL:!eNULL:!LOW:!EXP

また、前の節での仮定に対する確認事項で、Step 4. に書いてあるように、ECDSAやSHA256の設定が必要なのかもしれません。この節ではそこを確認し直します。

追記 (2025/5/12)
ECDSAで署名していたと勘違いして思っていましたが、あとでRSAで署名し直したことを思い出したため、ECDHEを含む暗号化スイートを使用しないように投稿の内容を修正しました。

Step 3. 暗号化スイートをリストアップ

設定したい暗号化スイートを openssl ciphers -v でリストアップします。パラメータの書き方は、+で、複数の暗号化スイート (AESやECDHE)の要素を連結します。:でいろんな組み合わせ (ECDHEやRSA)を指定できます。:+で、リストの末尾 (優先順位を最下位にする)にとばします。たとえば、:+AES256で、AES256を含むものはリストの末尾にいどうします。

.bash

# **こちらを実行（追記：2025/5/12)**
sudo openssl ciphers -v 'AESGCM+ECDHE+aRSA:CHACHA20+ECDHE+aRSA:+AES256'
TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(256)            Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256   TLSv1.3 Kx=any      Au=any   Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(128)            Mac=AEAD
TLS_AES_128_CCM_SHA256         TLSv1.3 Kx=any      Au=any   Enc=AESCCM(128)            Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2 Kx=ECDH     Au=RSA   Enc=AESGCM(256)            Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2 Kx=ECDH     Au=RSA   Enc=AESGCM(128)            Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305    TLSv1.2 Kx=ECDH     Au=RSA   Enc=CHACHA20/POLY1305(256) Mac=AEAD

# 【参考情報】本投稿の修正前のパラメータにつき、読み飛ばし推奨（追記：2025/5/12)
sudo openssl ciphers -v 'AESGCM+ECDHE:AESGCM+DHE+aRSA:CHACHA20+ECDHE:CHACHA20+DHE:+AES256
'

Step 4. 暗号化スイートの設定 (httpdとvsftpd)

httpd

/etc/httpd/conf.d/ssl.conf

# **こちらを入力**（追記：2025/5/12)
SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384

# 【参考情報】本投稿の修正前のパラメータにつき、読み飛ばし推奨（追記：2025/5/12)
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384

vsftpd
【追記: 2025/5/13】WinSCP も使用している場合、何も設定していない状態では暗号化スイートは ECDHE-RSA-AES256-GCM-SHA384が使用されます (Amazon Linux 2023でシステムログに表示されていた暗号化スイート)。接続ができませんので、下記ssl_ciphersの末尾の:+AES256は削除してください。

/etc/vsftpd/vsftpd.conf

# **こちらを入力**（追記：2025/5/12)
ssl_ciphers=AESGCM+ECDHE+aRSA:CHACHA20+ECDHE+aRSA:+AES256

# 【参考情報】本投稿の修正前のパラメータにつき、読み飛ばし推奨（追記：2025/5/12)
ssl_ciphers=AESGCM+ECDHE:AESGCM+ECDHE+aRSA:AESGCM+DHE+aRSA:CHACHA20+ECDHE:CHACHA20+DHE:+AES256

/etc/vsftpd/vsftpd.conf

# または、明示的に安全でないものを除外
ssl_ciphers=AESGCM+ECDHE+aRSA:CHACHA20+ECDHE+aRSA:!aNULL:!eNULL:!LOW:!EXP:+AES256

vsftpdを再起動

.bash

sudo systemctl restart vsftpd.service

opensslコマンドで確認

.bash

# TLSv1.2の暗号化スイートを使用する場合、-cipherをつける
# -ciphersuitesをつけると、TLSv1.3で利用可能な暗号化スイートを使用する
sudo openssl s_server -cert /etc/pki/tls/certs/localhost.pem -key /etc/pki/tls/private/localhost.key -port 21 -cipher ECDHE-ECDSA-AES128-GCM-SHA256
Using default temp DH parameters
800BCA6C877F0000:error:80000062:system library:BIO_bind:Address already in use:crypto/bio/bio_sock2.c:176:calling bind()
800BCA6C877F0000:error:10000075:BIO routines:BIO_bind:unable to bind socket:crypto/bio/bio_sock2.c:178:
   0 items in the session cache
   0 client connects (SSL_connect())
   0 client renegotiates (SSL_connect())
   0 client connects that finished
   0 server accepts (SSL_accept())
   0 server renegotiates (SSL_accept())
   0 server accepts that finished
   0 session cache hits
   0 session cache misses
   0 session cache timeouts
   0 callback cache hits
   0 cache full overflows (128 allowed)

"Address already in use" というエラーが出る場合
openssl s_serverコマンドで確認すると、
error:80000062:system library:BIO_bind:Address already in use:crypto/bio/bio_sock2.cや error:10000075:BIO routines:BIO_bind:unable to bind socket:crypto/bio/bio_sock2.cというメッセージが表示されています。

そこで、21番ポートをnetstatとlsofで確認してみると、以下のようになりました。

.bash

# 21番ポートでLISTENしている
sudo netstat -nao | grep ":21"
tcp6       0      0 :::21                   :::*                    LISTEN      off (0.00/0/0)

# vsftpがLISTENしている
sudo lsof -i :21
COMMAND     PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
vsftpd  2751136 root    4u  IPv6 16715547      0t0  TCP *:ftp (LISTEN)

ファイアウォールは以下。

.bash

sudo firewall-cmd --permanent --list-all
public
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: dhcpv6-client https mdns ssh
  ports: 80/tcp 443/tcp xxxxx-xxxxx/tcp 21/tcp # 21番ポートを許可 (xxxはパッシブモードのポート範囲)
  protocols:
  forward: yes
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

21番を使用している vsftpdのプロセスIDを指定して、ポートを解放します。

.bash

#  vsftpdのプロセスを強制終了
sudo kill -9 2751136
# 再び確認
sudo lsof -i :21
sudo netstat -nao | grep ":21" # 21番ポートが解放され、LISTENもしていない
# 再び TLS v1.2の暗号化スイートでのSSL接続を確認
sudo openssl s_server -cert /etc/pki/tls/certs/localhost.pem -key /etc/pki/tls/private/localhost.key -port 21 -cipher ECDHE-ECDSA-AES128-GCM-SHA256
Using default temp DH parameters
ACCEPT # 無事、接続が受け付けられた

対処法 (その 2)

そのほかの設定を確認する
※本節は、2025/5/12 追記
上記の対処法を試してみても、まだうまくいかず、Fatal error: gnutls_record_recv: An unexpected TLS packet was received. というエラーが出たままの状態になりました。

システムログを見てみる

システムログを見てみると、真ん中の方に vsftpd[2805866]: [ftp-user] OK LOGIN: Client "::ffff:xxx.xx.xx.194" と表示されています。

クライアント側のグローバルIPアドレスが正しく認識されていて、ftp-userでログインが正常にできていることが分かります。

.bash

[ec2-user@ip-xxx-xx-xx-250 log]$ sudo journalctl -af
May 12 05:12:40 ip-xxx-xx-xx-250.ap-northeast-1.compute.internal audit[2805866]: USER_ACCT pid=2805866 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix acct="ftp-user" exe="/usr/sbin/vsftpd" hostname=M106072191194.v4.enabler.ne.jp addr=xxx.xx.xx.194 terminal=ftp res=success'
May 12 05:12:40 ip-xxx-xx-xx-250.ap-northeast-1.compute.internal audit[2805866]: CRED_ACQ pid=2805866 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_listfile,pam_shells,pam_unix acct="ftp-user" exe="/usr/sbin/vsftpd" hostname=M106072191194.v4.enabler.ne.jp addr=xxx.xx.xx.194 terminal=ftp res=success'
May 12 05:12:40 ip-xxx-xx-xx-250.ap-northeast-1.compute.internal vsftpd[2805866]: [ftp-user] OK LOGIN: Client "::ffff:xxx.xx.xx.194"
May 12 05:12:40 ip-xxx-xx-xx-250.ap-northeast-1.compute.internal audit[2805871]: AVC avc:  denied  { write } for  pid=2805871 comm="vsftpd" name="html" dev="xvda1" ino=8533329 scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=dir permissive=1
May 12 05:12:59 ip-xxx-xx-xx-250.ap-northeast-1.compute.internal audit[2805872]: USER_ACCT pid=2805872 uid=1000 auid=1000 ses=138 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix acct="ec2-user" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
May 12 05:12:59 ip-xxx-xx-xx-250.ap-northeast-1.compute.internal audit[2805872]: USER_CMD pid=2805872 uid=1000 auid=1000 ses=138 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/var/log" cmd=6A6F75726E616C63746C202D6166 exe="/usr/bin/sudo" terminal=pts/0 res=success'

また、21番ポートはvsftpdがLISTENしていたため、このポートでftp-userでvsftpdにログインし、コントロールコネクションが張れていると思われます。（なお、立て続けに2度接続したのでシステムログのpidの値とは違う値になっています）

.bash

[ec2-user@ip-xxx-xx-xx-250 log]$ sudo lsof -i ":21"
COMMAND     PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
vsftpd  2798517 root    4u  IPv6 16993895      0t0  TCP *:ftp (LISTEN)

ということは、データコネクションの方で問題が起きているとみていいと思います。ちなみにvsftpdのログには何も出ていませんでした。

（補足）セッションの再利用はされているかも？

あまり本筋とは関係ないですが、備忘録的に。急いでいる場合は読み飛ばしてOKです。

セッションの再利用がvsftpdのどこかのバージョンからデフォルトになっています。クライアントによっては (curlなど)、再利用には対応していないものがあります。なので再利用するしないにかかわらず、require_ssl_reuse=NOに設定することでvsftpdに接続できるようにしていました。

.bash

[ec2-user@ip-xxx-xx-xx-250 log]$ sudo cat /etc/vsftpd/vsftpd.conf | grep "require_ssl_reuse"
require_ssl_reuse=NO

ですが、上記のシステムログを見る限り、2度立て続けにFTP接続を行っても、[ftp-user] OK LOGINのメッセージは一度目にしか表示されていないようでした。

これは、もしかしたら1回目のセッションが再利用できているのかもしれません。その場合、クライアントはlftpでftpコマンドを発行しているため、lftpあるいはftpがセッションの再利用に対応していることになります。（つまり、require_ssl_reuse=NOはなくてもかまわない。）

コラム: GnuTLSの仕様を見てみた

(少し箸休めに。急いでいる方は最後の『対処法その3』にスキップしてください。)
今回、TLSv1.2を利用しています。GnuTLSのドキュメントを見てみると、プロトコルのハンドシェイクの違いについて以下のように書いてありました。

TLS 1.2 以前では、鍵再生成、再認証、再ネゴシエーションの区別がありませんでした。これらのユースケースはすべて、TLS の再ハンドシェイクプロセスによって処理されます。そのため、GnuTLS では再ハンドシェイクはアプリケーションに対して透過的ではなく、アプリケーションが明示的にそのプロセスを制御する必要があります。

これを読むと、そもそも再ネゴシエーションはTLSv1.2では概念としてはまだ洗練されていなく、サーバー側ではなくアプリケーション側で実装するようになっているように読み取れます。

また、再ハンドシェイクについて以下のように書かれてあります。

クライアントはいつでも再ハンドシェイクを開始できます。これは、gnutls_handshake を呼び出すことで実現でき、ハンドシェイクの結果はgnutls_handshakeの戻り値によって判断されます（サーバーは再ハンドシェイクを拒否する場合があります）。サーバーが再ハンドシェイクを要求した場合、gnutls_record_recvを呼び出すとクライアントで GNUTLS_E_REHANDSHAKE が返され、gnutls_handshakeを呼び出すように指示されます。

エラーメッセージを見るとgnutls_record_recvでエラーがあったようです。上記のドキュメントを参考にすると、サーバーが再ハンドシェイクを要求するときにgnutls_record_recvが呼び出されるようになっています。

A server could also encounter the GNUTLS_E_REHANDSHAKE error code while receiving data. That indicates a client-initiated re-handshake request. In that case the server could ignore that request, perform handshake (unsafe when done generally), or even drop the connection.

このドキュメントの内容から、サイハンドシェイクがクライアント主導で開始された場合、GNUTLS_E_REHANDSHAKEのエラーコードを受け取ります。その結果ハンドシェイクの要求を無視し、接続を拒否することがあります。

そのため、今回のようなエラーが出ていると思われます。

対処法 (その3)

【参考情報】GnuTLSで暗号化スイートを設定する

以下のサイトを参考に、gnutls-cli を使用し、暗号化スイートの設定をおこないます。

なお、WSLのUbuntu-24.04 (noble)のディストリビューションでは、gnutls-cliをインストールしようとしてもできなかったため (E: Unable to locate package)、実際にgnutlsに暗号化スイートを設定してエラーの解消を確かめられていません。参考までに。

.bash

# aptパッケージリストを更新する
[ec2-user@ip-xxx-xx-xx-250 ~]$ sudo apt update
...
......
# gnutls-cliのパッケージをインストールする
[ec2-user@ip-xxx-xx-xx-250 ~]$ sudo apt install gnutls-cli
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package gnutls-cli # WSL (Ubuntu-24.04)ではインストールできない

下記、gnutls-cliをインストールできている人向けです。

(gnutls-cliじたいインストールできないことに加え、WinSCPを使用するつもりなので、WindowsでGnuTLSはめんどうなこともあり、実際には確認できていません。すみません。)

.bash

# 暗号化スイートの優先順位を設定する（例）
sudo gnutls-cli --priority PERFORMANCE:-VERS-TLS-ALL:+VERS-TLS1.2:-DHE-DSS:+AES256

設定基準は以下です。gnutls-cliで設定できる暗号化スイートのキーワードについては、
こちらを参考にしました。

128 bitsの暗号化スイートのみに制限するため（初心者のため、設定をできるだけシンプルにするため）、PERFORMANCE キーワードを設定する。さらに :+AES256で末尾にAES256を回す。
DHEやDSSは使用しない (:-DHE-DSS)
TLSのプロトコルバージョンは、TLSv1.2のみを使用する (:-VERS-TLS-ALL:+VERS-TLS1.2)

なお、個人で利用するケースを想定しているので、安全性は最低限にしています。自身の環境に合わせて、使用する暗号化スイートの優先順位を設定してください。たとえば、:+AES256は本来必要ないと思います（今回は設定で沼にはまらないように簡単化のために使用しています）。