Ubuntu 22.04 389 Directory Server #2 – TLS 有効化と LDAPS 設定

389 Directory Server で LDAP を認証・ディレクトリ基盤として使う場合、平文 LDAP のまま運用せず、LDAPS または StartTLS を前提にします。Ubuntu 22.04 の既存環境では、389 DS 側で TLS を有効化するだけでなく、クライアントが CA 証明書を信頼して接続できるところまで確認します。

この記事は、Ubuntu 22.04 の既存環境で 389 Directory Server の TLS / LDAPS 設定を読み直すための記事です。新規構築では Ubuntu 26.04 側の記事を優先しつつ、22.04 環境の設定確認や古い構築記録の読み替えに使ってください。

TLS / LDAPS の考え方

LDAP は平文のままでも動作しますが、認証や属性情報を扱う場合は通信路を保護します。LDAPS は最初から TLS で接続し、StartTLS は通常の LDAP 接続を TLS に昇格します。

内部 CA や自己署名証明書を使う場合は、証明書の期限、SAN、サーバー名、クライアントへの CA 配布を合わせて管理します。

pin.txt を作成する

389 DS の証明書 DB を扱うため、PIN ファイルを用意します。ここではインスタンス名を ldap01 とします。

sudo tee /etc/dirsrv/slapd-ldap01/pin.txt <<'EOF'
Internal (Software) Token:change-me
EOF
sudo chown dirsrv:dirsrv /etc/dirsrv/slapd-ldap01/pin.txt
sudo chmod 0400 /etc/dirsrv/slapd-ldap01/pin.txt

change-me は実際の証明書 DB の PIN に合わせます。ファイル権限は広げず、dirsrv が読める状態にします。

CA 証明書を登録する

389 DS の証明書 DB に、サーバー証明書を発行した CA 証明書を登録します。

sudo dsctl ldap01 tls import-ca /etc/pki/ca/example-ca.crt --name Example-CA

CA 証明書は、389 DS 側だけでなく、LDAP クライアント側にも信頼させる必要があります。

サーバー証明書を登録する

PKCS#12 形式のサーバー証明書を 389 DS に登録します。証明書の SAN には、クライアントが接続に使う FQDN を含めます。

sudo dsctl ldap01 tls import-server-key-cert /etc/pki/ldap/ldap01.p12

登録後、証明書名や有効期限、発行元を確認しておくと、後から LDAPS 接続の失敗を切り分けやすくなります。

TLS を有効化する

389 DS 側で TLS を有効化し、最小 TLS バージョンを設定します。

sudo dsconf ldap01 security set --security on
sudo dsconf ldap01 security set --ssl-version-min TLS1.2
sudo dsctl ldap01 restart

再起動後、389 DS が LDAPS で待ち受けていることを確認します。

systemctl status dirsrv@ldap01 --no-pager
ss -ltnp | grep ':636'

LDAPS 接続を確認する

クライアントから LDAPS で検索できることを確認します。ここでは suffix を dc=example,dc=local とします。

ldapsearch -x -H ldaps://ldap.example.local -b dc=example,dc=local dn
openssl s_client -connect ldap.example.local:636 -servername ldap.example.local -showcerts < /dev/null

ldapsearch が証明書検証で失敗する場合は、クライアント側が CA 証明書を信頼しているか、接続先ホスト名と証明書の SAN が一致しているかを確認します。

クライアント側の CA 信頼を確認する

内部 CA を使う場合は、LDAP クライアント側にも CA 証明書を配布します。Ubuntu では OS の信頼ストアへ追加してから反映します。

sudo cp example-ca.crt /usr/local/share/ca-certificates/example-ca.crt
sudo update-ca-certificates
grep -v -e '^\s*#' -e '^\s*$' /etc/ldap/ldap.conf

切り分け目的で証明書検証を無効化する例を見かけますが、常用は避けます。LDAPS を使う目的は、暗号化だけでなく、接続先の正当性を検証することにもあります。

まとめ

389 Directory Server は内部サービスから参照される基盤なので、TLS を後回しにしない方が安全です。389 DS 側で TLS を有効化し、CA 証明書、サーバー証明書、クライアント側の CA 信頼、接続先ホスト名まで合わせて確認します。

22.04 の既存環境を見直すときは、LDAPS の待ち受け、証明書の SAN、CA の配布、ldapsearch の証明書検証込みの接続を分けて確認します。次の段階でベースエントリーを登録し、BIND ユーザーやアクセス制御へ進みます。

関連記事

Ubuntu 22.04 389 Directory Server #1 – インスタンス作成と suffix 設計 Ubuntu 22.04 389 Directory Server #3 – ベースエントリーの登録 Ubuntu 22.04 389 Directory Server #4 – BIND ユーザーとアクセス制御 Ubuntu 26.04 LDAP サーバーの基本設定 – 389 Directory Server でディレクトリ基盤を作る Ubuntu 22.04 389 Directory Server #5 – グループとユーザーの登録 Ubuntu 22.04 Apache TLS – 内部 CA 証明書で HTTPS を有効化する Ubuntu 22.04 Apache HTTP/2 有効化 – TLS VirtualHost で h2 を使う Ubuntu 26.04 SSSD LDAP 連携 – LDAP ユーザー認証と TLS を設定する