(旧) 猫好きモバイルアプリケーション開発者記録
モバイルアプリケーション開発プログラマの開発ナレッジ記録です
現場におけるSubversionからGitへの移行について
今回は私が実際に社内でSubversionからGitへ移行したときの話をまとめてみました。
うちの社内でもGitに移行したい！と考えている人に、少しでも参考になればと思います。
Gitはもうすっかり世間に浸透してきており、
業界にいる人では利用していない人はいないだろうというくらい多くなって来ました。
しかし、残念なことに未だ日本のIT企業ではSubversionが主流です。
これはGit登場当時、クロスプラットフォームにおける日本語の扱いに問題があったこと、
またWindowsでの動作に不具合が多かったことなどの理由が挙げられます。
かくいう私も、当時はGitよりもWindows対応のしっかりしていたMercurialを推していました。
しかし、Gitもver.1.7.10以降は日本語問題を解決したのと、
Windowsへの対応も大分しっかりしてきたこともあり、
今ではGitを社内SCMとして採用するには必要十分な条件を満たしています。
とはいえ、日本語扱いが怪しいといった当時の印象を持ったままの人が未だにいたり、「Subversionでいいじゃん。敢えてGitに移行したところで教育コストが掛かるしな・・・」などという理由から、移行したがる人がとにかくいません。
こういう人たちに何といえば納得してもらえるのか・・・と考えると、
会社の社風や上司・メンバーの性格にもよるので、確実な手段というものはもちろんありません。
ただ、何もやらなければ結局移行は出来ないので、まずはGitに移行しようという流れをつくることが大事でしょう。
それにはどうすればいいのかということと、
必ず向こうからぶつけられるであろう疑問・質問に対する回答をまとめてみました。
01. Git移行への流れを作るにはまずどこかのプロジェクトでやってみる
プロジェクト単位は比較的小さな単位なので、
その単位であれば許可をしてくれる上司は多いです。
なので、まずはプロジェクトごとにSubversionからGitへの移行を試していけばいいと思います。
更に言えば、「並行開発の多い既存プロジェクト」が一番望ましいです。
その理由については、それがGitの利点を一番生かせるため、成功例として印象付けやすいからです。
02. 「導入してもいいけど教育コスト掛かるんじゃないの？」という質問に対して
社員だけならともかく、パートナーさんなど社外の人をプロジェクトに参入させた場合を考慮し始めると、
やはりコストが掛かるだろうと考える人が多いようです。
先述のとおり、日本のIT業界では未だSubversionが主流なので、Gitを使えない人ばかりだろうという前提で考えている人は多いです。
しかし、Subversionであってもプロジェクトごとにtrunk、branches、tagsの扱い方は違うわけで、結局プロジェクト参入当初の教育という意味でのコストは掛かります。
更に言えば、私はSubversionを知らないという人すらも何人か見て来ました。
なので結局のところ、外部からパートナーさんを呼んだ時であっても、
社員を新しいプロジェクトに参入させたときであっても、
初回の教育コストは掛かりますし、余程アクロバティックなソース管理をしないのであればGitにしたところでそこに差はありません。
Gitであっても、基本はSubversionと同じく、trunk、branches、tagsといったソース管理の考え方自体は踏襲しているので、大きな違いはないと言えます。
03. 「移行することで何が便利になるの？」という質問に対して
当然、それがないことには移行する意味もないわけですから、この点に関する説明も求められると思います。
実は、これが一番難しいです。
何から説明すればいいのかわからなくなりますし、
説明したところで利点に結びつくかどうかは「やってみなければ」みたいな話になってしまう人も多いです。
いわゆる「集中型管理」と「分散型管理」という違いを上げた所で、
「( ´_ゝ｀)ﾌｰﾝ」で終わってしまうのが関の山ですし、
「ローカルでコミットできる」という説明をしたところでも
「一見便利に聞こえるけど、別にできなくてもよくないか？」と言われることもよくあります。
これは結局のところ、Gitを採用しようと思っている人自身も
Gitを満足に複数人開発で利用したことが無いから上手く説明できないことに起因していると言えます。
じゃあ、利点って何なのか。
余計なことはいわずにシンプルに言うと
「ブランチ管理が高速で簡単」
これに尽きます。
そしてこれは、保守と並行して追加開発を複数行う案件など
並行開発が多いプロジェクトほどこの利点が生かされます。
とはいえ、これだけではまだ理解はできないでしょう。
「何がどう簡単なのか」
これを説明するには、実際にEclipseのEGitなどでブランチ切り替えを実演すればわかるかと思います。
ワークスペースを切り替えたり、Eclipseを終了することなく、
ブランチ切り替えを実行することで、数秒〜数十秒ほどで別のソースにガラッと切り替わる。
これは目で見せてあげるのが一番いいと思います。
実際、私もこれを実演したら「これは凄く便利だね」と納得してくれた人が多かったです。
これをSubversionでやろうとすると、
trunk、branchesごとにワークスペースを予め作成しておき、
一回Eclipseを終了させてワークスペースを切り替えて・・・などになるかと思います。
一見これでもいいように聞こえますが、
ソース量が膨大なプロジェクトほどSubversionはチェックアウトに時間が掛かり、
ブランチが増えるたびにそれを行わなくてはいけなくなりますから、
これが結構なストレスになります。
その上、数ヶ月に一度リリースがあるプロジェクトでは
その都度branchesが新たに作成されます。
しかも、そのbranche対応最中で本番環境においてバグ対応などの緊急リリースが発生しますと、
trunkにもbranchesにも修正を反映しなくてはいけなくなります。
このような同じ修正を複数ブランチへ取り込む、といった対応がSubversionだとかなり面倒です。
その点Gitでは、他のブランチのコミット内容を取り込むことができますので、
このような場面にもSubversionと比較して簡単に対応することが出来るようになります。
要は、ブランチ切り替えを実演した上で、上記のような理由から「管理コストが減る」と言っておけば比較的納得します（笑）
04. Subversionのコミット履歴は移行できるの？という質問に対して
これは「git svn」コマンドを利用することで問題なくできます。
ただ、git svnコマンドはgitを導入しただけでは利用できないので
その点についてはまた別の機会に説明します。
とりあえず、「出来る」と回答してしまいましょう。
05. メリット、デメリットは？という質問に対して
何に対してもメリットとデメリットを求めてくる人が世の中にはいます。
メリットは、先述で説明したことになりますので問題ないでしょう。
ではデメリットと聞かれた場合、どう答えればいいでしょうか。
実は、Gitには１つだけデメリットがあり、
「誰でもコミット内容を自由に編集・削除できてしまう」という点があります。
その点Subversionではコミット内容をひたすら溜めていくだけなので、
制限があるからこそ守らているとも言えます。
これに関しては、予め運用ルールを決めておく必要が出てきます。
・「git push -f」を使わない (ローカルで削除したコミットをリモートリポジトリへ反映できてしまう)
・ブランチを勝手に作成・削除しない
この２つのルールは最低でも導入する必要が出てくると思います。
もし仮に、ルールを決めていたにも関わらず上記が守られなかったとした場合でも、
各人の変更は各々のローカルリポジトリにあるので、
誰かのローカルリポジトリを新たなベースとして、そこへマージしてあげれば問題はありません。
これはDVCSのいいところになりますので、
デメリットを説明しつつもメリットの説明になります（笑）
以上が、比較的聞かれるであろう質問に対する回答になります。
私の場合は周囲に新しい技術に対する理解のある方が多かったことも助けとなりましたので、そのようなメンバーを何人か見方につけるというのも手段の１つになります。
みなさんもめげずにGitへ移行して、脱Subversionしてしまいましょう。
次回は、実際にSubversionからGitへ移行するにあたって
必要となるツールをいくつか紹介します。
うちの社内でもGitに移行したい！と考えている人に、少しでも参考になればと思います。
Gitはもうすっかり世間に浸透してきており、
業界にいる人では利用していない人はいないだろうというくらい多くなって来ました。
しかし、残念なことに未だ日本のIT企業ではSubversionが主流です。
これはGit登場当時、クロスプラットフォームにおける日本語の扱いに問題があったこと、
またWindowsでの動作に不具合が多かったことなどの理由が挙げられます。
かくいう私も、当時はGitよりもWindows対応のしっかりしていたMercurialを推していました。
しかし、Gitもver.1.7.10以降は日本語問題を解決したのと、
Windowsへの対応も大分しっかりしてきたこともあり、
今ではGitを社内SCMとして採用するには必要十分な条件を満たしています。
とはいえ、日本語扱いが怪しいといった当時の印象を持ったままの人が未だにいたり、「Subversionでいいじゃん。敢えてGitに移行したところで教育コストが掛かるしな・・・」などという理由から、移行したがる人がとにかくいません。
こういう人たちに何といえば納得してもらえるのか・・・と考えると、
会社の社風や上司・メンバーの性格にもよるので、確実な手段というものはもちろんありません。
ただ、何もやらなければ結局移行は出来ないので、まずはGitに移行しようという流れをつくることが大事でしょう。
それにはどうすればいいのかということと、
必ず向こうからぶつけられるであろう疑問・質問に対する回答をまとめてみました。
01. Git移行への流れを作るにはまずどこかのプロジェクトでやってみる
プロジェクト単位は比較的小さな単位なので、
その単位であれば許可をしてくれる上司は多いです。
なので、まずはプロジェクトごとにSubversionからGitへの移行を試していけばいいと思います。
更に言えば、「並行開発の多い既存プロジェクト」が一番望ましいです。
その理由については、それがGitの利点を一番生かせるため、成功例として印象付けやすいからです。
02. 「導入してもいいけど教育コスト掛かるんじゃないの？」という質問に対して
社員だけならともかく、パートナーさんなど社外の人をプロジェクトに参入させた場合を考慮し始めると、
やはりコストが掛かるだろうと考える人が多いようです。
先述のとおり、日本のIT業界では未だSubversionが主流なので、Gitを使えない人ばかりだろうという前提で考えている人は多いです。
しかし、Subversionであってもプロジェクトごとにtrunk、branches、tagsの扱い方は違うわけで、結局プロジェクト参入当初の教育という意味でのコストは掛かります。
更に言えば、私はSubversionを知らないという人すらも何人か見て来ました。
なので結局のところ、外部からパートナーさんを呼んだ時であっても、
社員を新しいプロジェクトに参入させたときであっても、
初回の教育コストは掛かりますし、余程アクロバティックなソース管理をしないのであればGitにしたところでそこに差はありません。
Gitであっても、基本はSubversionと同じく、trunk、branches、tagsといったソース管理の考え方自体は踏襲しているので、大きな違いはないと言えます。
03. 「移行することで何が便利になるの？」という質問に対して
当然、それがないことには移行する意味もないわけですから、この点に関する説明も求められると思います。
実は、これが一番難しいです。
何から説明すればいいのかわからなくなりますし、
説明したところで利点に結びつくかどうかは「やってみなければ」みたいな話になってしまう人も多いです。
いわゆる「集中型管理」と「分散型管理」という違いを上げた所で、
「( ´_ゝ｀)ﾌｰﾝ」で終わってしまうのが関の山ですし、
「ローカルでコミットできる」という説明をしたところでも
「一見便利に聞こえるけど、別にできなくてもよくないか？」と言われることもよくあります。
これは結局のところ、Gitを採用しようと思っている人自身も
Gitを満足に複数人開発で利用したことが無いから上手く説明できないことに起因していると言えます。
じゃあ、利点って何なのか。
余計なことはいわずにシンプルに言うと
「ブランチ管理が高速で簡単」
これに尽きます。
そしてこれは、保守と並行して追加開発を複数行う案件など
並行開発が多いプロジェクトほどこの利点が生かされます。
とはいえ、これだけではまだ理解はできないでしょう。
「何がどう簡単なのか」
これを説明するには、実際にEclipseのEGitなどでブランチ切り替えを実演すればわかるかと思います。
ワークスペースを切り替えたり、Eclipseを終了することなく、
ブランチ切り替えを実行することで、数秒〜数十秒ほどで別のソースにガラッと切り替わる。
これは目で見せてあげるのが一番いいと思います。
実際、私もこれを実演したら「これは凄く便利だね」と納得してくれた人が多かったです。
これをSubversionでやろうとすると、
trunk、branchesごとにワークスペースを予め作成しておき、
一回Eclipseを終了させてワークスペースを切り替えて・・・などになるかと思います。
一見これでもいいように聞こえますが、
ソース量が膨大なプロジェクトほどSubversionはチェックアウトに時間が掛かり、
ブランチが増えるたびにそれを行わなくてはいけなくなりますから、
これが結構なストレスになります。
その上、数ヶ月に一度リリースがあるプロジェクトでは
その都度branchesが新たに作成されます。
しかも、そのbranche対応最中で本番環境においてバグ対応などの緊急リリースが発生しますと、
trunkにもbranchesにも修正を反映しなくてはいけなくなります。
このような同じ修正を複数ブランチへ取り込む、といった対応がSubversionだとかなり面倒です。
その点Gitでは、他のブランチのコミット内容を取り込むことができますので、
このような場面にもSubversionと比較して簡単に対応することが出来るようになります。
要は、ブランチ切り替えを実演した上で、上記のような理由から「管理コストが減る」と言っておけば比較的納得します（笑）
04. Subversionのコミット履歴は移行できるの？という質問に対して
これは「git svn」コマンドを利用することで問題なくできます。
ただ、git svnコマンドはgitを導入しただけでは利用できないので
その点についてはまた別の機会に説明します。
とりあえず、「出来る」と回答してしまいましょう。
05. メリット、デメリットは？という質問に対して
何に対してもメリットとデメリットを求めてくる人が世の中にはいます。
メリットは、先述で説明したことになりますので問題ないでしょう。
ではデメリットと聞かれた場合、どう答えればいいでしょうか。
実は、Gitには１つだけデメリットがあり、
「誰でもコミット内容を自由に編集・削除できてしまう」という点があります。
その点Subversionではコミット内容をひたすら溜めていくだけなので、
制限があるからこそ守らているとも言えます。
これに関しては、予め運用ルールを決めておく必要が出てきます。
・「git push -f」を使わない (ローカルで削除したコミットをリモートリポジトリへ反映できてしまう)
・ブランチを勝手に作成・削除しない
この２つのルールは最低でも導入する必要が出てくると思います。
もし仮に、ルールを決めていたにも関わらず上記が守られなかったとした場合でも、
各人の変更は各々のローカルリポジトリにあるので、
誰かのローカルリポジトリを新たなベースとして、そこへマージしてあげれば問題はありません。
これはDVCSのいいところになりますので、
デメリットを説明しつつもメリットの説明になります（笑）
以上が、比較的聞かれるであろう質問に対する回答になります。
私の場合は周囲に新しい技術に対する理解のある方が多かったことも助けとなりましたので、そのようなメンバーを何人か見方につけるというのも手段の１つになります。
みなさんもめげずにGitへ移行して、脱Subversionしてしまいましょう。
次回は、実際にSubversionからGitへ移行するにあたって
必要となるツールをいくつか紹介します。
オレオレ証明書を信頼のおけるSSL証明書にしてみる Vol.3 (証明書の設定とインストール)
前回の「オレオレ証明書を信頼のおけるSSL証明書にしてみる Vol.2」の続きです。
証明書の準備が出来たので、残るは設定とインストールだけになります。
今回は簡潔に設定方法を紹介します。
01. Apache or nginxへの証明書の設定
ここでは Apache と nginx について設定例を紹介します。
■Apacheの場合
Apacheの場合、443のVirtualHostディレクティブ内へサーバのSSL証明書、サーバの秘密鍵、サーバのSSL証明書を署名した中間認証局の証明書の３つの情報を設定すればOKです。
具体的には以下のように設定します。
中間認証局が複数ある場合は、以下のようにサーバのSSL証明書を署名した中間認証局から順に結合していき、出来たファイルを SSLCertificateChainFile ディレクティブへ設定します。
ここでは、ica3.crt がサーバのSSL証明書を署名した中間認証局の証明書とし、以降番号の降順にルート認証局へ近づくようになっています。
(※ただし、これについては推奨しません。詳細は後述の 03 を参照)
■nginxの場合
nginxの場合は、Apacheの中間認証局の証明書を設定する
SSLCertificateChainFile ディレクティブに相当するものがありません。
そのため、nginxの場合は、サーバのSSL証明書の後ろにサーバ証明書を署名した中間認証局の証明書を記述します。
具体的には以下のコマンドで、nginx用のサーバのSSL証明書を作成します。
作成したSSL証明書と秘密鍵を以下のように nginx の conf ファイルへ設定します。
Apacheの場合と同じく、中間認証局が複数ある場合は、以下のようにサーバ証明書を署名した中間認証局から順に結合していきます。(※ただし、これについては推奨しません。詳細は後述の 03 を参照)
以上で、Apacheまたはnginxへの設定は完了になります。
02. ブラウザまたはiPhoneへ認証局の証明書をインストールする
Vol.2で作成したバイナリ形式の証明書である「rca.der」と「ica.der」をインストールします。
手順は至って簡単で、これらのファイルをOS内へダウンロードし、ダブルクリックして信頼する証明書としてインストールすればOKです。(IEやChromeの場合はOSに設定された証明書情報を参照しますが、Firefoxの場合はブラウザ本体に設定するため注意)
iPhoneの場合は、http でアクセス可能な場所へこれらバイナリ形式の証明書を配置し、Safariでダウンロードして信頼する証明書としてインストールするだけでOKです。
以上で、オレオレ証明書が設定されたサーバであるにも関わらず警告が出ずにSSL通信を行うことが可能になりました。
認証局を作る手順が若干手間ですが、一度作ってしまえば簡単ですので、是非試してみましょう。
03. サーバに設定された中間認証局の証明書とブラウザやOSにインストールされた認証局の証明書の関係
ところで、前回の例ですと中間認証局にあたる
「部長」「課長」「係長」がいるという話になっていたかと思います。
これらは「社長」であるルート認証局から以下の用に４段階に分けて認証局を経て署名されていることになります。
このうち、どれか１つでも証明書が欠けているとSSL通信時に「警告」が出るようになります。
証明書を設定出来る場所は、ユーザのOSまたはブラウザ、
サーバのApacheまたはnginxのいずれかになります。
つまり、OS(ブラウザ)に「社長」と「部長」の認証局証明書が予めインストールされている場合、
サーバ(Apache or nginx)側で設定するべき認証局証明書は「課長」と「係長」になります。
別の例ですと、OS(ブラウザ)に「社長」しかインストールされていない場合は、
サーバ(Apache or nginx)側で設定するべき認証局証明書は「部長」と「課長」と「係長」になります。
Apacheの設定を例にもう少し具体的に説明しますと、
ブラウザがSSL証明書の設定されたサーバへSSL接続を行うとき、
まずサーバ側から SSLCertificateFile ディレクティブで設定された証明書情報と
SSLCertificateChainFile ディレクティブで設定された証明書情報をダウンロードします。
そして、ブラウザ側で予め持っている証明書の情報と繋ぎあわせ、
「社長」〜「一般社員」まで繋げることが出来れば成功と判断し、
信頼のあるサーバとして警告を出さずにSSL接続することが出来るようになるわけです。
なので極端な話、
サーバ側の SSLCertificateChainFile ディレクティブに
すべての中間認証局の証明書を結合し、
ルート認証局だけブラウザ側へ信頼のある証明書としてインストールしてしまえば、それだけでも警告なしに接続することが出来るようになります。
ですが、それだとセキュリティ的にあまり意味がない話となります。
なぜなら、「社長」以外の中間認証局の証明書はそのサイトへSSL接続したときに自動的にダウンロードされるわけですから、４段階で署名したものが１段階で署名したものと大差ないことになってしまいます。
Vol.1の例でも説明したとおり、「社長」だけを懐柔しておけばいいという話になってしまいますから、これだとよろしくないわけです。
なので、基本はサーバ証明書を署名した中間認証局(係長)の証明書だけを
SSLCertificateChainFile ディレクティブへ設定し、
その他は予めブラウザやOS側へインストールされているという状態が望ましいです。
以上で、３回に渡って説明してきたオレオレ証明書を信頼のおけるSSL証明書にしてみる説明は終了になります。
今回の手順を使えば、iPhoneやAndroidでも警告なしのSSL通信を行うことが可能になりますので、テスト環境でSSL接続したい場合は是非参考にしてみてください。
証明書の準備が出来たので、残るは設定とインストールだけになります。
今回は簡潔に設定方法を紹介します。
01. Apache or nginxへの証明書の設定
ここでは Apache と nginx について設定例を紹介します。
■Apacheの場合
Apacheの場合、443のVirtualHostディレクティブ内へサーバのSSL証明書、サーバの秘密鍵、サーバのSSL証明書を署名した中間認証局の証明書の３つの情報を設定すればOKです。
具体的には以下のように設定します。
<VirtualHost _default_:443>
(...省略...)
SSLCertificateFile "/usr/local/ssl/private/server.crt" # サーバのSSL証明書
SSLCertificateKeyFile "/usr/local/ssl/private/server.key" # サーバのSSL証明書の秘密鍵
SSLCertificateChainFile "/usr/local/ssl/ICA/ica.crt" # 中間認証局の証明書
(...省略...)
</VirtualHost>
中間認証局が複数ある場合は、以下のようにサーバのSSL証明書を署名した中間認証局から順に結合していき、出来たファイルを SSLCertificateChainFile ディレクティブへ設定します。
ここでは、ica3.crt がサーバのSSL証明書を署名した中間認証局の証明書とし、以降番号の降順にルート認証局へ近づくようになっています。
(※ただし、これについては推奨しません。詳細は後述の 03 を参照)
cat ica3.crt ica2.crt ica.crt > ica-bundle.crt
■nginxの場合
nginxの場合は、Apacheの中間認証局の証明書を設定する
SSLCertificateChainFile ディレクティブに相当するものがありません。
そのため、nginxの場合は、サーバのSSL証明書の後ろにサーバ証明書を署名した中間認証局の証明書を記述します。
具体的には以下のコマンドで、nginx用のサーバのSSL証明書を作成します。
cd /usr/local/ssl
cat certs/server.crt ICA/ica.crt > certs/server.nginx.crt
作成したSSL証明書と秘密鍵を以下のように nginx の conf ファイルへ設定します。
server {
listen 443;
(...省略...)
ssl_certificate /usr/local/ssl/certs/server.nginx.crt;
ssl_certificate_key /usr/local/ssl/private/server.key;
(...省略...)
}Apacheの場合と同じく、中間認証局が複数ある場合は、以下のようにサーバ証明書を署名した中間認証局から順に結合していきます。(※ただし、これについては推奨しません。詳細は後述の 03 を参照)
cat server.crt ica3.crt ica2.crt ica.crt > certs/server.nginx.crt
以上で、Apacheまたはnginxへの設定は完了になります。
02. ブラウザまたはiPhoneへ認証局の証明書をインストールする
Vol.2で作成したバイナリ形式の証明書である「rca.der」と「ica.der」をインストールします。
手順は至って簡単で、これらのファイルをOS内へダウンロードし、ダブルクリックして信頼する証明書としてインストールすればOKです。(IEやChromeの場合はOSに設定された証明書情報を参照しますが、Firefoxの場合はブラウザ本体に設定するため注意)
iPhoneの場合は、http でアクセス可能な場所へこれらバイナリ形式の証明書を配置し、Safariでダウンロードして信頼する証明書としてインストールするだけでOKです。
以上で、オレオレ証明書が設定されたサーバであるにも関わらず警告が出ずにSSL通信を行うことが可能になりました。
認証局を作る手順が若干手間ですが、一度作ってしまえば簡単ですので、是非試してみましょう。
03. サーバに設定された中間認証局の証明書とブラウザやOSにインストールされた認証局の証明書の関係
ところで、前回の例ですと中間認証局にあたる
「部長」「課長」「係長」がいるという話になっていたかと思います。
これらは「社長」であるルート認証局から以下の用に４段階に分けて認証局を経て署名されていることになります。
社長
↓ ←署名
部長
↓ ←署名
課長
↓ ←署名
係長
↓ ←署名
一般社員 (サーバのSSL証明書)
このうち、どれか１つでも証明書が欠けているとSSL通信時に「警告」が出るようになります。
証明書を設定出来る場所は、ユーザのOSまたはブラウザ、
サーバのApacheまたはnginxのいずれかになります。
つまり、OS(ブラウザ)に「社長」と「部長」の認証局証明書が予めインストールされている場合、
サーバ(Apache or nginx)側で設定するべき認証局証明書は「課長」と「係長」になります。
別の例ですと、OS(ブラウザ)に「社長」しかインストールされていない場合は、
サーバ(Apache or nginx)側で設定するべき認証局証明書は「部長」と「課長」と「係長」になります。
Apacheの設定を例にもう少し具体的に説明しますと、
ブラウザがSSL証明書の設定されたサーバへSSL接続を行うとき、
まずサーバ側から SSLCertificateFile ディレクティブで設定された証明書情報と
SSLCertificateChainFile ディレクティブで設定された証明書情報をダウンロードします。
そして、ブラウザ側で予め持っている証明書の情報と繋ぎあわせ、
「社長」〜「一般社員」まで繋げることが出来れば成功と判断し、
信頼のあるサーバとして警告を出さずにSSL接続することが出来るようになるわけです。
なので極端な話、
サーバ側の SSLCertificateChainFile ディレクティブに
すべての中間認証局の証明書を結合し、
ルート認証局だけブラウザ側へ信頼のある証明書としてインストールしてしまえば、それだけでも警告なしに接続することが出来るようになります。
ですが、それだとセキュリティ的にあまり意味がない話となります。
なぜなら、「社長」以外の中間認証局の証明書はそのサイトへSSL接続したときに自動的にダウンロードされるわけですから、４段階で署名したものが１段階で署名したものと大差ないことになってしまいます。
Vol.1の例でも説明したとおり、「社長」だけを懐柔しておけばいいという話になってしまいますから、これだとよろしくないわけです。
なので、基本はサーバ証明書を署名した中間認証局(係長)の証明書だけを
SSLCertificateChainFile ディレクティブへ設定し、
その他は予めブラウザやOS側へインストールされているという状態が望ましいです。
以上で、３回に渡って説明してきたオレオレ証明書を信頼のおけるSSL証明書にしてみる説明は終了になります。
今回の手順を使えば、iPhoneやAndroidでも警告なしのSSL通信を行うことが可能になりますので、テスト環境でSSL接続したい場合は是非参考にしてみてください。
オレオレ証明書を信頼のおけるSSL証明書にしてみる Vol.2 (認証局と証明書の作成)
前回の「オレオレ証明書を信頼のおけるSSL証明書にしてみる Vol.1」の続きです。
今回は実際にオレオレルート認証局、オレオレ中間認証局、オレオレSSL証明書を作成する手順を紹介していきます。
01. OpenSSLを認証局作成先サーバへインストールする
これがないと始まらないので、手短に説明します。
yumでインストールしてもいいし、ソースからインストールしても構いませんが、
今回はディレクトリのパスを共通化するためにソースからのインストールを紹介します。
こんな感じでインストールします。
02. ルート認証局を作成する
前回の例えの説明でいうところの「社長」を作成します。
※以降の作業は全てルートユーザにて行っています。
02-01. ルート認証局用のOpenSSL設定ファイルを作成する
以下のコマンドでルート認証局用ディレクトリを作成し、デフォルトの設定ファイルをコピーします。
02-02. ルート認証局用のOpenSSL設定ファイルを編集する
02-01で作成した「openssl_rca.cnf」を vim などで開き、以下の項目を編集します。
02-03. ルート認証局スクリプトを作成する
以下の手順で作成します。
また、作成した RCA.sh を vim などで開き、以下の値をヘッダコメントのすぐ下に追加します。
02-04. ルート認証局スクリプトでルート認証局を新規作成する
以下のコマンドを実行します。
「CA cretificate filename (or enter tocreate)」と聞かれますが、無視してEnterで次へ進みます。
すると、「Enter PEM pass phrase」と認証局の秘密鍵のパスワード入力を促されますので、パスワードを入力します。
その後、以下を項目の入力を促されますので、以下の例を参考に値を入力します。
上記項目を入力後、「Enter pass phrase for /usr/local/ssl/RCA/private/./cakey.pem」と再び秘密鍵のパスワードを聞かれますので、パスワードを入力しておきます。
完了すると、/usr/local/ssl/RCA ディレクトリにルート認証局の証明書ファイルが作成されます。
最後に、以下のコマンドにて後でOSやブラウザへインストールするための、ルート認証局証明書のバイナリ形式(DER)ファイルを作成しておきます。
これでルート認証局を作成することが出来ました。
認証局の証明書のインストールについては後述するとして、
次は中間認証局の作成に移ります。
03. 中間認証局を作成する
前回の例えの説明でいうところの「部長」「課長」「係長」を作成します。
03-01. 中間認証局用のOpenSSL設定ファイルを作成する
以下のコマンドで中間認証局用ディレクトリを作成し、ルート認証局用の設定ファイルをコピーします。
03-02. 中間認証局用のOpenSSL設定ファイルを編集する
03-01で作成した「openssl_ica.cnf」を vim などで開き、以下の項目を編集します。
03-03. 中間認証局スクリプトを作成する
以下の手順で作成します。
また、作成した ICA.sh を vim などで開き、以下の値を変更します。
03-04. ルート認証局スクリプトから中間認証局の証明書を作成するための要求証明書を作成する
ここからルート認証局作成時とは手順が変わってきます。
中間認証局はルート認証局によって認められたものになるわけですから、
これから作成したい中間認証局の要求証明書を作成します。
この要求証明書に企業名などの各種情報が記載されており、
ルート認証局はその要求証明書を審査することで、中間認証局の証明書を作成するかどうかを判断します。
要求証明書の作成には以下のコマンドを実行します。
すると、「Enter PEM pass phrase」と作成する中間認証局の秘密鍵のパスワード入力を促されますので、パスワードを入力します。
その後、以下を項目の入力を促されますので、以下の例を参考に値を入力します。
すると、中間認証局の秘密鍵「newkey.pem」と要求証明書の「newreq.pem」が /usr/local/ssl/ICA ディレクトリへ作成されます。(ファイル名はこの時点では絶対に変えないで下さい)
03-05. ルート認証局を使って中間認証局の要求証明書を署名する
中間認証局の証明書を発行するために、ルート認証局を使って中間認証局の要求証明書を署名します。
これも前回の例えでいいますと、ルート認証局である社長が中間認証局である部長に「お前は今日から部長だ」と認めるというわけです。
以下のコマンドを実行します。
すると、ルート認証局の秘密鍵のパスワードを聞かれますので、パスワードを入力します。
その後、以下の様な画面になります。
署名するかどうかを聞かれていますので、問題なければ「y」を入力していきます。
その後、「1 out of 1 certificate requests certified, commit? [y/n]」と聞かれますので、問題なければ「y」を入力して確定します。
すると、中間認証局の証明書ファイルである「newcert.pem」ファイルが /usr/local/ssl/ICA ディレクトリへ作成されます。
03-06. 中間認証局を認証局として動作させる
これで中間認証局の証明書ファイルは作成されましたが、このままだと中間認証局は証明書があるだけで認証局として動作しません。
そのため、認証局として動作させるために必要なファイルを作成します。
以下のコマンドを実行します。
「CA cretificate filename (or enter tocreate)」と聞かれますが、
ルート証明書のときとは違って今回は元となる証明書ファイルを指定します。
元となる証明書ファイルとは 03-05 で作成した「newcert.pem」ファイルになりますので、
以下のパスを入力して決定します。
すると、中間認証局の必要な各種ファイルが /usr/local/ssl/ICA へ作成されます。
あとは、中間認証局の秘密鍵をファイル名を変更して private ディレクトリへ移動すれば完了です。
最後に、ルート認証局のときと同様に中間認証局の証明書を後ほどブラウザやOSへインストールするために、バイナリ形式(DER)版も作成し、ApacheやNginxで利用するためのCRTファイルを作成しておきます。
これで中間認証局の作成が完了しました。
いわゆる「部長」の作成が終わったことになるのですが、
「課長」を作成する場合はこの手順のルート証明書の部分を「部長」に置き換えて作成する必要があります。
同様に、「係長」を作成する場合は、この手順のルート証明書の部分を「課長」に置き換えて作成する必要があります。
今回は全て作成したことにして次へ進みます。
04. サーバ証明書を作成する
ようやく認証局の作成が完了しましたので、
サーバ証明書の作成に入れます。
サーバ証明書の作成も中間認証局作成時と同様で、秘密鍵と要求証明書をまず作成します。
04-01. サーバの秘密鍵を作成する
以下のコマンドで作成します。
認証局のときとは違い、秘密鍵のパスフレーズを解除しておきます。
(毎回パスワードを聞かれるとApacheやnginxで使えないため)
04-02. サーバの要求証明書を作成する
以下のコマンドで要求証明書を新規作成する。
その後、以下を項目の入力を促されますので、以下の例を参考に値を入力します。
入力完了後、「newreq.pem」ファイルが作成されます。
04-03. 中間認証局を使ってサーバ証明書を発行する
中間認証局でサーバの要求証明書を署名し、サーバ証明書を発行します。
以下のコマンドを入力します。
すると、中間認証局の秘密鍵のパスワードを聞かれますので入力します。
その後、以下の様な表示になりますので、「y」を選択して署名します。
署名後、「newcert.pem」ファイルが /usr/local/ssl/private ディレクトリへ作成されます。
「newcert.pem」ファイルのままだと利用できないので、
以下のコマンドで余計な情報を排除した CRT ファイルを作成します。
また、秘密鍵も区別しやすいようにファイル名を変更しておきます。
これでサーバ証明書の作成は完了です。
ちなみに、証明書の有効期間を変更する場合は
サーバ証明書を署名する中間認証局の設定ファイル(openssl_ica.cnf)にある
default_days の値を変更することで期間を変更できます。
以上で、認証局と証明書の作成については完了です。
次回は作成した証明書をApacheやnginxに設定したり、
ブラウザやOSにインストールする手順を紹介します。
Vol.3へ続く
今回は実際にオレオレルート認証局、オレオレ中間認証局、オレオレSSL証明書を作成する手順を紹介していきます。
01. OpenSSLを認証局作成先サーバへインストールする
これがないと始まらないので、手短に説明します。
yumでインストールしてもいいし、ソースからインストールしても構いませんが、
今回はディレクトリのパスを共通化するためにソースからのインストールを紹介します。
cd /usr/local/src
wget http://www.openssl.org/source/openssl-1.0.1e.tar.gz
tar zxvf openssl-1.0.1e.tar.gz
cd openssl-1.0.1e
./config --prefix=/usr/local --openssldir=/usr/local/ssl -fPIC enable-tlsext shared
make 2>&1 | tee make.log && make install 2>&1 | tee -a make.log
こんな感じでインストールします。
02. ルート認証局を作成する
前回の例えの説明でいうところの「社長」を作成します。
※以降の作業は全てルートユーザにて行っています。
02-01. ルート認証局用のOpenSSL設定ファイルを作成する
以下のコマンドでルート認証局用ディレクトリを作成し、デフォルトの設定ファイルをコピーします。
cd /usr/local/ssl
mkdir RCA
cp openssl.cnf openssl_rca.cnf
02-02. ルート認証局用のOpenSSL設定ファイルを編集する
02-01で作成した「openssl_rca.cnf」を vim などで開き、以下の項目を編集します。
＜ディレクトリ変更(※２箇所あるので２箇所とも変更する)＞
dir = /usr/local/ssl
↓
dir = /usr/local/ssl/RCA
＜認証種別変更＞
[ v3_ca ]
#nsCertType = sslCA, emailCA
↓
nsCertType = sslCA, emailCA
＜サーバ証明書署名時のNetscape用認証種別変更＞
[ usr_cert ]
#nsCertType = server
↓
nsCertType = server
＜暗号化bit数の変更＞
[ req ]
default_bits = 1024
↓
default_bits = 2048
＜証明書有効期間の変更＞
[ CA_default ]
default_days = 365
↓
default_days = 1095
02-03. ルート認証局スクリプトを作成する
以下の手順で作成します。
cd /usr/local/ssl/misc
cp CA.sh RCA.sh
また、作成した RCA.sh を vim などで開き、以下の値をヘッダコメントのすぐ下に追加します。
CATOP=/usr/local/ssl/RCA
SSLEAY_CONFIG="-config /usr/local/ssl/openssl_rca.cnf"
02-04. ルート認証局スクリプトでルート認証局を新規作成する
以下のコマンドを実行します。
/usr/local/ssl/misc/RCA.sh -newca
「CA cretificate filename (or enter tocreate)」と聞かれますが、無視してEnterで次へ進みます。
すると、「Enter PEM pass phrase」と認証局の秘密鍵のパスワード入力を促されますので、パスワードを入力します。
その後、以下を項目の入力を促されますので、以下の例を参考に値を入力します。
Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Tokyo
Locality Name (eg, city) []:Setagaya
Organization Name (eg, company) [Internet Widgits Pty Ltd]:SSL Test Company
Organizational Unit Name (eg, section) []:Network
Common Name (e.g. server FQDN or YOUR name) []:SSL Test Company RCA
Email Address []:(メールアドレス)
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
上記項目を入力後、「Enter pass phrase for /usr/local/ssl/RCA/private/./cakey.pem」と再び秘密鍵のパスワードを聞かれますので、パスワードを入力しておきます。
完了すると、/usr/local/ssl/RCA ディレクトリにルート認証局の証明書ファイルが作成されます。
最後に、以下のコマンドにて後でOSやブラウザへインストールするための、ルート認証局証明書のバイナリ形式(DER)ファイルを作成しておきます。
cd /usr/local/ssl/RCA
openssl x509 -inform pem -in cacert.pem -outform der -out rca.der
これでルート認証局を作成することが出来ました。
認証局の証明書のインストールについては後述するとして、
次は中間認証局の作成に移ります。
03. 中間認証局を作成する
前回の例えの説明でいうところの「部長」「課長」「係長」を作成します。
03-01. 中間認証局用のOpenSSL設定ファイルを作成する
以下のコマンドで中間認証局用ディレクトリを作成し、ルート認証局用の設定ファイルをコピーします。
cd /usr/local/ssl
mkdir ICA
cp openssl_rca.cnf openssl_ica.cnf
03-02. 中間認証局用のOpenSSL設定ファイルを編集する
03-01で作成した「openssl_ica.cnf」を vim などで開き、以下の項目を編集します。
＜ディレクトリ変更前＞
dir = /usr/local/ssl/RCA
↓
＜ディレクトリ変更後 (※２箇所あるので２箇所とも変更する)＞
dir = /usr/local/ssl/ICA
03-03. 中間認証局スクリプトを作成する
以下の手順で作成します。
cd /usr/local/ssl/misc
cp RCA.sh ICA.sh
また、作成した ICA.sh を vim などで開き、以下の値を変更します。
＜変更前＞
CATOP=/usr/local/ssl/RCA
SSLEAY_CONFIG="-config /usr/local/ssl/openssl_rca.cnf"
↓
＜変更後＞
CATOP=/usr/local/ssl/ICA
SSLEAY_CONFIG="-config /usr/local/ssl/openssl_ica.cnf"
03-04. ルート認証局スクリプトから中間認証局の証明書を作成するための要求証明書を作成する
ここからルート認証局作成時とは手順が変わってきます。
中間認証局はルート認証局によって認められたものになるわけですから、
これから作成したい中間認証局の要求証明書を作成します。
この要求証明書に企業名などの各種情報が記載されており、
ルート認証局はその要求証明書を審査することで、中間認証局の証明書を作成するかどうかを判断します。
要求証明書の作成には以下のコマンドを実行します。
cd /usr/local/ssl/ICA
/usr/local/ssl/misc/ICA.sh -newreq
すると、「Enter PEM pass phrase」と作成する中間認証局の秘密鍵のパスワード入力を促されますので、パスワードを入力します。
その後、以下を項目の入力を促されますので、以下の例を参考に値を入力します。
Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Tokyo
Locality Name (eg, city) []:Setagaya
Organization Name (eg, company) [Internet Widgits Pty Ltd]:SSL Test Company
Organizational Unit Name (eg, section) []:Network
Common Name (e.g. server FQDN or YOUR name) []:SSL Test Company ICA
Email Address []:(メールアドレス)
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
すると、中間認証局の秘密鍵「newkey.pem」と要求証明書の「newreq.pem」が /usr/local/ssl/ICA ディレクトリへ作成されます。(ファイル名はこの時点では絶対に変えないで下さい)
03-05. ルート認証局を使って中間認証局の要求証明書を署名する
中間認証局の証明書を発行するために、ルート認証局を使って中間認証局の要求証明書を署名します。
これも前回の例えでいいますと、ルート認証局である社長が中間認証局である部長に「お前は今日から部長だ」と認めるというわけです。
以下のコマンドを実行します。
cd /usr/local/ssl/ICA
/usr/local/ssl/misc/RCA.sh -signCA
すると、ルート認証局の秘密鍵のパスワードを聞かれますので、パスワードを入力します。
その後、以下の様な画面になります。
Using configuration from /usr/local/ssl/openssl_rca.cnf
Enter pass phrase for /usr/local/ssl/RCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 12558440992105649970 (0xae488b8b7b295732)
Validity
Not Before: Mar 31 09:17:54 2013 GMT
Not After : Mar 30 09:17:54 2016 GMT
Subject:
countryName = JP
stateOrProvinceName = Tokyo
localityName = Setagaya
organizationName = SSL Test Company
organizationalUnitName = Network
commonName = SSL Test Company RCA
emailAddress = (要求証明書発行時に入力したメールアドレス)
X509v3 extensions:
X509v3 Subject Key Identifier:
1E:9E:D3:F3:68:1F:7E:F6:F9:8E:E2:3D:B1:CB:90:A1:AE:CB:95:BD
X509v3 Authority Key Identifier:
keyid:7C:27:6F:57:B2:70:E9:11:1F:75:8B:C1:02:66:D0:DA:0B:BB:B0:67
X509v3 Basic Constraints:
CA:TRUE
Netscape Cert Type:
SSL CA, S/MIME CA
Certificate is to be certified until Mar 30 09:17:54 2016 GMT (1095 days)
Sign the certificate? [y/n]:
署名するかどうかを聞かれていますので、問題なければ「y」を入力していきます。
その後、「1 out of 1 certificate requests certified, commit? [y/n]」と聞かれますので、問題なければ「y」を入力して確定します。
すると、中間認証局の証明書ファイルである「newcert.pem」ファイルが /usr/local/ssl/ICA ディレクトリへ作成されます。
03-06. 中間認証局を認証局として動作させる
これで中間認証局の証明書ファイルは作成されましたが、このままだと中間認証局は証明書があるだけで認証局として動作しません。
そのため、認証局として動作させるために必要なファイルを作成します。
以下のコマンドを実行します。
/usr/local/ssl/misc/ICA.sh -newca
「CA cretificate filename (or enter tocreate)」と聞かれますが、
ルート証明書のときとは違って今回は元となる証明書ファイルを指定します。
元となる証明書ファイルとは 03-05 で作成した「newcert.pem」ファイルになりますので、
以下のパスを入力して決定します。
/usr/local/ssl/ICA/newcert.pem
すると、中間認証局の必要な各種ファイルが /usr/local/ssl/ICA へ作成されます。
あとは、中間認証局の秘密鍵をファイル名を変更して private ディレクトリへ移動すれば完了です。
cd /usr/local/ssl/ICA
mv newkey.pem private/cakey.pem
最後に、ルート認証局のときと同様に中間認証局の証明書を後ほどブラウザやOSへインストールするために、バイナリ形式(DER)版も作成し、ApacheやNginxで利用するためのCRTファイルを作成しておきます。
cd /usr/local/ssl/ICA
openssl x509 -inform pem -in cacert.pem -outform der -out ica.der
openssl x509 -in cacert.pem -out ica.crt
これで中間認証局の作成が完了しました。
いわゆる「部長」の作成が終わったことになるのですが、
「課長」を作成する場合はこの手順のルート証明書の部分を「部長」に置き換えて作成する必要があります。
同様に、「係長」を作成する場合は、この手順のルート証明書の部分を「課長」に置き換えて作成する必要があります。
今回は全て作成したことにして次へ進みます。
04. サーバ証明書を作成する
ようやく認証局の作成が完了しましたので、
サーバ証明書の作成に入れます。
サーバ証明書の作成も中間認証局作成時と同様で、秘密鍵と要求証明書をまず作成します。
04-01. サーバの秘密鍵を作成する
以下のコマンドで作成します。
cd /usr/local/ssl/private
openssl genrsa -des3 2048 > newkey.pem
認証局のときとは違い、秘密鍵のパスフレーズを解除しておきます。
(毎回パスワードを聞かれるとApacheやnginxで使えないため)
openssl rsa -in newkey.pem -out newkey.pem
04-02. サーバの要求証明書を作成する
以下のコマンドで要求証明書を新規作成する。
openssl req -new -key newkey.pem -out newreq.pem
その後、以下を項目の入力を促されますので、以下の例を参考に値を入力します。
Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Tokyo
Locality Name (eg, city) []:Setagaya
Organization Name (eg, company) [Internet Widgits Pty Ltd]:SSL Test Company
Organizational Unit Name (eg, section) []:Development
Common Name (e.g. server FQDN or YOUR name) []:www.testserver.com ← サーバのFQDNを入力
Email Address []:(メールアドレス)
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
入力完了後、「newreq.pem」ファイルが作成されます。
04-03. 中間認証局を使ってサーバ証明書を発行する
中間認証局でサーバの要求証明書を署名し、サーバ証明書を発行します。
以下のコマンドを入力します。
cd /usr/local/ssl/private
/usr/local/ssl/misc/ICA.sh -sign
すると、中間認証局の秘密鍵のパスワードを聞かれますので入力します。
その後、以下の様な表示になりますので、「y」を選択して署名します。
Using configuration from /usr/local/ssl/openssl_ica.cnf
Enter pass phrase for /usr/local/ssl/ICA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 12558440992105649971 (0xae488b8b7b295733)
Validity
Not Before: Mar 31 10:03:44 2013 GMT
Not After : Mar 30 10:03:44 2016 GMT
Subject:
countryName = JP
stateOrProvinceName = Tokyo
localityName = Setagaya
organizationName = SSL Test Company
organizationalUnitName = Development
commonName = www.testserver.com
emailAddress = (入力したメールアドレス)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Server
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
C0:C8:EB:E9:B1:AD:14:8C:36:2C:E8:AC:07:38:BB:69:1C:25:1F:47
X509v3 Authority Key Identifier:
keyid:1E:9E:D3:F3:68:1F:7E:F6:F9:8E:E2:3D:B1:CB:90:A1:AE:CB:95:BD
Certificate is to be certified until Mar 30 10:03:44 2016 GMT (1095 days)
Sign the certificate? [y/n]:
署名後、「newcert.pem」ファイルが /usr/local/ssl/private ディレクトリへ作成されます。
「newcert.pem」ファイルのままだと利用できないので、
以下のコマンドで余計な情報を排除した CRT ファイルを作成します。
mv /usr/local/ssl/private/newcert.pem /usr/local/ssl/certs
cd /usr/local/ssl/certs
openssl x509 -in newcert.pem -out server.crt
また、秘密鍵も区別しやすいようにファイル名を変更しておきます。
cd /usr/local/ssl/private
mv newkey.pem server.key
これでサーバ証明書の作成は完了です。
ちなみに、証明書の有効期間を変更する場合は
サーバ証明書を署名する中間認証局の設定ファイル(openssl_ica.cnf)にある
default_days の値を変更することで期間を変更できます。
以上で、認証局と証明書の作成については完了です。
次回は作成した証明書をApacheやnginxに設定したり、
ブラウザやOSにインストールする手順を紹介します。
Vol.3へ続く
オレオレ証明書を信頼のおけるSSL証明書にしてみる Vol.1
なんだか今更かと思われる内容ですが、いわゆるSSLのオレオレ証明書を作成する上で中間証明書についてまで詳しく触れているサイトがネット上で少なかったので、(あるにはあるけど、実運用を考えると今ひとつ面倒な手順だったり…)
今更とはいえ敢えて書いてみることにしました。
(個人的解釈も交えているので多少間違っていたら指摘してください)
まずSSL証明書についてですが、いわずとしれたSSL通信を行うために必要な証明書のことです。
このSSL証明書をサーバ上のApacheやnginxなどに設定することで、
SSLによる暗号化通信が行えるようになります。
サーバに設定するSSL証明書は、単に「サーバ証明書」とも呼ばれます。
さて、このサーバへ設定するSSL証明書とはそもそもどういうものなのでしょうか。
一般的にお金を払わないと発行されないものであるけど、オレオレ証明書という自己証明書を作ることもできる。
なら最初からお金も掛からないし自分で作ればよくないか？なんて、思ったことがある人もいるかも知れません。
それを説明するために、SSL証明書がどういうものなのかを説明していきます。
01. SSL証明書は認可制である
そもそもですが、SSL暗号化通信を行う必要がある場面を考えてもらえればわかるかと思います。
暗号化をする必要がある情報は、殆どの場合漏洩するとまずい情報です。
そしてその情報は、例えば個人情報など、漏洩すると利用者に多大な被害を与える可能性のある情報を扱う場面も多くあります。それ故に、その情報を悪質なサイト運営者に悪用される恐れもあるわけで、ある一定の基準をクリアしたサイトでなければSSL暗号化通信を認めさせないようにしよう、という目的や、SSL証明書が発行されているサイトということで信頼性のあるサイトであることを利用者へ証明するといった目的が本来あります。
このサイトを認可し、SSL証明書を発行してくれる世界的に信頼のおける機関を認証局(CA : Certificate Authority)と呼びます。これらの認証局が審査などを行い、SSL証明書を発行してくれるわけです。
02. 信頼のおける認証局が発行してくれる証明書とオレオレ証明書(自己証明書)との違い
さて、認証局というものがあることはわかりましたが、認証局が発行してくれたSSL証明書と自分で発行したオレオレ証明書との違いは何なのでしょうか。オレオレ証明書でもSSL通信は行えますので、敢えて認証局が発行したSSL証明書を使う必要がないようにも思えます。
この違いというのは、オレオレ証明書を作ったことがある人なら誰もが経験していると思いますが、ブラウザでオレオレ証明書を設定したWebサイトへアクセスした場合、「このサイトは信頼されていません」といった警告メッセージが出力されます。つまり、「このサイトは信頼のおける認証局が発行したSSL証明書を使ってないから危険かも知れないよ」と警告してくれるわけです。ECサイトや求人サイトなど、多くのサイトではそんなメッセージを毎回出されて怪しいサイトの烙印を押されてしまったら、たまったものではありませんね。だからお金を出してでもちゃんと信頼のおける認証局に認可してもらったSSL証明書を設定する必要があることがわかるかと思います。
しかし、ここで少し不思議に思った方もいるかと思います。
ブラウザは何を基準にして、信頼のおける認証局が発行したSSL証明書とオレオレ認証局が発行したオレオレ証明書を区別しているのでしょうか。
実はWindowsやMac、携帯電話などの各OSまたはブラウザには予め信頼のおける認証局の証明書情報が設定されており、アクセスしたサイトが利用しているSSL証明書がOSまたはブラウザで設定されている信頼のおける認証局が発行したSSL証明書かどうかを判定することで、これを実現しています。
なので極端な話、その情報をOSまたはブラウザ側から削除をしてしまうと、信頼のおける認証局かどうかを区別できなくなり、実際は信頼のおける認証局が発行した証明書を利用していても「このサイトは信頼されていません」といったメッセージが出力されてしまいます。そしてこれは逆もまた然りで、オレオレ証明書であっても、OSまたはブラウザ側に「信頼のおける証明書」として証明書情報を予めインストールさえしておけば、ブラウザ側で警告メッセージが出力されることはなくなるのです。
03. ブラウザやiPhone等でオレオレ証明書を信頼のおける証明書として設定するためには
そして、ここからが本題になります。
オレオレ証明書のように信頼のおける認証局が発行していない証明書は、
時としてアプリのテストに不都合を生じさせる可能性があります。
例えばiPhoneアプリの場合、信頼されていないSSL証明書が設定されたWebサイトへのSSL通信を行うことが通常できません。
一応プログラム側である値を書き換えると出来るようになるのですが、それを実際にリリースするときまで有効にすることは出来ないし、そもそも信頼のおけるWebサイトへのSSL通信のテストを行ったことにはならないため、非常に困ります。
「iPhoneでSSL通信のテストを行うには、テストサイトにおいて高いお金を払ってまでSSL証明書を発行してもらう必要があるのだろうか？」と思われるかもしれませんが、その必要はありません。
前述のとおり、オレオレ証明書を「信頼のおける認証局が発行した証明書」として設定してしまえばいいのです。
具体的には、オレオレ証明書を発行した「オレオレ認証局」の証明書をブラウザや携帯電話に設定する必要があります。
04. ルート認証局と中間認証局について
実際にオレオレ認証局の作成方法を説明する前に、認証局の仕組みについてもう少し詳しく説明したいと思います。
認証局は、実は複数ある場合があり、多くの信頼のおける機関の認証局が発行してくれる証明書は複数の認証局から署名されたSSL証明書になっています。
これはどういうことなのかというと、会社の組織に例えるとわかりやすいかと思います。
会社の一番上には社長がいて、その社長の下には部長、課長、係長などがいます。
社長が認めた部長がいて、部長が認めた課長がいて、課長が認めた係長がいて、その下に一般社員がいるようなイメージです。SSL証明書はこの一般社員に当たるもので、その他の社長、部長、課長、係長は全て認証局に当たります。
つまりどういうことなのかと言いますと、認証局自体も認可制になっているということなのです。
親玉の社長だけに認められたとしても、賄賂や美人局など何か姑息な手段で取り入った可能性もあります (笑)
そのため、部長や課長、係長といった複数人にも認められなければ信頼のおける出世コースの花道に乗れる一般社員とはなれないわけです。
上記の例でいうと、社長にあたる認証局を「ルート認証局 (RCA : Root Certificate Authority)」と呼び、部長・課長・係長を「中間認証局 (ICA : Intermediate Certificate Authority)」と呼びます。
中間認証局は別になくても良いのですが、
中間認証局を設けることでより信頼性を向上させることが可能になります。
また、お金を払って買えるSSL証明書の殆どが複数の中間認証局に署名されているということを考えると、実際のWebサービスをリリースする際には、中間認証局のあるSSL証明書を設定することになります。
そのため、本番環境とテスト環境とのApache or nginxの設定差分を出来るだけ少なくするためにも、中間認証局ありでオレオレ証明書を作ることをオススメします。
というわけで、SSL証明書の前提知識については以上になります。
次は実際の作成方法の説明に行こうかと思ったのですが、
思ったよりも説明が長くなってしまったので、また次回へ続きます。
＜最後に用語整理＞
「証明書」
読んで字のごとく何かを証明するもの。
SSL通信で意識する必要があるのは
「認証局を区別するための証明書」
「サーバを区別するための証明書 (＝サーバ証明書)」
の２つになる。
「SSL証明書」
SSL通信を行うWebサイトのサーバに設定する証明書。
サーバ証明書とも言う。
「認証局」
SSL証明書を発行する実体。
認証局は階層的に存在する。
その大元をルート認証局と呼び、その下に続く認証局を中間認証局と呼ぶ。
「自己証明書」
信頼のおける機関の認証局ではなく、
自分で作成した自己認証局にて発行した証明書を自己証明書と呼ぶ。
また、誰が最初に言い出したのかは知らないが俗に「オレオレ証明書」とも呼ばれ、
そのオレオレ証明書を発行する認証局を「オレオレ認証局」とも呼ぶ。
Vol.2へ続く
今更とはいえ敢えて書いてみることにしました。
(個人的解釈も交えているので多少間違っていたら指摘してください)
まずSSL証明書についてですが、いわずとしれたSSL通信を行うために必要な証明書のことです。
このSSL証明書をサーバ上のApacheやnginxなどに設定することで、
SSLによる暗号化通信が行えるようになります。
サーバに設定するSSL証明書は、単に「サーバ証明書」とも呼ばれます。
さて、このサーバへ設定するSSL証明書とはそもそもどういうものなのでしょうか。
一般的にお金を払わないと発行されないものであるけど、オレオレ証明書という自己証明書を作ることもできる。
なら最初からお金も掛からないし自分で作ればよくないか？なんて、思ったことがある人もいるかも知れません。
それを説明するために、SSL証明書がどういうものなのかを説明していきます。
01. SSL証明書は認可制である
そもそもですが、SSL暗号化通信を行う必要がある場面を考えてもらえればわかるかと思います。
暗号化をする必要がある情報は、殆どの場合漏洩するとまずい情報です。
そしてその情報は、例えば個人情報など、漏洩すると利用者に多大な被害を与える可能性のある情報を扱う場面も多くあります。それ故に、その情報を悪質なサイト運営者に悪用される恐れもあるわけで、ある一定の基準をクリアしたサイトでなければSSL暗号化通信を認めさせないようにしよう、という目的や、SSL証明書が発行されているサイトということで信頼性のあるサイトであることを利用者へ証明するといった目的が本来あります。
このサイトを認可し、SSL証明書を発行してくれる世界的に信頼のおける機関を認証局(CA : Certificate Authority)と呼びます。これらの認証局が審査などを行い、SSL証明書を発行してくれるわけです。
02. 信頼のおける認証局が発行してくれる証明書とオレオレ証明書(自己証明書)との違い
さて、認証局というものがあることはわかりましたが、認証局が発行してくれたSSL証明書と自分で発行したオレオレ証明書との違いは何なのでしょうか。オレオレ証明書でもSSL通信は行えますので、敢えて認証局が発行したSSL証明書を使う必要がないようにも思えます。
この違いというのは、オレオレ証明書を作ったことがある人なら誰もが経験していると思いますが、ブラウザでオレオレ証明書を設定したWebサイトへアクセスした場合、「このサイトは信頼されていません」といった警告メッセージが出力されます。つまり、「このサイトは信頼のおける認証局が発行したSSL証明書を使ってないから危険かも知れないよ」と警告してくれるわけです。ECサイトや求人サイトなど、多くのサイトではそんなメッセージを毎回出されて怪しいサイトの烙印を押されてしまったら、たまったものではありませんね。だからお金を出してでもちゃんと信頼のおける認証局に認可してもらったSSL証明書を設定する必要があることがわかるかと思います。
しかし、ここで少し不思議に思った方もいるかと思います。
ブラウザは何を基準にして、信頼のおける認証局が発行したSSL証明書とオレオレ認証局が発行したオレオレ証明書を区別しているのでしょうか。
実はWindowsやMac、携帯電話などの各OSまたはブラウザには予め信頼のおける認証局の証明書情報が設定されており、アクセスしたサイトが利用しているSSL証明書がOSまたはブラウザで設定されている信頼のおける認証局が発行したSSL証明書かどうかを判定することで、これを実現しています。
なので極端な話、その情報をOSまたはブラウザ側から削除をしてしまうと、信頼のおける認証局かどうかを区別できなくなり、実際は信頼のおける認証局が発行した証明書を利用していても「このサイトは信頼されていません」といったメッセージが出力されてしまいます。そしてこれは逆もまた然りで、オレオレ証明書であっても、OSまたはブラウザ側に「信頼のおける証明書」として証明書情報を予めインストールさえしておけば、ブラウザ側で警告メッセージが出力されることはなくなるのです。
03. ブラウザやiPhone等でオレオレ証明書を信頼のおける証明書として設定するためには
そして、ここからが本題になります。
オレオレ証明書のように信頼のおける認証局が発行していない証明書は、
時としてアプリのテストに不都合を生じさせる可能性があります。
例えばiPhoneアプリの場合、信頼されていないSSL証明書が設定されたWebサイトへのSSL通信を行うことが通常できません。
一応プログラム側である値を書き換えると出来るようになるのですが、それを実際にリリースするときまで有効にすることは出来ないし、そもそも信頼のおけるWebサイトへのSSL通信のテストを行ったことにはならないため、非常に困ります。
「iPhoneでSSL通信のテストを行うには、テストサイトにおいて高いお金を払ってまでSSL証明書を発行してもらう必要があるのだろうか？」と思われるかもしれませんが、その必要はありません。
前述のとおり、オレオレ証明書を「信頼のおける認証局が発行した証明書」として設定してしまえばいいのです。
具体的には、オレオレ証明書を発行した「オレオレ認証局」の証明書をブラウザや携帯電話に設定する必要があります。
04. ルート認証局と中間認証局について
実際にオレオレ認証局の作成方法を説明する前に、認証局の仕組みについてもう少し詳しく説明したいと思います。
認証局は、実は複数ある場合があり、多くの信頼のおける機関の認証局が発行してくれる証明書は複数の認証局から署名されたSSL証明書になっています。
これはどういうことなのかというと、会社の組織に例えるとわかりやすいかと思います。
会社の一番上には社長がいて、その社長の下には部長、課長、係長などがいます。
社長が認めた部長がいて、部長が認めた課長がいて、課長が認めた係長がいて、その下に一般社員がいるようなイメージです。SSL証明書はこの一般社員に当たるもので、その他の社長、部長、課長、係長は全て認証局に当たります。
つまりどういうことなのかと言いますと、認証局自体も認可制になっているということなのです。
親玉の社長だけに認められたとしても、賄賂や美人局など何か姑息な手段で取り入った可能性もあります (笑)
そのため、部長や課長、係長といった複数人にも認められなければ信頼のおける出世コースの花道に乗れる一般社員とはなれないわけです。
上記の例でいうと、社長にあたる認証局を「ルート認証局 (RCA : Root Certificate Authority)」と呼び、部長・課長・係長を「中間認証局 (ICA : Intermediate Certificate Authority)」と呼びます。
中間認証局は別になくても良いのですが、
中間認証局を設けることでより信頼性を向上させることが可能になります。
また、お金を払って買えるSSL証明書の殆どが複数の中間認証局に署名されているということを考えると、実際のWebサービスをリリースする際には、中間認証局のあるSSL証明書を設定することになります。
そのため、本番環境とテスト環境とのApache or nginxの設定差分を出来るだけ少なくするためにも、中間認証局ありでオレオレ証明書を作ることをオススメします。
というわけで、SSL証明書の前提知識については以上になります。
次は実際の作成方法の説明に行こうかと思ったのですが、
思ったよりも説明が長くなってしまったので、また次回へ続きます。
＜最後に用語整理＞
「証明書」
読んで字のごとく何かを証明するもの。
SSL通信で意識する必要があるのは
「認証局を区別するための証明書」
「サーバを区別するための証明書 (＝サーバ証明書)」
の２つになる。
「SSL証明書」
SSL通信を行うWebサイトのサーバに設定する証明書。
サーバ証明書とも言う。
「認証局」
SSL証明書を発行する実体。
認証局は階層的に存在する。
その大元をルート認証局と呼び、その下に続く認証局を中間認証局と呼ぶ。
「自己証明書」
信頼のおける機関の認証局ではなく、
自分で作成した自己認証局にて発行した証明書を自己証明書と呼ぶ。
また、誰が最初に言い出したのかは知らないが俗に「オレオレ証明書」とも呼ばれ、
そのオレオレ証明書を発行する認証局を「オレオレ認証局」とも呼ぶ。
Vol.2へ続く
- プロフィール
Author:Kou
モバイル関連の開発ばかりやってる人のブログです。たまにWebもやります。
- ＱＲコード
