2016/12/31(土)FreeBSD11 で OpenLDAP・Courier-Authlib・postfix3.1.x インストール時の注意
2017/10/12 19:46
年明けから、FreeBSD11 を使用したARM系ボードの試作の仕事が入りそうなこともあり、弊社管轄の幾つかのサーバを FreeBSD 11.0 にしてみました。
FreeBSD 9系 のサポートは本日で終了です。
FreeBSD10.3 は、少なくとも 2018年4月末までのサポート、
FreeBSD11系 は、少なくとも 2021年9月末までのサポートになっています。
FreeBSD10系 は微妙ですが、FreeBSD11系は、サポート期間が延びる可能性ありです。
FreeBSD 11 にすると、コンソール(画面表示)ドライバが変更されており、こんな表示になります。↓
フォントさえ設定できれば、日本語表示できるのですが、11.0 の時点ではまだデフォルトでは出来ないようです。
また、スクリーンセーバーは機能しません。今後の課題でしょうか。。
本題ですが、FreeBSD11にするにあたり、注意すべき気づいた点をメモ書きしておきます。
1)OpenLDAP 2.4.44 のインストール
FreeBSD10 まで普通に使い回しが出来たのですが、
どうやら、BDB 形式でデータベースクラスタを構築している場合、
FreeBSD11 上で OpenLDAP自体を構築し、FreeBSD10 で使っていた BDB を使用しようとすると、slapd 自体が起動しなくなるようなのです。
これをしなければ大丈夫ぽいですが、問題の先送りをするだけです。
このため、
○ FreeBSD 11 移行前に slapcat コマンドで LDIF をエクスポート
○ FreeBSD 11 移行後に openLDAPを再構築したら、slapadd コマンドで LDIF インポート
という手順で解決しました。
2)Courier-Authlib のインストール
ソースコードからインストール作業する場合、以下のメッセージが出て configure に失敗することがあります。
Shared object "libssl.so.7" not found, required by "courierauthconfig"これは、 /usr/local/bin/courierauthconfig 、/usr/local/courier/bin/courierauthconfig をバッサリと削除し、 configure をやり直せば大丈夫です。
過去に Courier IMAP 等を使用したことがあって、FreeBSD を更新インストール継続しているとこうなると思います。
3)postfix 3.1.x のインストール
現時点での最新バージョンは 3.1.3 ですが、これは FreeBSD11 には対応しておらず、ソースコードからの構築はそのままではできません。
ですが、機能的には問題ないと思われますので、以下の修正を行ってから構築を行います。
・ makedef 260行目付近 ~ (行頭が + の行を挿入)
FreeBSD.10*) SYSTYPE=FREEBSD10 : ${CC=cc} : ${SHLIB_SUFFIX=.so} : ${SHLIB_CFLAGS=-fPIC} : ${SHLIB_LD="${CC} -shared"' -Wl,-soname,${LIB}'} : ${SHLIB_RPATH='-Wl,-rpath,${SHLIB_DIR}'} : ${SHLIB_ENV="LD_LIBRARY_PATH=`pwd`/lib"} : ${PLUGIN_LD="${CC} -shared"} ;; + FreeBSD.11*) SYSTYPE=FREEBSD11 + : ${CC=cc} + : ${SHLIB_SUFFIX=.so} + : ${SHLIB_CFLAGS=-fPIC} + : ${SHLIB_LD="${CC} -shared"' -Wl,-soname,${LIB}'} + : ${SHLIB_RPATH='-Wl,-rpath,${SHLIB_DIR}'} + : ${SHLIB_ENV="LD_LIBRARY_PATH=`pwd`/lib"} + : ${PLUGIN_LD="${CC} -shared"} + ;; DragonFly.*) SYSTYPE=DRAGONFLY ;; OpenBSD.2*) SYSTYPE=OPENBSD2・ src/util/sys_defs.h 25行目付近~ (行頭が + の行を挿入)
#if defined(FREEBSD2) || defined(FREEBSD3) || defined(FREEBSD4) \ || defined(FREEBSD5) || defined(FREEBSD6) || defined(FREEBSD7) \ || defined(FREEBSD8) || defined(FREEBSD9) || defined(FREEBSD10) \ + || defined(FREEBSD11) \ || defined(BSDI2) || defined(BSDI3) || defined(BSDI4) \ || defined(OPENBSD2) || defined(OPENBSD3) || defined(OPENBSD4) \
2016/12/10(土)perl 5.24 にしたら ports の XPDFJ は動作しない
2017/10/12 19:44
サーバのエラーログに
Can't use 'defined(%hash)' (Maybe you should just omit the defined()?) at /usr/local/lib/perl5/site_perl/XPDFJ.pm line 757.と文句を垂れますので、XPDFJ.pm の 757行目を以下の要領で直接修正します。
《変更前》
if( defined %{$tab->{$name}} && $name !~ /::$/ ) {《変更後》
if ((%{$tab->{$name}}) && ($name !~ /::$/ )) {こうすると、perl 5.24 でも動作するようです。
筆者がメンテナンスを請け負っている企業のサーバでは動作確認できました。
原因は、perl 5.24 にて defined(%hash) の構文を致命的エラーとするように変更されたためです。何故こうするのかはよく判りませんが。。。
2016/08/06(土)プライベートCAの構築[FreeBSD] (3)
2017/10/12 19:35
このシリーズのその2 → プライベートCAの構築[FreeBSD] (2)
自分メモですが、証明書の失効方法や、証明書には種類があるというお話です。
● 証明書の失効手続き
利用対象者が居なくなった場合とか、何らかの問題が起きた場合に発行した証明書を取り消したい(無効にしたい)場合があります。
そんな場合には、「証明書失効操作」を行います。
openssl ca -gencrl -revoke user.pem -out cert.crlcert.crl が失効リストで、実際には証明書のシリアルナンバーと対応する証明書の失効日が暗号化(?)されて記述されたものが書き込まれるようです。
この cert.crl を各サーバ(Apache、OpenVPN等)の設定で参照するようにします。
これとは別に、証明書発行リストが以下のようにCA管理ディレクトリの index.txt に生成されます。
Vで始まる行は、現在有効な証明書、
Rで始まる行は、失効する証明書を示しています。
●証明書には種類がある。
多くの場合、ディジタル証明書といえば、サーバ証明書をさす場合が多いです。
Webサーバで https を行う場合や、電子メールサーバにて TLS 通信を行う場合は、必ず必要になるのでお馴染みの方も多いでしょう。
OpenVPN のクライアント側には、接続先のサーバ証明書(公開鍵のみ)のほかに、クライアント証明書というのが必要になります。
これを OpenSSL コマンドラインで発行するには、 FreeBSD では /etc/ssl/openssl.cnf の設定を一部変更する必要があります。
具体的には、[ usr_cert ] ブロックの nsCertType パラメータを
nsCertType = client, email, objsignとする必要があります。
こうしないと、少なくとも OpenVPN は KU ERROR が発生したり、接続途上でダンマリを決め込んでしまい、クライアント側から上手く接続できません。
ですが、サーバ証明書の場合は、これでは逆に駄目で、
nsCertType = serverとする必要があります。
2016/07/27(水)FreeBSD 10.3R 環境で dovecot 2.2.25 はそのままでは動作しない
2017/10/12 19:34
弊社でも採用していますが、どうやら FreeBSD固有のバグがあるようです。
具体的には、
Last died with error (see error log for more information): kevent(EV_ADD, READ, 56) failed: Bad file descriptor(実際は改行しません)
といったメッセージが起動時に発生し、サービスを全く提供出来なくなるという重篤な問題。
これは、日本語の情報がほぼ皆無ですが、以下のパッチで凌げます。(弊社でも確認済。)
#Ports でインストールする場合は、既にパッチが当たった状態でインストールされるので問題ありません。
画像をクリックすると見やすい大きさで表示されると思います。
〔参考URL〕 https://github.com/dovecot/core/commit/ffd8dc932516bc55bf01d91355540daab365e5e9
余りお勧めしませんが、次のバージョン 2.2.26 が出るのを待つ手もあります。
2016/07/17(日)プライベートCAの構築[FreeBSD] (2)
2017/10/12 19:33
今度は、構築したプライベートCAを用いて、実際にサーバ証明書を発行するところまでメモしておきます。実際に発行する環境を整えるために、最初の一度だけ幾つか準備が必要です。
○ 準備その1- /etc/ssl/openssl.cnf の変更
以下のセクションを修正します。
[ usr_cert ]
basicConstraints=CA:false(CA:true を CA:false に)
[ v3_ca ]
basicConstraints=CA:false(CA:true を CA:false に)
これやらないと、証明書は発行できるものの、発行した証明書は不正証明書扱いになってしまいます。
○ 準備その2 - CA の公開証明書を pem 形式から der形式へ変換
# cd /root/BasekernelCA # openssl x509 -in cacet.pem -inform PEM -out cacert.der -outform DERここで作成した der 形式の証明書ファイルを Webサイト公開ディレクトリ等に設置し、Webページからダウンロード出来るようにしておきます。
● いよいよサーバ証明書の発行
ここから先は、本物の認証局にサーバ証明書発行手続きをする際にもほぼ同じ手順が使用できます。但し、Unix系/Linux系のコマンドラインインタフェースが基本です。
○ 秘密鍵の生成
# openssl genrsa -out private.key 2048この後生成する公開鍵とペアで使用されます。
ここでは 2048bit(256バイト) 長の秘密鍵を生成します。
一般的に「鍵長」とはこの秘密鍵の鍵長で、現在では 2048 bit 以上でないと、サーバ証明書発行を受け付けません。
また、-des3 や -aes128 などのパラメータを付加すると、パスフレーズ(パスワードと同じようなものだが、似て非なるもの)を付けることが出来ますが、サーバ用途においては却ってパスフレーズが邪魔になる(自動起動が できなくなる)ため、特に理由が無い限りは付けないほうがよいです。
○ CSR(署名申請書/Certificate Signing Request)の生成
# openssl req -new -sha512 -key private.key -out server.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:JP State or Province Name (full name) [Some-State]:Hokkaido Locality Name (eg, city) []:Sapporo Organization Name (eg, company) [Internet Widgits Pty Ltd]:Base Kernel Co,.Ltd. Organizational Unit Name (eg, section) []:labo Common Name (e.g. server FQDN or YOUR name) []:clione.basekernel.ne.jp Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:この手順で、当該の例では暗号化された CSR が server.csr ファイルに作成されます。
ここで・・・
Country Name - ここは日本なので、ISO3166 で規定され、日本を示す2レターコード JP を指定します。
State or Province Name - 日本では都道府県に該当し、米国では州、中共では省です。筆者の組織は北海道にありますので、そのまま Hokkaido とします。
Locality Name - 市区町村名。筆者の組織は札幌市にありますので、そのまま Sapporo とします。 Sapporo-shi や Sapporo City でも大丈夫なようですが、個人的には好みではありません。
Organization Name - 組織名。英語表記の正式名称を記述します。
本物の認証局に対し CSR を発行する際は、ドメイン登録情報と比較したときに、ここを一字一句間違えただけでも発行を拒絶されることがあります。
Organizational Unit Name - 組織内部署名。省略可能ですが、同一組織が複数のサーバ証明書を必要とする場合、ここに何等かの情報を記述し、区別する必要があります。
Common Name - サーバの場合は、サーバのFQDN 名、電子メール認証の場合は、証明対象の電子メールアドレスを記述します。
Email Address 以降は通常、省略します。
本物の認証局に証明書発行依頼をする際は、殆どの場合、この server.csr の中身(テキストファイルです)をコピー&ペーストする仕組みになっていると思います。
○ CA局による証明書(公開鍵)の発行
# openssl ca -out server.pem -infiles server.csrこの操作により、
Enter pass phrase for /root/BaseKernelCA/private/cakey.pem:と、プライベートCAを生成するときに設定したパスワードを入力後、
下記のように確認が促され、
Sign the certificate? [y/n] の問いに y で署名処理、
1 out 1 certificate requests certified, commit?[y/n] の問いに y で登録処理
がなされ、証明書ファイル server.pem が作成されます。
このファイルの中身(暗号化されたテキストファイル)が証明書本体です。
2016/07/15(金)プライベートCAの構築[FreeBSD] (1)
2017/10/12 19:30
7年半前に構築したきりですので、構築手順を忘れています・・・orz
ということで、2回の記事に分けて投稿します。いつものメモです。
具体的には、弊社のVPN接続と電子メール送受信(TLS 又は SSL を使用している場合のみ)に影響があります。新しい証明書に入れ替えて頂く必要があります。
きちんとした正式認証局のものを使うべきだろう、、という声も聞こえてきそうですが、弊社暗号化通信サービスに閉じた用途ですし、逆に汎用的に使われては困るので、弊社プライベートCAでの運用としています。
● 先ずは、スクリプトの修正
Google先生の検索では、Linux ベースの CentOS の事例ばかりで、FreeBSD の事例はほぼ皆無。
ですが、ファイルの置き場所以外に大差ありません。
FreeBSD の場合は、 /usr/src/crypto/openssl/apps/CA.sh を編集します:
(63行目付近)
if [ -z "$DAYS" ] ; then DAYS="-days 395" ; fi # 13 month CADAYS="-days 14610" # 40 years REQ="$OPENSSL req $SSLEAY_CONFIG"(71行目付近)
if [ -z "$CATOP" ] ; then CATOP=/root/BaseKernelCA ; fiCADAYS はCAの有効日数。
CATOP はCAにて発行する証明書の管理トップディレクトリです。
共に適宜の値を指定します。
変更したら、
# chmod +x /usr/src/crypto/openssl/apps/CA.shとして、スプリプトを実行可能状態にしておきます。
●次に /etc/ssl/openssl.cnf の修正
FreeBSD においては、opensslの設定ファイルは、/etc/ssl/openssl.cnf にあります。
このファイルは、セクション単位に設定項目がまとまっています。
セクション内の該当パラメータを以下のように修正します。
[ CA_default ] dir = /root/BaseKernelCA default_days = 7305 default_crl_days= 30 default_md = sha512 policy = policy_match [ policy_match ] countryName = match stateOrProvinceName = supplied organizationName = supplied organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] default_bits = 2048 default_md = sha512 [ req_distinguished_name ] countryName_default = JP stateOrProvinceName_default = Hokkaido 0.organizationName_default = Base Kernel Co., Ltd [ usr_cert ] basicConstraints=CA:true nsCertType = server [ v3_ca ] basicConstraints = CA:true nsCertType = sslCA, emailCAこの修正で、鍵長デフォルト 2,048bit、暗号化ハッシュ SHA-2(SHA512) に対応します。
修正したら、プライベートCAの構築です。(以下、一部テキスト伏字処理あり)
# /usr/src/crypto/openssl/apps/CA.sh -newca
CA certificate filename (or enter to create) Making CA certificate ... Generating a 2048 bit RSA private key ...............................................................+++ .......................................+++ writing new private key to '/root/BaseKernelCA/private/./cakey.pem' Enter PEM pass phrase: (CAパスフレーズ入力) Verifying - Enter PEM pass phrase: (もう一度同じCAパスフレーズ入力) ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [JP]: (JP でよいのでこのままリターン) State or Province Name (full name) [Hokkaido]:(Hokkaido でよいのでこのままリターン) Locality Name (eg, city) []:Sapporo Organization Name (eg, company) [Base Kernel Co., Ltd]: Organizational Unit Name (eg, section) []:Base Net Common Name (eg, YOUR name) []:Base Kernel CA Email Address []:hoge@example.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: (このままリターン) An optional company name []: (このままリターン) Using configuration from /etc/ssl/openssl.cnf Enter pass phrase for /root/BaseKernelCA/private/./cakey.pem: Check that the request matches the signature Signature ok (以下省略)実際には続いてこんな感じで詳細が出力されます:
この例では、/root/BasekernelCA/cacert.pem にCAの証明書が生成されます。
この証明書は、後でサーバ証明書を発行する際に、一緒にCA証明書として通知を行います。
また、この例では証明書の有効期間を 40年としていますが、こういうアホな証明書も発行できるということでご参考にどーぞ。
次の記事は、このプライベートCAを用いたサーバ証明書の発行方法です。
#以前は出来なかったんです。はい。確か、2036年くらいが限界でした。
2016/06/10(金)FreeBSD自身をコンパイルしてセルフ更新してみる
2017/10/12 19:27
FreeBSD 9.3R , Athron64x2 3800+ Dual Core , DDR2 1024MByte , ATA100 80GB HDD
中古購入のため M/B 型番不明
(その2)
FreeBSD 10.1R , Athron64 3000+ , DDR 2048MByte , ATA100 80GB HDD
Asus A8V
(その2)のほうは、時間かかりすぎのような気がするのだが、、、
OSのバージョンも違うし、(その2)のほうは、役割上LANを4系統接続している状態だし、ハードウェアスペックも低いから単純な比較は出来ないけれど。。
それを差し引いてもねぇ。。です。どんなものでしょうか。
2016/05/09(月)今更ながら dovecot-SASL による CRAM-MD5,DIGEST-MD5,SCRAM-SHA-1 SMTP認証のサポート
2017/10/12 19:25
実はこれらの動作検証をするには、メールサーバが欠かせません。
実際に顧客に提供しているサーバはサービス停止を引き起こす障害が起きると、その対応となりますので、非公開のメールサーバをいじることになります。
ところが、手元のメールサーバ(dovecot + OpenLDAP + postfix) の構成にて、どのようにサポートしているのか(特にパスワード自体の管理方法)の情報が断片的かつごく少数しかありません。
弊社では、SMTP認証を dovecot-SASL に担当させ、電子メールアカウントやパスワードを OpenLDAP にて管理しています。
試行錯誤したところ、OpenLDAP には今まで通り平文管理(実際の格納形式は Base64)で、全種類いけることが判明しました。
こうなると簡単です。
dovecot.conf に
のような設定を行い、postfix 側は CRAM-MD5 や DIGEST-MD5 のための特別な設定は要りません。(厳密には、postfix側にセキュリティ的設定オプションがあるが、LOGIN 認証と PLAIN 認証をサポートするのであれば、デフォルトでいけるはず)
dovecot.conf に上記の設定を行ったあと再起動し、他ホストから SMTP を喋ってみると、サポートできていることが下記のように確認できます。
これで作業を進めることが出来ました。
昨今では、通信経路そのものを暗号化しようかという方向で、SMTP認証の CRAM-MD5や DIGEST-MD5 といった暗号化ハッシュ認証対応はどちらかというと消極的なISPが多いのですが、簡単にできるのが判っててサポートしな いのは手抜きですので、近日中に全ての弊社メールサーバにて対応予定としたいと考えてます。
〔2016/05/16 追記〕上記は、2016/05/11 付でサポート開始しています。
SCRAM 認証は 2010年7月に RFC5802 として規定されましたが、現在どこまでサポートされているのかはよく知りません。
SHA-1 は MD5 と並んで広く使われている暗号化ハッシュ関数の名称ですが、脆弱性が指摘されていて、SSL サーバ証明書なんかがこの影響をもろに受け、SHA-2 へ移行しています。
2016/03/09(水)今般の FreeBSD 9.3 のセキュリティアップデートは見送ったほうが無難
2017/10/12 19:19
今のところ、
・SSH 接続ができない(接続がクラッシュする)
・SMTP接続にて TLS 接続やるとクラッシュする
・IMAP接続にて TLS 接続やるとクラッシュする
といった情報が上がっています。
公式サイトにも FreeBSD 9.3R-p37 のアナウンスは無いようです。
運用環境的にどうしても OpenSSL 周りのパッチが必要な場合は、ports/pakkages の OpenSSL で凌ぐしかないと思います。(こちらは大丈夫という報告があがっています)
個人的には、メンテナンス工数との絡みがあり、数日様子見したほうがいいかなと考えています。
〔2016/03/10 追記〕
本日、FreeBSD 9.3R-p38 が提供されたようです。
公式サイトにも掲載されています。