【OpenLDAP基本講座 第6回】セキュリティ強化。TLS/SSL化と証明書管理による「盗聴」の完全防止

パスワードが「丸見え」の状態で運用していませんか？

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、ACL（アクセス制御リスト）を使って、「誰がどのデータを見れるか」という認可の制御を行いました。
これでデータベース内部の守りは固まりました。

しかし、どんなに完璧なACLを設定しても、防げない脅威があります。
それは「通信経路の盗聴」です。
LDAP (Port 389) は、歴史的な経緯からデフォルトでは平文（クリアテキスト）で通信を行います。
もし、悪意のあるユーザーが同じネットワーク内で tcpdump や Wireshark を使っていたら、ユーザーがログイン時に入力したパスワードは、そのままの文字で抜き取られてしまいます。

本記事では、OpenLDAPにおける暗号化方式の違い（StartTLS vs LDAPS）、OpenSSLによる証明書の作成手順、cn=config への適用方法、そして「証明書エラーで繋がらない」時のトラブルシューティングまでを徹底解説します。

---

第1章：StartTLSとLDAPS。2つの暗号化方式の違い

作業を始める前に、LDAPにおける2種類の暗号化アプローチを理解しておきましょう。
現場ではこれらが混同されやすく、トラブルの元になります。

1. LDAPS (LDAP over SSL)

• ポート: TCP 636
• 仕組み: 接続確立時（ハンドシェイク）から即座にSSL/TLSで暗号化します。WebのHTTPS (443) と同じ方式です。
• メリット: シンプルで分かりやすい。レガシーなクライアントやアプリケーションでも対応していることが多い。
• デメリット: 専用のポート (636) をファイアウォールで開ける必要がある。現在は公式には「非推奨（Deprecated）」扱いですが、実質的な標準として広く使われています。

2. StartTLS

• ポート: TCP 389 (標準ポートと同じ)
• 仕組み: 最初は平文で接続し、途中でクライアントが「これから暗号化しましょう」というコマンド（StartTLS拡張操作）を送って、通信を暗号化に切り替えます（昇格）。
• メリット: 標準ポートだけで完結する。
• デメリット: クライアント側がStartTLSに対応している必要がある。設定ミスにより「平文のまま通信し続ける」リスクがある。

---

第2章：証明書の準備。OpenSSLによる自己署名証明書の作成

暗号化通信を行うには、「サーバー証明書」と「秘密鍵」が必要です。
本番環境（インターネット公開）では Let’s Encrypt などの公的CAを使うべきですが、社内LAN（イントラネット）内のLDAPサーバーでは、運用の容易さから「自己署名証明書（オレオレ証明書）」や、社内プライベートCAの発行する証明書を使うことが一般的です。

ここでは、OpenSSLを使って自己署名証明書を作成する手順を紹介します。

1. ディレクトリの準備

証明書を格納するディレクトリを作成します。

mkdir -p /etc/pki/tls/private
mkdir -p /etc/pki/tls/certs

2. 秘密鍵の作成

パスワードなしのRSA秘密鍵 (2048bit) を作成します。

openssl genrsa -out /etc/pki/tls/private/ldap-server.key 2048

3. 証明書署名要求 (CSR) の作成

証明書の発行依頼書を作ります。
ここで最も重要なのは Common Name (CN) です。ここにはLDAPサーバーの FQDN (完全修飾ドメイン名) を正確に入力してください。
ここがズレていると、クライアント接続時にエラーになります。

openssl req -new -key /etc/pki/tls/private/ldap-server.key \
  -out /etc/pki/tls/certs/ldap-server.csr \
  -subj "/C=JP/ST=Tokyo/L=Chiyoda/O=LinuxKoubou/CN=ldap01.linuxkoubou.com"

4. 証明書の発行（自己署名）

CSRに自分の秘密鍵で署名し、有効期限10年（3650日）の証明書を作成します。

openssl x509 -req -days 3650 \
  -in /etc/pki/tls/certs/ldap-server.csr \
  -signkey /etc/pki/tls/private/ldap-server.key \
  -out /etc/pki/tls/certs/ldap-server.crt

5. 権限の設定（最重要！）

初心者が必ずハマるのがここです。
OpenLDAPの実行ユーザー（通常は ldap）が、秘密鍵ファイルを読み取れずに起動に失敗するケースです。

chown ldap:ldap /etc/pki/tls/private/ldap-server.key
chown ldap:ldap /etc/pki/tls/certs/ldap-server.crt
chmod 600 /etc/pki/tls/private/ldap-server.key

これで証明書の準備は完了です。

---

第3章：サーバー側の設定。cn=configへの証明書登録

作成した証明書と秘密鍵の場所を、OpenLDAP (slapd) に教えます。
これもおなじみ、LDIFファイルと ldapmodify コマンドで行います。

1. 設定変更用LDIFの作成

tls_config.ldif を作成します。
cn=config エントリ（グローバル設定）を修正します。

dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/pki/tls/certs/ldap-server.crt
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/pki/tls/private/ldap-server.key

CA証明書について：
自己署名証明書の場合、サーバー証明書自体がCA証明書を兼ねるため、olcTLSCACertificateFile の設定は必須ではありませんが、クライアント配布用に明示的に設定することもあります。

2. 設定の適用

ldapmodify -Y EXTERNAL -H ldapi:/// -f tls_config.ldif

エラーが出なければ、設定は即座に反映されます。

3. 設定の確認

ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config" "(objectClass=olcGlobal)" olcTLS*

設定したパスが正しく表示されているか確認してください。

---

第4章：ポート636 (LDAPS) の有効化

証明書を設定しただけでは、まだLDAPS (636) はリッスンしていません。
起動オプションを変更する必要があります。

RHEL / AlmaLinux / Rocky Linux の場合

設定ファイル /etc/sysconfig/slapd (Symas版の場合は /etc/default/symas-openldap 等の場合あり) を編集します。

# SLAPD_URLS="ldapi:/// ldap:///"
# ↓ 以下のように変更
SLAPD_URLS="ldapi:/// ldap:/// ldaps:///"

ldaps:/// を追加することで、SSLポート (636) でのリッスンが有効になります。

サービスの再起動と確認

systemctl restart slapd

ポートが開いているか確認します。

ss -ltn | grep 636

LISTEN と表示されれば、LDAPSサーバーの立ち上げ成功です！

Firewallの設定

外部から接続できるようにポートを開放します。

firewall-cmd --add-service=ldaps --permanent
firewall-cmd --reload

---

第5章：クライアント側の設定。ldap.confと接続テスト

サーバー側の準備ができたら、クライアント側（ldapsearch コマンドなど）の設定です。
SSL/TLS通信では、クライアントが「このサーバーは信頼できるか？」を検証します。
自己署名証明書の場合、クライアントに「この証明書は信頼していいよ」と教える必要があります。

1. 証明書の配布

サーバーで作った ldap-server.crt を、クライアントマシンの /etc/pki/tls/certs/ などにコピーします。

2. ldap.conf の編集

OpenLDAPクライアントの設定ファイル /etc/openldap/ldap.conf を編集します。

# サーバーのURI（LDAPSを指定）
URI ldaps://ldap01.linuxkoubou.com

# 信頼するCA証明書（自己署名の場合はサーバー証明書そのもの）
TLS_CACERT /etc/pki/tls/certs/ldap-server.crt

# 証明書検証のレベル
TLS_REQCERT demand

TLS_REQCERT の設定値

• demand (hard): 検証に失敗したら接続しない。最もセキュア（推奨）。
• allow (soft): 検証に失敗しても接続する。セキュリティの意味がない（非推奨）。
• never: 検証しない。

最初は allow でテストし、最終的に demand にするのが移行のコツです。

3. 接続テスト

ldapsearch -x -b "dc=linuxkoubou,dc=com" "(uid=taro)"

-H オプションを指定しなくても、ldap.conf の URI 設定が効いていればLDAPSで接続されます。
デバッグモード -d 1 を付けると、TLSハンドシェイクの様子が詳細に表示されます。

---

第6章：セキュリティ強度の向上。暗号化スイートの設定

「とりあえず暗号化した」だけでは不十分です。
古いSSLプロトコル（SSLv3, TLS 1.0, TLS 1.1）は脆弱性があるため、無効化すべきです。

TLSプロトコルバージョンの制限

TLS 1.2 以上のみを許可する設定を入れます。

# tls_harden.ldif
dn: cn=config
changetype: modify
replace: olcTLSProtocolMin
olcTLSProtocolMin: 3.3

3.3 は TLS 1.2 を意味します（3.1=TLS1.0, 3.2=TLS1.1）。

StartTLSの強制（平文接続の拒否）

ポート389 (平文) への接続に対しても、StartTLSによる暗号化を強制します。
これを設定すると、平文のまま認証（Bind）しようとしたクライアントは拒否されます。

# security.ldif
dn: cn=config
changetype: modify
add: olcSecurity
olcSecurity: tls=1

これを適用すれば、うっかり平文でパスワードを送ってしまう事故をサーバー側で防ぐことができます。

---

第7章：トラブルシューティング。繋がらない時のチェックリスト

SSL/TLS化はハマりポイントが多いです。
うまくいかない時は、以下のチェックリストを確認してください。

Check 1: ホスト名は合っていますか？

証明書の CN (Common Name) と、接続時に指定しているホスト名が一致していないとエラーになります。
証明書のCNが ldap01.linuxkoubou.com なのに、ldaps://192.168.1.10 で接続しようとすると失敗します。
/etc/hosts やDNSを確認しましょう。

Check 2: 証明書の期限は切れていませんか？

以下のコマンドで証明書の期限を確認できます。

openssl x509 -in /etc/pki/tls/certs/ldap-server.crt -noout -dates

Check 3: 中間CA証明書は必要ですか？

Let’s Encryptなどの公的証明書を使う場合、中間CA証明書（chain.pem）の設定が必要です。
OpenLDAPの設定では、olcTLSCACertificateFile に中間CA証明書（またはルート+中間の結合ファイル）を指定することが多いです。

Check 4: クライアント側のデバッグ

openssl s_client コマンドを使うと、LDAPクライアントを使わずにSSL接続の診断ができます。

openssl s_client -connect ldap01.linuxkoubou.com:636 -showcerts

ここで Verify return code: 0 (ok) が出れば、SSL層は正常です。
エラーが出る場合は証明書チェーンや信頼設定に問題があります。

---

まとめ：セキュリティは「設定」ではなく「運用」

お疲れ様でした！
第6回は、OpenLDAPのTLS/SSL化について、証明書の作成から設定、トラブルシュートまでを解説しました。

今回の重要ポイント：

• LDAPは平文通信がデフォルト。LDAPS (636) の利用を強く推奨。
• 証明書のパーミッション（ldapユーザーが読めること）は最大のハマりポイント。
• /etc/sysconfig/slapd で ldaps:/// を有効化するのを忘れない。
• クライアント側は TLS_REQCERT demand で厳格に検証する。

さて、これで単一サーバーとしての機能は完成形に近づきました。
しかし、このサーバーがハードウェア障害で停止したらどうなりますか？
認証基盤の停止は、業務の完全停止を意味します。

次回、第7回は「レプリケーション。Syncreplによる冗長化構成」です。
OpenLDAP標準の同期機能 Syncrepl を使って、マスター・スレーブ構成を構築し、可用性を高める手順を解説します。お楽しみに！