openldapで自己署名の証明書をつかうldapsなサーバに接続
JavaScriptの仕事をしていると言ったな、あれは嘘だまずCA証明書が正しいかを確認しておく。openssl s_connect で接続すると、最初にこの証明書周りの情報が正しくなっているかを判定してくれる。
- openssl s_client -connect (host):(port) -CAfile (pem形式)
これでまずVerify return codeがokとなっている必要がある。でないと、このCAfileが間違っていることが濃厚。
次、仮にここで0と出ても、もしhost名が違う場合は注意。Can't contact LDAP server と一言言ってldapsearchは終了する。可能性の一つは、その自己署名を行ったCAが自分側に登録されていない、言い方を変えるとTLS_CACERTの設定ミス。 /etc/openldap/ldap.conf に"TLS_CACERT (file)"の行を足してみる。ここでうまくいけば、いいね。ちなみに der 形式ではなくpem 形式。derからpemへは以下のような感じで変換しとく。
- openssl x509 -inform der -in cacert.cer -outform pem -out cacert.pem
もしそれでだめなら、ldapsearch で -d 3 などとやってデバッグレベルの高い情報を見る
TLS: hostname (X.X.X.X) does not match common name in certificate (hogehoge.tune.local).仮に上記のようなエラーが出たとする。この場合、多分使っているCA証明書に入っているCN( hogehoge.tune.local) と、実際にこちらがアクセスしているホスト名が違う。例えばldaps://IPアドレスとか。
この場合、IPアドレスでアクセスすると、SSLのレイヤで正しくてもopenldapのレイヤで怒られてしまう。
workaround として、/etc/hosts にそのホストを書いてしまうというものがある:
https://answers.atlassian.com/questions/52781/jira-5-0-self-signed-ssl-cert-hostname-mismatch
James, why not stick with the /etc/hosts fix? That would allow a specific host (your ladp server) to be resolved by that url, and be trusted securely.あるいは、上記のホスト名検知を別の方法で止める。どう止めるかは確認してない。
私の手元では一応上記の流れを踏まえた結果、ldapsearchからそんなカンジのldapsサーバに接続して結果を取れた。が、もちろん正しい方法は自己署名ではないサーバ証明書をldaps側に用意しておくことだ。