2017/10/13(金)はんかくさい日報を新システムへ移行しました。
2017/10/13 5:11
しかし、見栄えは以前よりシンプルになってしまいました。
移行が何故か上手く行かず、更にデータの一部を壊してしまったため、
移行そのものを全て手動操作でやる羽目になり、足掛け３日掛かってしまいました。
また、手動操作移行の故、記事番号・記事URLが変わってしまい、Google 等への反映は１カ月程度かかるものと思われます。
2017/10/07(土)メールサーバへの攻撃事情
2017/10/12 22:20
こういう障害は２０年運用していて初めてのことでして・・・
どうも直接の原因は、これです。ＩＰアドレスも晒します。 ↓
52.166. 系のＩＰアドレスの登録上の使用者は、皆が誰でも知っている企業です。
調べればすぐ判るので、ここでは敢えて言及しません。
なんと、概ね 10秒毎にＳＭＴＰ認証を失敗しては繰り返しています。
文字列 'UGFzc3dvcmQ6' は、'Password:' を Base64エンコードして得られる文字列です。
ＳＭＴＰ認証も現在は数種類あって、これはセキュリティレベルが低いとされている LOGIN 認証と言われる種別。
サーバ負荷をこのようにして意図的に高くし、サーバ障害やサーバダウンを引き起こそうとする愉快犯か、何等かの意図を持っている連中の仕業です。
10/5 の 21:00 頃に、現在一緒に仕事をしている同業者がこのログを見て、 Twitter で呟いたそうです。
『○○社のネットワークから、メールサーバへの攻撃を受けている』と。
そうしたら、52.166. 系からの攻撃は「ピタッ」と止まりました。
これには余りの素早さに笑ってしまいましたね。勿論、対応された方々には感謝申し上げます。確信犯的にやっていたのであれば、逆に許せないですが。
で、今の攻撃主体はどうやら ↓ の模様。これもＩＰアドレスを晒しておきます。
間隔は４分毎ですが、攻撃と言えるレベルです。
時折「セキュリティ対策業者がセキュリティホール探しのためにやっている」なんていう話をする奴がいますが、ならサーバ負荷を意図的に上げるような行為を何故やる？ という 疑問が必然的に湧きますね。
SMTP サーバ自体の接続拒否機能は、SMTP認証処理成功後に機能するようで、認証前にＩＰアドレスや接続元ドメインなどで強制切断するようにはなっていないようです。
これをするには、ファイアウォールを使わないと駄目ですね。
この手の設定は、微々たるものだとしても傘下ネットワーク全体のパフォーマンス低下を招くので、出来れば余計なことはしたくない。
SMTP サーバ単体で、接続そのもの自体を拒否できる機能が欲しいと考えるのは自分だけでしょうか。
ま、発信元で犯人の処分をしてくれるのが最も有益なわけですが・・・
2017/08/28(月)powerDNS 4.0.4 は FreeBSD10 以降でソースコード構築途上でコンパイルエラー
2017/10/12 22:17
コンパイルを始めたばかりのところで、
ext/json11/json11.cpp:153:24: error: invalid operands to binary expression
('nullptr_t' and 'nullptr_t')
return m_value < static_cast<const Value<tag, T> *>(other)->m_value;
~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ext/json11/json11.cpp:209:5: note: in instantiation of member function
'json11::Value<json11::Json::Type::NUL, nullptr_t>::less' requested here
JsonNull() : Value(nullptr) {}
^
のようなエラーを吐いて構築不能になります。どうやら clang/LLVM 4.0.0 環境が少なくとも全滅です。
FreeBSD 11 はまさにこの環境。
% /usr/bin/clang -v FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) Target: x86_64-unknown-freebsd11.1 Thread model: posix InstalledDir: /usr/bin日本語の情報が殆ど無いですね。
これは ext/json11/json11.cpp と ext/json11/json11.hpp の２つのファイルを修正することで解決します。
具体的な修正内容は下記リンクです：
json11 fixes from upstream via pdns #135それにしても日本人の感覚だと、この修正量と内容だとバージョンアップしてソースコード一式を再リリースするものですが、開発元であるオランダ人の感覚は違うようです。
https://github.com/PowerDNS/weakforced/pull/135/commits/9e4d9bd48663e849be13e2cb5fcf64f917aec608
2017/05/23(火)権威ＤＮＳ ― SOA レコードの記述方法
2017/10/12 22:15
SOA とは Start Of Authority を略したもので、
よく「権威の開始」を意味すると説明されます。
このあたりが、日本語での感覚と英語圏での感覚が合わなくてピンとこないのですが、要するにここでいう「権威の開始」というのは、「ゾーン情報を管理する権限を持っているこ とを明示する」ということになります。
ＳＯＡレコードは、BIND の設定ファイルに従うと、下記のような書式になります：
@ IN SOA ns.example.jp. postmaster.example.jp. (
17052301 ; Serial-No.
3600 ; Refresh
900 ; Retry
604800 ; Expire
1800 ; Minimum
)
以下、「マスターＤＮＳ」「スレーブＤＮＳ」「権威サーバ」等の用語は理解しているものとして記述していきます。これらの意味は１つ前の記事に全て記してあります。ひとつひとつのパラメータを理解しているようでよく解かっていないのではないかなと。
SOA レコードは実に７つのパラメータで成り立っています。
個々に示してみます：
MNAME [ns.example.jp.]
・マスターＤＮＳのホスト名。
・「完全修飾」という書式で通常、最後にもドットを付ける。
・CNAME レコードのホスト名は指定不可。ＩＰアドレス自体も指定不可。
RNAME [postmaster.example.jp.]
・連絡先の電子メールアドレス。
・「完全修飾」という書式で通常、最後にもドットを付ける。
・ＤＮＳの動作上使われることはないが、管理者同士の連絡先として使われることがある。
・記述の際、@ マークは . に置き換える。
SERIAL [17052301]
・ゾーンシリアル番号。符号なし 32bit長整数で保持される。
・ゾーン内容を更新したら、必ずこの番号を＋１以上更新する。
・０以上ならどのような値でも構わないのだが、更新日（作成日）を示す YYYYMMDDnn 或いは YYMMDDnn の形式が多い。
・4294967295 の状態で＋１すると 0 になるが、こういう場合の正常な動作は基本的に考慮されていないことに留意。
→ この場合は、スレーブＤＮＳを一旦停止し、該当ゾーンを含む保持データそのものを削除してから、スレーブＤＮＳを再起動するしかありません。 SERIAL を前回より小さい番号にした場合も同様の対処です。
○ 以下３つはスレーブＤＮＳの挙動を指定：
REFRESH [3600] 〔単位：秒〕
・当該ゾーン情報をリフレッシュする間隔。
・スレーブＤＮＳは、マスターＤＮＳからのゾーン転送処理を受け入れたあと、ここで指定した時間経過すると、マスターＤＮＳへゾーン情報更新問合わせを行い、シリアル番号 が更新されていたら適宜更新処理を行う挙動になる。
RETRY [900] 〔単位：秒〕
・リフレッシュがマスターＤＮＳや回線障害など原因で上手く行かなかった場合、リトライを試みる間隔。
・従って、REFRESH で指定する値よりも小さな値でないと意味がなく、通常は、REFRESH の整数分の１の値とする。（この例では４分の１）
EXPIRE [604800] 〔単位：秒〕
・ゾーン情報のリフレッシュができない状態が続いた場合、スレーブＤＮＳにて、ゾーン情報を最後にリフレッシュが成功してから保持を可能とする時間を示す。
・従って、REFRESH の整数倍で無いと意味がなく、２週間から４週間が適切とされている。（この例では７日＝１週間）
○最後の１つはキャッシュＤＮＳの挙動を指定：
MINIMAM [1800] 〔単位：秒〕
・このパラメータは Negative cache TTL とも呼ばれる。
・各レコードのデフォルトキャッシュ保持時間を指定する。
・値が小さいほど臨機応変に権威サーバにおける保持情報に追従できるが、ＤＮＳの負荷が上がるため、60 ～ 3600 の間で適宜指定されるのが実態である。
・また、レコードに存在しない情報の問い合わせを受けた場合、'NXDOMAIN' （情報なし）という回答をするが、キャッシュＤＮＳは「情報なし」もここで指定した時間だけ保持する挙動になる。
以上、参考にどうぞ。
ダイナミックＤＮＳを運用している場合、MINIMAM は 60 を指定するのが通例の設定のようです。ホストの増減が多い環境では MINIMAM は 600、比較的変化が少ない環境では 1800 や 3600 という設定が多いようです。
2017/05/15(月)権威ＤＮＳとキャッシュＤＮＳの分離をしました
2017/10/12 22:13
ＤＮＳをいじるので、工程途上で作業ミスがあると傘下のネットワーク運用への影響が大きいため、１年近くやりたくてもできない状態だったので、出来る時にやってしまおうとい うことで。。
権威ＤＮＳとかキャッシュＤＮＳとか判らない方々も多いので、基礎的な解説を交えていきます。
変更前は以下のような単純な構成でした：
これは、弊社管轄ドメインのネームサーバとして、レジストラに登録しているサーバになります。
レジストラに登録するサーバは、「権威サーバ」となる種別のＤＮＳでなければなりません。
では、「権威サーバ」と「キャッシュサーバ」の違いは何？ というところですが・・
「権威サーバ」とは、ドメイン各種情報の原本を持つサーバ、
「キャッシュサーバ」とは、探索したドメイン情報の写しを持つサーバ
を言います。
従来のＤＮＳは、「権威サーバ」と「キャッシュサーバ」が一緒で、ＤＮＳのサーバソフトウェアで有名な BIND が以前は「権威サーバ」「キャッシュサーバ」と区別する概念が 無く、最初から両方使えるようになっているので、このあたりが混乱を来す要因になっています。
さて、「権威サーバ」には更に２種類あって、
かつては本当の原本情報を持たせるサーバを「プライマリＤＮＳ」
原本情報の複製を保持するサーバを「セカンダリＤＮＳ」と言っていました。
最近では、
「プライマリＤＮＳ」は「マスターＤＮＳ」とか「マスター権威ＤＮＳ」、
「セカンダリＤＮＳ」は「スレーブＤＮＳ」とか「スレーブ権威ＤＮＳ」とかいう言い方が主流になってきているようです。
ちなみに、「キャッシュＤＮＳ」には「プライマリ」「セカンダリ」あるいは「マスター」「スレーブ」の区別も概念もありません。
さて、「マスターＤＮＳ」も「スレーブＤＮＳ」も「権威サーバ」の位置づけなので、レジストラに「ネームサーバ」として登録できます。
「マスターＤＮＳ」か「スレーブＤＮＳ」かの種別は問いません。「権威サーバ」であることが重要です。
「マスターＤＮＳ」か「スレーブＤＮＳ」かの種別は問いません。「権威サーバ」であることが重要です。
弊社では、ＤＮＳ関係は下記のような構成にしました(2017/05/08より)：
最近はこのような構成がやや強めにお勧めされています。
使用するＤＮＳソフトウェアは何でも良いのですが、弊社での環境的事情や BIND の相次ぐセキュリティアラートに加え、常用の FreeBSD にて BIND が標準提供から外された(BIND 10 から Python ベースになったのが主たる理由）のに辟易して、PowerDNS,nsd,unbound という構成を採用した次第です。
「hidden マスターＤＮＳ」とは、その名の通り、マスターＤＮＳを公開ネットワーク上から隠しています。
こうすることで、ドメイン原本情報に「毒」が外部から入ることを防ぐセキュリティ対策が出来ます。
レジストラへのドメイン登録はネームサーバが最低２つ要るため、２つのスレーブＤＮＳを稼働させます。このスレーブＤＮＳは自前ですが、費用面さえ許す環境ならば、他社サー ビスの利用でも良いでしょう。
同じくキャッシュＤＮＳも２つ用意します。これは最低でも１つあればいいです。
逆に３つ以上キャッシュＤＮＳを指定できるアプリケーションはあまり見かけませんね。
キャッシュＤＮＳは「ドメイン情報探索専用」のサーバです。
「権威ＤＮＳ」とは物理的に別のサーバとし、利用を許可するネットワークを限定することがコツです。
「権威ＤＮＳ」はＣＰＵ負荷はあまり重くならないので、Raspberry Pi 等の活用も可能です。
キャッシュＤＮＳで特殊なのは google の 8.8.8.8 とか 8.8.4.4 とかで、これはオープンＤＮＳとかオープンリゾルバとか呼ばれ、誰でも使用できる代物ですが、負荷分散の意味 で、キャッシュサーバを用意しない場合や、用意できない場合、出来る限り加入しているプロバイダで指定されているネームサーバを使うことをお勧めします。
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にするにあたり、注意すべき気づいた点をメモ書きしておきます。
１）OpenLDAP 2.4.44 のインストール
FreeBSD10 まで普通に使い回しが出来たのですが、
どうやら、BDB 形式でデータベースクラスタを構築している場合、
FreeBSD11 上で OpenLDAP自体を構築し、FreeBSD10 で使っていた BDB を使用しようとすると、slapd 自体が起動しなくなるようなのです。
これをしなければ大丈夫ぽいですが、問題の先送りをするだけです。
このため、
○ FreeBSD 11 移行前に slapcat コマンドで LDIF をエクスポート
○ FreeBSD 11 移行後に openLDAPを再構築したら、slapadd コマンドで LDIF インポート
という手順で解決しました。
２）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 を更新インストール継続しているとこうなると思います。
３）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(土)プライベートＣＡの構築[FreeBSD] (3)
2017/10/12 19:35
このシリーズのその２ → プライベートＣＡの構築[FreeBSD] (2)
自分メモですが、証明書の失効方法や、証明書には種類があるというお話です。
● 証明書の失効手続き
利用対象者が居なくなった場合とか、何らかの問題が起きた場合に発行した証明書を取り消したい（無効にしたい）場合があります。
そんな場合には、「証明書失効操作」を行います。
openssl ca -gencrl -revoke user.pem -out cert.crlcert.crl が失効リストで、実際には証明書のシリアルナンバーと対応する証明書の失効日が暗号化（？）されて記述されたものが書き込まれるようです。
この cert.crl を各サーバ（Apache、OpenVPN等)の設定で参照するようにします。
これとは別に、証明書発行リストが以下のようにＣＡ管理ディレクトリの index.txt に生成されます。
Ｖで始まる行は、現在有効な証明書、
Ｒで始まる行は、失効する証明書を示しています。
●証明書には種類がある。
多くの場合、ディジタル証明書といえば、サーバ証明書をさす場合が多いです。
Ｗｅｂサーバで 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 でインストールする場合は、既にパッチが当たった状態でインストールされるので問題ありません。
画像をクリックすると見やすい大きさで表示されると思います。
〔参考ＵＲＬ〕 https://github.com/dovecot/core/commit/ffd8dc932516bc55bf01d91355540daab365e5e9
余りお勧めしませんが、次のバージョン 2.2.26 が出るのを待つ手もあります。
2016/07/17(日)プライベートＣＡの構築[FreeBSD] (2)
2017/10/12 19:33
今度は、構築したプライベートＣＡを用いて、実際にサーバ証明書を発行するところまでメモしておきます。実際に発行する環境を整えるために、最初の一度だけ幾つか準備が必要です。
○ 準備その１－ /etc/ssl/openssl.cnf の変更
以下のセクションを修正します。
[ usr_cert ]
basicConstraints=CA:false(CA:true を CA:false に)
[ v3_ca ]
basicConstraints=CA:false(CA:true を CA:false に)
これやらないと、証明書は発行できるものの、発行した証明書は不正証明書扱いになってしまいます。
○ 準備その２ － CA の公開証明書を pem 形式から der形式へ変換
# cd /root/BasekernelCA # openssl x509 -in cacet.pem -inform PEM -out cacert.der -outform DERここで作成した der 形式の証明書ファイルを Ｗｅｂサイト公開ディレクトリ等に設置し、Ｗｅｂページからダウンロード出来るようにしておきます。
● いよいよサーバ証明書の発行
ここから先は、本物の認証局にサーバ証明書発行手続きをする際にもほぼ同じ手順が使用できます。但し、Unix系/Linux系のコマンドラインインタフェースが基本です。
○ 秘密鍵の生成
# openssl genrsa -out private.key 2048この後生成する公開鍵とペアで使用されます。
ここでは 2048bit(256バイト) 長の秘密鍵を生成します。
一般的に「鍵長」とはこの秘密鍵の鍵長で、現在では 2048 bit 以上でないと、サーバ証明書発行を受け付けません。
また、-des3 や -aes128 などのパラメータを付加すると、パスフレーズ（パスワードと同じようなものだが、似て非なるもの）を付けることが出来ますが、サーバ用途においては却ってパスフレーズが邪魔になる（自動起動が できなくなる）ため、特に理由が無い限りは付けないほうがよいです。
○ ＣＳＲ（署名申請書/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 で規定され、日本を示す２レターコード 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 の中身（テキストファイルです）をコピー＆ペーストする仕組みになっていると思います。
○ ＣＡ局による証明書（公開鍵）の発行
# openssl ca -out server.pem -infiles server.csrこの操作により、
Enter pass phrase for /root/BaseKernelCA/private/cakey.pem:と、プライベートＣＡを生成するときに設定したパスワードを入力後、
下記のように確認が促され、
Sign the certificate? [y/n] の問いに y で署名処理、
1 out 1 certificate requests certified, commit?[y/n] の問いに y で登録処理
がなされ、証明書ファイル server.pem が作成されます。
このファイルの中身（暗号化されたテキストファイル）が証明書本体です。