OpenSSL

Fedora Core 5 では /etc/pki/ に証明書関係のファイルは配置されるようです。ここでは、OpenSSLによるサーバ証明書の発行の手順をまとめてみました。

サーバ証明書署名要求と秘密鍵の作成

 コマンドを実行して,サーバ証明書署名要求(csr.pem)と秘密鍵(privkey.pem)を作成します。

# openssl req -new -out csr.pem

 作成にあたっては下記の項目について決めておく必要があります。いくつかは省略可能なのでそのままエンターキーを押下することにします。

  • pass phrase:changeit
  • Country Name (2 letter code) [GB]:JP
  • State or Province Name (full name) [Berkshire]:Tokyo
  • Locality Name (eg, city) [Newbury]:Ueno
  • Organization Name (eg, company) [My Company Ltd]:sssg
  • Organizational Unit Name (eg, section) [ ]:
  • Common Name (eg, your name or your server’s hostname) [ ]:192.168.0.1
  • Email Address [ ]:
  • A challenge password [ ]:
  • An optional company name [ ]:

 開発で利用する場合には、秘密鍵(privkey.pem)から,パスフレーズを削除した秘密鍵(server.key)が欲しいこともあるでしょう。その場合は次のようにします。どちらのファイルも秘密鍵のファイルとして使うことができます。

# openssl rsa -in privkey.pem \
-out /etc/pki/tls/private/server.key

自己認証局(プライベートCA)の構築

自己認証局(プライベートCA)を構築するには、次のようなコマンドを実行します。最初に作成するファイル名を指定するプロンプトがでますが、指定しないのならそのままエンターキーを押下します。デフォルトではカレントディレクトリにファイルはできあがります。「/etc/pki/CA」などへ作成してもいいでしょう。


# /etc/pki/tls/misc/CA -newca

 構築にあたっては下記の項目について決めておく必要があります。いくつかは省略可能なのでそのままエンターキーを押下することにします。CAの構築前にデフォルト設定値を変更したい場合は/etc/pki/tls/openssl.cnfを編集します。たとえば、有効期間を30日に指定するには「 default_days = 30 」のようにします。

  • pass phrase:changeit
  • Country Name (2 letter code) [GB]:JP
  • State or Province Name (full name) [Berkshire]:Tokyo
  • Locality Name (eg, city) [Newbury]:Ueno
  • Organization Name (eg, company) [My Company Ltd]:sssg
  • Organizational Unit Name (eg, section) [ ]:
  • Common Name (eg, your name or your server’s hostname) [ ]:192.168.0.1
  • Email Address [ ]:
  • A challenge password [ ]:
  • An optional company name [ ]:

サーバー証明書の作成

 自己認証局を構築するとサーバ証明書署名要求(csr.pem)から、サーバ証明書を作成することができます。ただし、ここでは自己認証局を使って署名をするため、自己署名証明書になります。

# openssl ca -out /etc/pki/tls/certs/server.crt \
-infiles csr.pem

 作成したサーバ証明書のフィンガープリントは次のコマンドで表示することができます。

# openssl x509 -fingerprint -noout \
-in /etc/pki/tls/certs/server.crt

Study

 会社における教育というものを考えてみたときに、できるだけコストを抑えるためにはどうするのがよいだろうか? 必要性が高い教育については教育費を会社がもってでも行なうべきなのだろうが、一般教養に近いものについては各自の努力で身につけてもらいたいということがあるだろう。ここで、一般教養とそれ以外はどこで線引きができるのか、という問題はあるのだが、たとえば社内システムの使用方法は明らかに会社独自の話なので一般教養ではない。しかし社内で使用するメーラについては、自社以外の会社でもメーラを使えることはひとつの技能として認められることなので一般教養と考えてもいいだろう。

 こういう視点で大雑把でもいいのでシステムを分類して、教育コストを含めた上でのシステム運用コストを計算してみるとおもしろそうである。データをとってみたわけではないが、社内で独自のシステムを動かすよりも、普及しているシステムを動かした方が有利ではないだろうか。ちょっと飛躍するがインターネットの普及により独自のLANで動作するグループウェアというのは、より汎用的なWebベースのものになったりインターネットメーラへ置き換わっているあたりをみても、一般教養としてWebブラウザやインターネットメーラの使い方を知っている人が多くなって、教育コストを抑えることができることが1つの要因ではないかと考えられる。

 ここで重要なのは、「いかにして普及しつつあるシステムを会社の教育コストを抑えつつ導入するか」である。たとえば、社員自身があるシステムを有効に使えると社内での自分の競争力が高くなる、ということを自覚できるような環境にした上で、普及しつつあるシステムを導入すれば会社の教育コストは抑えることができるはずである。そのコストは社員自身が払ってくれるはずなのだ。例として、英会話を考えてみてもわかりやすいのではないだろうか。英会話ができることに価値を見いだしている人は、自分でお金を払ってでも英会話教室へ通っている。社員自身が投資に見合う価値があると思うことに対しては、それにかかるコストを厭わないのだ。

 完全に普及しているシステムについては、意識しなくても使用するメリットは何かを解説するものは世の中に汎濫しているのでいいのだが、難しいのは「普及しつつあるシステム」とか「普及しているが社内での有効な利用方法がわからないシステム」である。Wiki, Blog, 掲示板, Instant Messenger, Skype, ITS/BTS など色々とあるわけだが、社員がそれらを使うメリットを認識できないと、せっかく用意したシステムも使われないまま放置されてしまうことになる。社員の責任だけではない。社内で使用するのに適していない方法で導入をすると使われないのも仕方がないということになるので、導入をリードする側でもそのメリットをわかりやすく説明をしたり、適切な分野で利用するように枠組みを決める必要があるだろう。

 これまでの個人的な経験からすると、共同作業をネットワーク上で行なうにあたって誰もが利用しているものというのは、電子メールだけである。掲示板は多数の参加者がいないとうまくいかない。Wikiは編集する人が偏ってしまって共同作業になりにくい。ITS/BTSは開発者はみんな使うが他の分野への適用はよくわからない。その他は、使うメリットはあるのだが、社内システムというレベルでの導入はまだなかなかできない、という感じである。

 こういったあたり、ちょっと研究をしてみたい気分だ。

カテゴリー: etc

Blog

サーバ管理担当の皆さんのおかげで、ブログが再開できる状態になりました。多謝。

カテゴリー: SSSG

diet

茶樹茸(ちゃじゅたけ)がいいらしい。かならず火を通してたべるのがいいらしい。とりすぎはいけないらしい。

カテゴリー: etc

Server

サーバメンテナンスはこまめにしておいた方がいいのはわかっているのですが、なかなか難しいものですね。手が回らないサーバが何台も…ちょっとはプランをたてたいところです。

カテゴリー: etc