最近、セキュリティ機能強化の風潮があちこちで広まり、IE（Edge)ばかりでなく、フリーのFirefox,Chromeまでも同様に標準で、オレオレ証明書（＝公的に保証されていない私的な証明書）のサイトはかならず警告ないし、最悪表示することすらできなくなってしまった。
これでは不便なので、仕方なく自身のサーバにもちゃんとした証明書を用意しなきゃと泣く泣く導入することにしました。
はじめに
まず、最初に準備というか前提ですが、、、本題のサーバ証明書を実装するオレオレ証明書で稼動するWEBサーバ（すなわち、https://*****でサイトが構成されていること）ありきで、話を進めます。
よって、本誌の内容は、いずれかのサービスでVPSサーバを保有し、そこにHTTPSでアクセスできるWEBサーバを立てたことがある方、もしくはこれからされようとされてい方に限られた内容になります。（このようなWEBサーバの立ち上げ方については、近々個人的に実施する予定なのでそのときに記事をアップしようと思ってます。）
ちなみに、今回対象とするWEBサーバの仕様は、以下のとおりです。
＜WEBサーバ仕様＞
- お名前ドットコムのVPSサービス（KVM）でたてたLinuxサーバ
- OSは、CentOS5.9
- WEBサーバは、OSバンドルのApache2.xパッケージを実装後アップデートしたものに、同様に実装したOpenSSLでHTTPSのWEBサイト環境を構築。
- 固定のグローバルIPアドレス×1個（お名前ドットコムのVPSサーバは、1個付与してくれる）
- インターネット上で自サーバのFQDNが使えるようDNSレコードが設定済み（お名前ドットコムの自ドメイン取得サービスを利用）
ここでのポイントはやはり、お名前ドットコムのサービスを使っているということでしょうか。
各サービス機能についての詳細については一長一短あるかと思いますが、通常個人のWEBサーバを維持管理していく上ではそれほど問題にならなかったですし、いずれのサービスも他社と比較しても遜色なく安く、必要なサービスの請求や管理の窓口が一本化されるのは何より便利です。(この良さが、後々の本書の中で効いてきます）
であれば、サーバ証明書の取得サービスもお名前ドットコムのものを使用すればと思うのですが、、、
実際にそのサービスの金額を見たら、他社サービスと比較してもお高いので、そこでこのサービスは以前に安いと評判のKingSSLを利用することにしました。（せめてRapidSSLを担いで欲しかった）
調理開始
以上、必要な材料がそろったので、早速調理に取り掛かります。
まずは、サーバ証明書取得のために、KingSSLのサイトへ。
ここをじっくり調査し、他者と比較検討したわけではないので、ほんとにおすすめできるかは現時点ではなんともいえませんが、
私的には、
- やはり、安い。しかも早い。支払いはクレジットカードのみになりますが、手続きも完全自動化されており、すぐにサーバ証明書を入手可能
- 安いだけにサイトはシンプルだけど、日本語でわかりやすい
- 新規だけでなく更新や再発行の手続きもわかりやすそう
という印象で決めました。(ここは自由に選べますし、将来的にはさらに安い業者もあるかもしれません。ただ、安いだけで決めるのは、今後必要となるサポートや手続きの面で損をすることもあるのでご注意を！）
本紙では、年間900円の1年モノにしました。（もちろん、複数年モノにすればそれだけ割引がありますが、ためしに使ってみるということで1年モノにしました）
さっそく、サイトから申し込み手続きのボタンをクリックして手続き開始へ！
第一関門：CSRの生成と入力
手続きの一発目から、いきなりCSRの入力欄が出現！
まずは手続きの第一関門。オレオレ証明書でやってきたので、CSR生成についてはピンと来なくて、どうすればいいんだけっけ？ってググろうと思ったけど、同サイト内のサポートページで、しっかり手順が書いてありましたので、その手順そのままに実施することにしてみました。
ちなみに、CSRは、サイトにも書かれていたが、”Certificate Signing Request”で、要は証明書を発行する際の本人確認のための情報みたいなもの。具体的には、サーバ内で生成されたサーバ所在情報＋公開鍵データ。
手順としては、サーバ構成が”Apache 2.x + mod_ssl + OpenSSL”なので、その手順ページを参照。
サーバ内での操作としては・・・、
まず、現在WEBサーバが立ち上がっている環境の確認。サーバ立ち上げ時に現在使用されているオレオレ証明書を作成した際に生成された、秘密鍵や証明書＋公開鍵の保管場所を/etc/httpd/conf.d/ssl.confファイル内で下記項目を確認し、
- SSLCertificateFile（サーバ証明書のパス）
- SSLCertificateKeyFile（秘密鍵のパス）
そこに記載されたパスにある、現在使用中の各ファイルをかならずmvコマンドなどで退避させておくこと。さもないと、以降の作業時に誤って消失させてしまうと、同じものを復元させることができませんので、現状のWEBサービスを停止・起動させることができなくなってしまいます。
（最悪、新たな証明書を用意するまで停止状態にするか、もう一度オレオレ証明書を再作成して立ち上げなおせばいいだけの話ですが、今後正規の証明書で運用していく場合は、この場合のリスクについても考慮のこと）
一発目の操作は、まず先のssl.confに記載のSSLCertificateKeyFileパス、すなわち秘密鍵が格納されているパスで以下のコマンドをrootユーザで実行します。
# openssl genrsa -des3 -out ./<生成する秘密鍵ファイル名>.key 2048
ここで、<生成する秘密鍵ファイル名>には、ssl.confの”ServerName”に記述されたファイル名（WEBサーバのFQDNを入れたり、さらに生成日も入れたりするといいでしょう）にして、実行します。
この結果、下記のように表示されるので、秘密鍵に割り当てたいパスフレーズを入力します。（これは、後の手順で入力が必要となるので、間違えず忘れないように！）
[root@myportal ~]# openssl genrsa -des3 -out ./myportal.yshome.net.key 2048 <Retキー>
Generating RSA private key, 2048 bit long modulus
......................................................+++
.......................+++
e is 65537 (0x10001)
Enter pass phrase for ./myportal.yshome.net.key: ＜パスフレーズを入力＞
Verifying - Enter pass phrase for ./myportal.yshome.net.key:＜同上を入力＞
[root@myportal ~]# ls -ltr
この結果、カレントディレクトリに、下記のファイルが生成される。
-rw-r--r-- 1 root root 1751 12月 29 11:07 myportal.yshome.net.key
なお、WEBサーバのFQDNはこの時点でかならず、これがお名前ドットコムのドメインサービスで取得されてDNSレコードに定義されて利用可能であること。
また、このとき入力したパスワードは、後の手順でも使用し続けるので、ちゃんと記録しておきましょう。（忘れてしまったら、手順というか手続きを位置からやり直しとなってしまいます）
この結果、カレントディレクトリに”<生成する秘密鍵ファイル名>.key”というファイル名で、 秘密鍵(2048ビット)が生成されます。
次に、証明書が格納されているパスで、以下のコマンドをrootユーザで実行します。
# openssl req -new -key <前手順で生成した秘密鍵ファイル> -out ./<生成するCSRファイル名>.csr
実行すると、当該WEBサーバの所在情報の入力が一問一答形式で開始されますので、KingSSLサイトのサポートページを参照して適切な値を入力していってください。
[root@myportal ~]# openssl req -new -key ./myportal.yshome.net.key -out ./myportal.yshome.net.csr
Enter pass phrase for ./myportal.yshome.net.key:
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) [GB]:JP
State or Province Name (full name) [Berkshire]:Tokyo
Locality Name (eg, city) [Newbury]:○○-ku
Organization Name (eg, company) [My Company Ltd]:My Home Lab.
Organizational Unit Name (eg, section) []:<入力不要とのこと>
Common Name (eg, your name or your server's hostname) []:myportal.yshome.net
Email Address []:<入力不要とのこと>
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:<先のパスフレーズを入力>
An optional company name []:＜同上＞
[root@myportal ~]# ls -ltr
-rw-r--r-- 1 root root 1751 12月 29 11:07 myportal.yshome.net.key
なお、ここで入力した値は、最終的に得られたサーバ証明書の情報に組み込まれ、ユーザなどからその情報が証明書情報の表示操作で見えてしまうので、誤字やいい加減な入力は恥ずかしい黒歴史となりますので慎重に！
最後に、前手順の秘密鍵生成時に入力したパスワードを入力する必要があります。
この結果、<生成するCSRファイル名>.csr がカレントディレクトリに生成されますので、これをcatやviコマンドで内容を表示させてください。
[root@myportal ~]# cat myportal.yshome.net.csr
-----BEGIN CERTIFICATE REQUEST-----
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
-----END CERTIFICATE REQUEST-----
[root@myportal ~]#
上記のように表示されたファイル内容において、”—–BEGIN ・・・・”の行から、”—–END ・・・・”の行まで、一文字の抜けがない様、また余計な文字が含まれないよう十分注意して、手続き画面の一発目に出現したCSRの入力欄にコピペします。
あとは、次の画面で、入力したCSRのデータから、サーバの所在情報の確認や、支払いに使用するクレジットカードの入力がありますので、各情報を入力していってください。
第二関門：承認メール送り先の用意
っで、この手続きの中で一番問題となる、第二関門の承認メールのメールアドレスの指定ですが、、、
これが厄介なことに、業者のシステムで、登録したFQDN情報から自動生成されたメールアドレスの選択式となっており、自由に入力することができないということです！
たとえば、メールアカウント名が、”hostmaster”,”postmaster”,”admin”となっており、メールアドレスのドメインも、WEBサーバのドメイン名しかありません。。。
（サポートページのFAQにも、回答として「コモンネームに指定のドメインのメールサーバにエイリアスでもいいので・・・」って、スラって書いてあるけど、面倒なのでそもそも自ドメインのメールサーバ立ててないんですけど！）
ここで助かったのが、お名前ドットコムの無料オプション機能の”お名前.comメール転送Plusサービス”です！！
これを知らないときは、1GBプラン￥42円／月のメールサービスを使用やむなしと思っていましたが、”お名前.comメール転送Plusサービス”もあるということを知り、使えるかどうか試しに申し込んでみたところ、思ったとおりの設定ができました！
この機能を有効に設定することで、
自身の管理するドメインのDNSレコードに、MXレコード（お名前ドットコムのメール転送機能用メールサーバ）が登録され、指定したメールアドレスから転送したい任意の既存メールアドレスに転送されるというというものです。おかげでメールサーバの運用コストを増やすことなく、手続きが可能となりました。
具体的には、
KingSSLで選択した、”postmaster@<domainname>”のメールアドレスに対して、
KingSSLの申込者欄の連絡先メールアドレスに記載の私個人利用のメールアドレスを設定するだけ！（この機能自体には、さらに自動応答やフィルタ機能なども備えている）
なお、このメールアドレスは、承認メールが送られるだけで使用するもので、最終的な証明書は、別途申込者情報の入力欄で入力した管理者連絡用メールアドレスに送られてきます。(むしろ、こちらのほうを当該サーバ側に送って欲しい。コピペって文字コードや改行コードなどで意外と危ういですし。）
この後は、上記のとおり、承認メールが転送先のメールアドレスに届くので、その本文中のリンクをクリックして、承認WEB画面内の承認ボタンをクリックして、しばらく待つと、証明書のメールが申込者の連絡先メールアドレスに送付されてきます。
証明書といっても、ファイルではなく、メールの本文内に何十行にもわたる意味不明な文字列が書いてあるので、これをWEBサーバの証明書ファイルにコピペしていくことになります。
たとえば、# cat > <新サーバ証明書ファイル名>.crt
を実行後、標準入力待ちになるので、一気にペーストして流し込む。（流し込んだ後は、<RET>キーを押下し、そのまま不要な文字を入力せずに速やかに「CTRL」＋「C」キー）
なお、本証明書には、中間証明書も必要になっているので、こちらも証明書のディレクトリに新たにファイルを用意してコピペすること。（このファイルは、それとわかるようにkingcacert.cerとか例そのままでもいいかと）
次に、いままでオレオレ証明書では使用することはなかった、中間証明書の指定を先のssl.conf内の”SSLCertificateChainFile”で追加してやる必要があります。
正規のサーバ証明書で立ち上げ！
念のため、各ファイルの内容やパスに誤りがないことを確認の上、
WEBサービスの停止（service httpd stop）＆起動(service httpd start)を実行。すると、起動時にパスワードを要求してきますので、最初の秘密鍵生成時に入力したパスワードを入力します。正しければ、何事もなく新しい正規のサーバ証明書でWEBサーバが立ち上がります！
[root@myportal certs]# service httpd stop
・・・省略・・・
[root@myportal certs]# service httpd start
httpd を起動中: Apache/2.2.3 mod_ssl/2.2.3 (Pass Phrase Dialog)
Some of your private key files are encrypted for security reasons.
In order to read them you have to provide the pass phrases.
Server myportal.yshome.net:443 (RSA)
Enter pass phrase:
OK: Pass Phrase Dialog successful.
[ OK ]
[root@myportal certs]#
補足）なお、再起動実施において、”NG”となった場合の原因の一例として、証明書コードのコピペミスがよくある。
この場合、/var/log/httpd/ssl_error_logに、下記のエラーログが見られる。
＞ [error] Failed to configure CA certificate chain!
このメッセージ自体の意味は、”証明書の初めから終わりまでが正しくない”という内容のものです。
今一度、コピペした証明書ファイルの内容を確認してみましょう。
十中八九、”—–BEGIN CERTIFICATE—–”から”—–END CERTIFICATE—–”までが正しく張り付けられていないはずです。
（コピーの範囲指定ミスで開始または終了の”-“が足りないとか、（コピペ後、<RET>を入れ忘れて）最後の”—–END CERTIFICATE—–”自体が欠落しているなど）
なお、新しいサーバ証明書での動作確認としては、IEの”In Privateブラウズ”でWEBブラウザを立ち上げて、同WEBサーバにアクセスしてみてください！いままでアドレスバー赤色に染まっていたのが、何事もなく水色の鍵アイコンに変わり、そのアイコンをクリックして証明書情報を確認すると、見覚えのある内容が確認できます。
以上の手続きが、時間も問わずなんと半日でできてしまう!というお手軽さ。
本件の目的を適当に急ぎでやっつけちゃおうってことだけであればおすすめしません。（ほんとに必要なのか？ほんとにこの業者でいいのか？をちゃんと考えてから行動を起こしましょう）
が、この運用コストを極力抑えて、本来のWEBサーバのコンテンツ管理の運用を行いたいというのであれば、おすすめします！
追記、肝心なこと忘れてました!
http://でアクセスしに来たら、https://にリダイレクトさせなきゃ。
おわりに・・・
以上で、個人のWEBサーバを、一般的にまともなWEBサーバに近づけることができました。
そもそもサーバ証明書の役割ですが、簡単に言うと、
- 通信を暗号化して、通信の盗聴リスクを回避する。
- サーバを外部の機関が唯一無二のサーバであることを保証してもらうことで、なりすましや改ざんといったリスクを回避する。
といったところでしょうか。
ひと昔では、サーバ証明書と自ドメインの取得と維持管理だけでも年間３万円以上出費しなければならず、自サーバを持ちたい貧乏人にとっては、大変きついものでした。（なので、そういった人はできるだけ出費を抑えようと自力で自己防衛の努力をしてきたのですが。。。）
これを、現実に置き換えて考えると、、、
盗聴やなりすまし(偽称）は、治安のよい日本ではよっぽどの人でない限り、被害にあうことはないものでしたが、今となってはストーカーや詐欺といった犯罪が広まり、普通の人でもその被害者になりつつあります。しかし、実際の生活環境でこれらに対する対策はしてないのに、自身のサーバにだけお金をかけて対策を講じるのも、変な話ですが、インターネットの世界では、当人だけの被害ならまだしも、被害者でありながら知らずに加害者になってしまっているケースがあるので、エチケットとしてこういった対策は施していかなければならないということでしょうか。。。（今という時代やインターネットの世界とは、まったく世知辛いものです）