Mailサーバー => S/MIME暗号化メールを使う > ４．S/MIME暗号化メールに必要な証明書を作成する
SSL for SMTP で解説したクライアント証明書と全く同じです。サーバー証明書もクライアント証明書もnsCertTypeの違いがある程度で、証明書の発行手順は全て同じです。
ここでは 太郎(taro@odn.ne.jp)と花子(hanako@hi-ho.ne.jp)がお互いにDES3(168bit)強度のメールのやり取りを実現 するという例で証明書を作成しています。尚、証明書は自己証明タイプではなく、自CA署名による証明書を例に解説します。
証明書のディレクトリは/etc/mail/certs/users をカレントディレクトリとしています。
補足
ここではCA署名型の証明書を例にしています。この x509証明書にはCAの公開カギが含まれます。そのためSSL Webサーバーで紹介したようなクライアント認証を導入しているケースは、証明書の判別を行わない限り、この証明書でこれらのディレクトリにもアクセスで きる事になるので注意が必要です。
S/MIMEの利用に限定する事が一般的だと思うので、自己証明型の証明書をS/MIMEを利用したいユーザーに配布し、ユーザー側で 「明示的に信頼する」を指定して利用するようにしてもらう方をお奨めします。
参照 => 自己証明型の証明書作成 例
まずはtaroの証明書を作成します。 /etc/mail/certs/users に移動後、署名要求書とプライベートキーを作成します。
Using configuration from /var/ssl/openssl.cnf
Generating a 1024 bit RSA private key
.......++++++
........................++++++
writing new private key to 'privkey.pem'
-----
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]:
State or Province Name (full name) [Osaka]:
Locality Name (eg, city) [xxxxxxxx]:
Organization Name (eg, company) [xxxxxxxxxxxx]:
Organizational Unit Name (eg, section) [xxxxxxxx]:
Common Name (eg, YOUR name) []:taro-odn
Email Address []:taro@odn.ne.jp
Please enter the following 'extra' attributes
A challenge password []:そのままenter
An optional company name []:そのままenter
Common Name (eg, YOUR name)
クライアント認証を行うわけではないので、taroがわかりやすい名前にします。
Email Address
ここにS/MIMEを利用するメールアカウント、すなわちメールアドレスを間違えないように設定します。ここで間違うと利用できないので注意が必要です。
次にCA管理者の立場で、署名要求に対し署名し、証明書を発行します。
/var/ssl/openssl_cliant.cnf
ここではあらかじめ証明書タイプを nsCertType = client, email に変更してあるopenssl_cliant.cnfを作成し、それを指定しています。-config オプションを付けない場合は/var/ssl/openssl.cnfの nsCertType を client, emailに変更して下さい。
先ほどの署名要求の内容が表示されるのでよければOK、間違っていれば、署名要求書を作り直します。
ユーザー証明書
/etc/mail/certs/users/mail_taro_cert.pem
が生成されます。
ユーザーが取り込み可能なPKCS12形式の証明書に変換します。このときCAの公開カギを含むのを忘れないでください。以下は一行です。-name はユーザー名 -canameはサーバーのドメインでかまいません。
以下の質問がありますので答えます。
自CA管理者がtaroに手渡す証明書 mail_taro_cert.p12 の出来上がりです。前述したとおり、これはtaroのための証明書です。個人を特定するために重要なプライベートキーを含んでおり、taro以外の人物に決して渡ってはいけないものです。このようなリスクがあることをCA管理者はtaroに釘を刺してから渡さなくてはなりません。
全く同じ要領で、hanako の証明書ファイルを作成してください。CA管理者としては、まず、taro,hanakoにそれぞれ作成したpkcs12形式の証明書を配布します。CA/サーバー管理者の仕事はここまでです。後はユーザー側の設定となります。
この標題のトップへ ４ / ７ 
