まだプログラマーですが何か？

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

タグ：apache

Apache HTTPD でバーチャルホストを使う設定手順の紹介です。一応 CentOS 6 環境を前提としますが、多くのケースで他の環境にも応用できる情報だと思っています。


バーチャルホストは、１つのウェブサーバー(Apache HTTPD)で複数のウェブサイトを運用するものです。　「複数のウェブサイト」の考え方ですが、例えば以下の例のようにディレクトリ単位で分けるのであればバーチャルホストを使わなくても１つのウェブサーバーで（ドキュメントルート以下のディレクトリを分けるだけで）運用できます：
　http://www.xxxxxx.com/host1/　　（ホスト１）
　http://www.xxxxxx.com/host2/　　（ホスト２）
　http://www.xxxxxx.com/host3/　　（ホスト３）

でも以下のような、ディレクトリの違いではなく、ホスト名やサブドメインの違いによる複数のウェブサイトを１台のウェブサーバーで運用するにはバーチャルホストの設定が必要です：
　http://www1.xxxxxx.com/　　（ホスト１）
　http://www2.xxxxxx.com/　　（ホスト２）
　http://www3.xxxxxx.com/　　（ホスト３）

上記のようなケースでのバーチャルホストの設定方法を紹介します。なお、前提条件として以下のような条件とします：
(1) DNS は設定済み（www1.xxxxxx.com, www2.xxxxxx.com, www3.xxxxxx.com いずれにも同じ IP アドレスが設定されていて、これらの名前全てでバーチャルホストを設定するマシンが参照できる）
(2) ユーザーが http://www1.xxxxxx.com/ にアクセスしてきたらドキュメントルート１(/var/www/html/vh1/)以下に誘導する
(3) ユーザーが http://www2.xxxxxx.com/ にアクセスしてきたらドキュメントルート２(/var/www/html/vh2/)以下に誘導する
(4) ユーザーが http://www3.xxxxxx.com/ にアクセスしてきたらドキュメントルート３(/var/www/html/vh3/)以下に誘導する
(5) ユーザーが IP アドレスなど上記以外の名前で http アクセスを行ってきたらエラーとする（ホスト名でしか参照できなくする）


まず最初に (1) の名前解決についての設定をしておきます。本当にドメイン（ここでは xxxxxx.com としますが、他のドメインの場合は読み替えてください）やグローバルIPアドレスを取得していて、www1.xxxxxx.com / www2.xxxxxx.com / www3.xxxxxx.com いずれも世界中から参照できる IP アドレスに結びつけることができるよう DNS 設定が可能な場合はそのように設定しておいてください。　一方、実際にはドメインを取得しておらず（或いは取得しているドメインは使わず）あくまでテスト目的でバーチャルホスト環境を構築するのであれば、/etc/hosts ファイルを編集して以下の赤字部分を追記します：
127.0.0.1      localhost localhost.localdomain www1.xxxxxx.com www2.xxxxxx.com www3.xxxxxx.com

この赤字部分を追記することで、とりあえずこのマシン上からは www1.xxxxxx.com / www2.xxxxxx.com / www3.xxxxxx.com いずれの名前でも 127.0.0.1 に結びつきました。つまり、このマシン上からは www1.xxxxxx.com / www2.xxxxxx.com / www3.xxxxxx.com の名前でアクセスできる環境が整いました。このマシン以外からの動作確認を行う場合は 127.0.0.1 ではなく、実際の IP アドレスに紐付けるように hosts ファイルを編集してください。


名前解決の準備ができたら Apache HTTPD サーバーをインストールします。CentOS であれば以下のコマンドでインストールできます：
# yum install httpd

ではここからバーチャルホストの設定を行います。まずは３つの運用ホストそれぞれに対応するドキュメントルートディレクトリを作成しておきましょう：
# mkdir /var/www/html/vh1
# mkdir /var/www/html/vh2
# mkdir /var/www/html/vh3

次に Apache HTTPD サーバーの設定ファイルをカスタマイズします。/etc/httpd/conf/httpd.conf を編集して、サーバー名の指定があればコメントし、またバーチャルホストの有効化を指定します：
  :
#ServerName xxxxxx.com:80  ←ServerName をコメント
  :
  :
  :
NameVirtualHost *:80  ←NameVirtualHost のコメントを外してバーチャルホスト有効化
  :

そして各ホストや設定内容に合わせた設定ファイルを追加していきます。上記の設定 (2) を実現するための設定ファイルを /etc/httpd/conf.d/virtualhost-vh1.xxxxxx.com.conf として作成（新規追加）します。内容は以下のようにします：
（/etc/httpd/conf.d/virtualhost-vh1.xxxxxx.com.conf）
<VirtualHost *:80%>
  ServerName www1.xxxxxx.com
  DocumentRoot /var/www/html/vh1
  ErrorLog logs/vh1-error_log
  CustomLog logs/vh1-access_log combined env=!no_log
</VirtualHost>

この中で http://www1.xxxxxx.com/ でアクセスがあった場合のドキュメントルートが /var/www/html/vh1 であることや、HTTPD のエラーログ／アクセスログのファイル名を指定しています。

同様にして、上記設定 (3), (4) のための設定ファイルを /etc/httpd/conf.d/virtualhost-vh2.xxxxxx.com.conf と /etc/httpd/conf.d/virtualhost-vh3.xxxxxx.com.conf をそれぞれ以下の内容で新規に作成します：

（/etc/httpd/conf.d/virtualhost-vh2.xxxxxx.com.conf）
<VirtualHost *:80%>
  ServerName www2.xxxxxx.com
  DocumentRoot /var/www/html/vh2
  ErrorLog logs/vh2-error_log
  CustomLog logs/vh2-access_log combined env=!no_log
</VirtualHost>
（/etc/httpd/conf.d/virtualhost-vh3.xxxxxx.com.conf）
<VirtualHost *:80%>
  ServerName www3.xxxxxx.com
  DocumentRoot /var/www/html/vh3
  ErrorLog logs/vh3-error_log
  CustomLog logs/vh3-access_log combined env=!no_log
</VirtualHost>

最後に上記設定 (5) のための設定ファイルを追加します。ここではサーバー名でのアクセスがあった場合のみ適合するドキュメントルートを参照させていますが、IP アドレスを指定してアクセスがあった場合はエラーとするように決めています。その内容を設定するために以下の内容で /etc/httpd/conf.d/virtualhost-00.conf ファイルを新規に作成します：
（/etc/httpd/conf.d/virtualhost-00.conf）
<VirtualHost *:80%>
  ServerName any
  <Location>
    Order deny,all
    Deny from all
  </Location>
</VirtualHost>

これで設定準備そのものは完了です。最後の準備として動作確認用に３つのドキュメントルートそれぞれに簡単な index.html ファイルを作成して、バーチャルホストが有効になっていることががテスト時に分かるようにします：
# echo "VirtualHost 1" > /var/www/html/vh1/index.html

# echo "VirtualHost 2" > /var/www/html/vh2/index.html

# echo "VirtualHost 3" > /var/www/html/vh3/index.html

これで目的のバーチャルホストを実現するための準備は完了です。最後に Apache HTTPD を再起動して、この準備内容を反映させます：
# /etc/init.d/httpd restart

動作確認は（ホスト名で区別するので） www1.xxxxxx.com / www2.xxxxxx.com / www3.xxxxxx.com の名前でこのホストの IP アドレスが引ける環境から行う必要があります。上記のように /etc/hosts の 127.0.0.1 で設定したのであれば Apache HTTPD サーバーと同じマシンからブラウザを起動して行います。

まずは http://www1.xxxxxx.com/ の場合。ちゃんと期待通りの内容が表示できてます：
2014120901


同様にして http://www2.xxxxxx.com/ や http://www3.xxxxxx.com/ の場合もそれぞれ正しいドキュメントルートを参照できているはずです：
2014120902

2014120903


最後に http://localhost/　（或いはhttp://IPアドレス） でアクセスしてみます。localhost で HTTPD サーバーが動いていることは間違いないのですが、ホスト名で指定されていないので（上記 (5) の設定が有効になっているので）エラー扱いとなるはずです：
2014120904


バーチャルホスト（とDNS）をうまく使うと、負荷やリソースとの兼ね合いもありますが、１台のサーバーで複数の HTTP ホストを運用できて便利です。


 
タグ ：
#centos
#apache
#httpd
#virtualhost

以前にこの記事を書きました：
CentOS に Apache Tomcat を導入する


上記ページの下の方で、Apache Tomcat を（一般的な HTTP のポートである）80 番ポートで実行するための指定方法も書き加えています。簡単に言うと、Apache Tomcat 自体は 8080 番ポートで動かしながら 80 番ポートへのリクエストを 8080 番に転送することで、外部からは 80 番ポートで動いているように見せる、というものでした。

もちろんこの方法は今でも有効で、比較的簡単に Apache Tomcat を 80 番ポートで動かすことができるようになります。ただ１つ、「事実上 80 番ポートを専有してしまう」という難点もあります。つまり実際には 8080 番ポートでしか動いていないのに、80 番ポートも含めて専有してしまうということです。

この結果、どんな不都合があるでしょう？　例えば Apache Tomcat が 8080 番ポートのままであれば、同じシステムに Apache HTTPD を導入して 80 番ポートで平行して動かすことができます。例えば PHP と MySQL と WordPress まで導入した上で、80 番ポートでは Apache HTTPD で WordPress を動かし、8080 番ポートでは Apache Tomcat で Java アプリケーションサーバーを同時に動かす、ということが可能でした。　上記の 80 番ポートを 8080 番ポートに転送するという方法を取ってしまうと、80 番ポートで Apache HTTPD を動かすことができなくなってしまいます。つまり２つの HTTP サーバーを同時に動かすことはできなくなってしまいます。

とはいえ、Apache Tomcat が 8080 番ポートのままですと、Java アプリケーションサーバーにアクセスさせるには
　　http://xxx.xxx.xxx:8080/hello
という、一般的とは言えないちょっと冗長な URL をユーザーに指定させる必要が出てきます。普通の HTTP（80番）リクエストが許可されていない環境は珍しいかもしれませんが、8080 番ポートとなると会社レベルのファイアウォールが許可していない可能性も出てきます。


これを解決する方法もあります。例えば WordPress が
　http://xxx.xxx.xxx/wordpress
という URL で動いていて、同時に Java アプリケーションが
　http://xxx.xxx.xxx:8080/hello
という URL で動いている場合であれば、以下の様なルールを作ります：

・原則的には、全てのリクエストを Apache HTTPD （80番ポート）で処理する
・但し /hello という URL パターンだった場合のみ、Apache Tomcat に渡して処理してもらう

これにより、http://xxx.xxx.xxx/hello というリクエストがあった場合には内部的に http://xxx.xxx.xxx:8080/hello に転送※して Apache Tomcat 側で処理をする、という作業分担が可能になります。　また同時に全てのリクエストをパフォーマンスのいい Apache HTTPD がいったん処理した上で分担処理することになるとか、サーバーのファイアウォールは 80 番ポートのみ開けておけばよくなる（Apache Tomcat の 8080 番ポートと停止することもできる）、という副次的なメリットも生まれます。

※実際には 8080 番ではなく、内部的な処理をするために 8009 番ポートを使います


この作業分担を実現するのが Apache Tomcat に付属している AJP(Apache Java Protocol) です。AJP は 8009 番ポートを使います。

具体的な作業の前に Apache Tomcat の設定を元に戻しておきます。つまり上記リンク先のような 80 番ポートへのリクエストを 8080 番ポートに転送するような指定がされている場合は無効にして、普通に Apache Tomcat が 8080 番ポートで動いているような状態にします。

続いて /etc/httpd/conf.d/proxy_ajp.conf というファイルを、以下の内容で作成します：
ProxyPass /hello/ ajp://localhost:8009/hello/

これで Apache HTTPD を再起動（# /etc/init.d/httpd restart）します。すると 80 番ポートへのリクエストは Apache HTTPD が受けるのですが、この AJP の設定により /hello/ というパスへのリクエストに関しては 8009 番ポートへの /hello/ に変換されます。そして内部的な 8009 番ポートで待ち構えている Apache Tomcat の AJP によって処理されるようになります。

結果的に、ユーザーからは WordPress へは
　　http://xxx.xxx.xxx/wordpress/
Java アプリケーションへは
　　http://xxx.xxx.xxx/hello/
それぞれの URL で利用できるようになる、ということです。

なお、この記述をすることで Apache Tomcat を 8080 番ポートで動かす必要はなくなります。消してしまうのであれば Apache Tomcat の server.xml から該当箇所を削除してください。


注意点としては、Java アプリケーションへの転送を proxy_ajp.conf で記述することになるため、複数の Java アプリケーションがあって、その全てを転送したいのであれば、全てを proxy_ajp.conf に（複数行で）記述する必要が出てきます。

もう１点、実は私自身はこの AJP をあまり信用していないというか、AJP コンテナ自身がそれほどでもない負荷を捌ききれなかった経験をしています。原因調査についてはこちらの記事を参考にしていますが、AJP を使う前提での根本解決はできていないので、ちとヤな感じではあります：
http://m97087yh.seesaa.net/article/212767022.html









 
タグ ：
#apache
#httpd
#tomcat
#ajp

Apache jMeter を使ったウェブサイトの負荷テストの手順を一通り紹介します。


今回の紹介するシナリオでは、以下の目的および前提でテストを行います：
(1) ウェブサイトは（一応）完成している
(2) ユーザーの想定挙動（「トップページを見て、検索をして、検索結果ページをいくつか閲覧して、・・」という導線）は決まっている
(3) １つのページあたりのユーザーレスポンスタイム（ユーザーがそのページを開き始めてから反応が返り切るまでの時間）を３秒以内にしたい
(4) この条件で、１秒あたりに何ユーザーのアクセスまで耐えられるシステムなのかを測定したい

アプリケーションのテストには色々な種類がありますが、今回は上記のように「どれだけのユーザーアクセスにまでは耐えうるシステムなのか」を検証するテストを行います。そしてそのようなテストではこの Apache jMeter は便利です。


まずは Apache jMeter をインストールします。jMeter は Pure Java アプリケーションのため、前提として Java の実行環境が必要になります。JRE または JDK を導入して、実行可能な状態にしておいてください。その上で公式サイトから Apache jMeter の最新版バイナリをダウンロードし、展開します。展開後、jMeter の起動ファイル（Windows であれば bin/jmeter.bat）を実行して、jMeter を起動します：
2014102701


次に、このテスト計画にスレッドグループを追加するのですが、その前に今回のテスト目的をおさらいします。一覧のページビューにおいて、そのユーザーレスポンスタイムを３秒（この数字は変更しても構いません）以内にする前提で、１秒あたりに何ユーザーのアクセスまで耐えられるシステムなのかを測定したい、というものでした。　

というわけで、今回のテストでは、あるユーザーシナリオを元に、最初は１ユーザーで実行、次に２ユーザー同時に実行、その次は３ユーザー同時に、、、、と少しずつユーザー数を増やしていきながら、（例えば）２０ユーザー同時にアクセスするところまでを実行して、それぞれのページビューアクションでのレスポンスタイムを計測する、という流れになります。そして（今回の場合であれば）３秒以内のレスポンスを期待できるのは何ユーザー程度の同時アクセスまでか、を調べることになります。

つまり今回のテストでは最初は１ユーザーでアクセスし、１分後に１ユーザー増やして２ユーザーでアクセス、更に１分後に１ユーザー増やして３ユーザーでアクセス、、、といった具合に１分ごとにユーザー数（ユーザースレッド）を増やして負荷を加えていきます。そして開始から１９分後に２０ユーザーでの同時アクセスとなり、ここでのレスポンスタイムを計測して終了、というテストを行います。　なお、１ユーザー増やすタイミングを１分後にする必要はありませんが、後から結果を確認しやすい（開始から何分経過したかで何ユーザーでのアクセスかを推測できる）のでこのようなテストシナリオにしています。

ではこのテストシナリオに従ってスレッドグループを定義します。jMeter の「テスト計画」と書かれた箇所を右クリックして、　追加 > Threads(Users) > スレッドグループ　を選択します：
2014102702


テスト契約の下にスレッドグループが追加されます。これをクリックして選択し、以下の内容を入力します：
　スレッド数: 20
　Ramp-Up期間（秒）: 1200
　ループ回数: 無限ループ
2014102703


スレッド数はユーザー数です、なので20。Ramp-Up はこの20スレッドをどれだけの時間かけて生成するか、という期間の数字です。今回は１分毎に１スレッドずつ、20スレッドまで増やしていくので 60 x 20 = 1200（秒）を指定します。そして各スレッドは無限に処理を繰り返し実行してほしいので、ループ回数は「無限ループ」を指定しています。

次に、各ユーザースレッドで実行する内容を定義します。「スレッドグループ」を右クリックして、　追加 > サンプラー > HTTPリクエスト　を選択します。
2014102704


HTTP リクエストが追加されたら、その中身を実際のテストシナリオに合わせて変更します：
　名前：　何のアクションが分かる名前に変更（どのアクションに時間がかかっているのかを区別できるように）
　サーバー名：　テスト先アプリケーションサーバー
　ポート番号：　テスト先アプリケーションサーバーのポート番号（80の場合は省略可）
　パス：　アクセスする URL のサーバー名以降の部分
2014102705


HTTP リクエスト１つがユーザーの１回のアクセスを定義します。「このページを見て、次にこのページを見て、その次にこのページを見て、・・」のように複数のページを巡回するシナリオで計測する場合は、必要なだけこの HTTP リクエストをスレッドグループに追加していきます。この例では４つのページを巡回するシナリオを定義しています：
2014102706


テストシナリオの定義はこれで終わりです。最後に結果を一覧表で確認できるようにします。スレッドグループを右クリックして　追加 > リスナー > 結果を表で表示　を選択します：
2014102708


これで最小限必要な設定ができたので、メニューから　ファイル > テスト計画を保存　を選択して、このテスト計画を保存します。

テストの実行はメニューから　実行 > 開始　を選択するだけです。実行中に「結果を表で表示」をクリックすると、次々に実行されるテストの結果を参照することができます：
2014102707

この "Sample Time(ms)" 列が各アクションのレスポンスタイムになります。スレッドが増えていった時にこの数値がどのように増えていくのかを参照することで（今回の例であれば３秒以内に収まっているかどうかを確認することで「どの程度の同時アクセス数までは期待通りのパフォーマンスを維持できているか」を調査していくことになります。












 
タグ ：
#apache
#jmeter
#test
#load
#workload

CentOS に Java アプリケーションサーバーである Apache Tomcat を導入します。
2014062601



手順としては、まず Java(JDK) をインストールし、その後で Tomcat を導入します。


Java(JDK) のインストール

Oracle Java でも Open Java でもいいのですが、ここでは簡単な後者の手順を紹介します。Java 7 であればこのコマンドで JDK が導入できます：
# yum install java-1.7.0-openjdk-devel

あるいは Java 実行環境だけでもよければこちら： 
# yum install java-1.7.0-openjdk

これだけ。


Apache Tomcat のインストール

Apache Tomcat も yum で導入できます。インストールと、起動と、自動起動設定までを行っています：
# yum install tomcat6 tomcat6-webapps tomcat6-admin-webapps
# /etc/init.d/tomcat6 start
# chkconfig tomcat6 on

ちなみにこの方法で導入すると Apache Tomcat 6 が /var/lib/tomcat6/ 以下にインストールされます。

起動後（/etc/init.d/tomcat6 start 実行後）にブラウザで http://（サーバーアドレス）:8080/ にアクセスすると Tomcat のデフォルトトップ画面が表示され、正しく導入・動作できていることが確認できます：
2014062701



Apache Tomcat の設定

設定ファイルを書き換えて管理用画面にもアクセスできるようにします：
# vi /etc/tomcat6/tomcat-users.xml

（以下を </tomcat-users> の直前に追加）
  <role rolename="manager"/>
  <user name="admin" password="（管理者用パスワード）" roles="manager"/> 

そして Tomcat サーバーを再起動します：
# /etc/init.d/tomcat6 restart

これで管理用画面のURL である http://（サーバーアドレス）:8080/manager/html にもアクセスできるようになりました。ログイン時の ID とパスワードは上記 tomcat-users.xml で指定したものです：
2014062702




（おまけ）Apache Tomcat を 80 番ポートで起動する

まず設定ファイルを書き換えます。server.xml に proxyPort の部分を追加します：
# vi /etc/tomcat6/server.xml

    :
  <Connector port="8080" protocol="HTTP/1.1"
        connectionTimeout="20000"
        redirectPort="8443"
        proxyPort="80" />
    :

そして iptable で 80 番ポートへのリクエストを 8080 番に転送し、この設定ルールを iptables に保存します：
# iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
# /sbin/service iptables save



これで Tomcat を再起動すると、Tomcat に 8080 番ポートではなく、 80 番ポートでアクセスできるようになります。
 
タグ ：
#centos
#apache
#tomcat
#java

CentOS 環境設定備忘録シリーズ（？）、今回は Apache HTTPD の巻。
CentOS の導入は済んでいるものとします。詳しい手順はこちらを参照。

Apache HTTPD の導入自体は簡単すぎるので、今回は SSL アクセスを有効にするところまでを紹介、オレオレ SSL だけど。

まずはターミナルを開いて、 Apache HTTPD をサクっとインストール：
# yum install httpd

これで完了、簡単すぎ。後は実行すれば HTTPD サーバーとして使えるけど、その前に SSL の設定も紹介します。


SSL(Secure Sockets Layer) 情報を暗号化して送受信するプロトコル。これを HTTP で使う場合のプロトコルが HTTPS です。個人情報やクレジットカード情報を送受信する場合、その中身を暗号化して途中経路で読めなくする場合などに使います。利用者のレベルでは HTTP や HTTPS の違いをほとんど意識することはありません。

一方、サーバー側には SSL の鍵や証明書を使うことでこの暗号化を実現します。単にサーバーそのものを SSL 対応することに加え、この鍵や証明書を用意しておく必要があります。商用サイトであれば専門の機関から有償で発行してもらうもののですが、検証目的であれば OpenSSL を使って自分で（無償で）用意することもできます。

余談ですが、自分で用意した場合は自分の作った証明書で自分を信じこませて認証する、という意味で「オレオレ SSL」とか「オレオレ証明書」とか言われます。いずれこれらも「母さん、助けてSSL」とかって呼ばれるようになるんでしょうかね（笑）。

で、その自分で SSL を有効にするまでの手順も紹介します。まずは OpenSSL と、Apache HTTPD に SSL 機能を付けるための mod_ssl モジュールを導入します（既に導入済みかもしれません、その場合は気にせず先に進んでください）：
# yum install openssl
# yum install mod_ssl

まずはオレオレ証明書を作ります。その前提として秘密鍵と公開鍵のペアが必要なので、順序としては (1)秘密鍵を作って、(2)公開鍵を作って、(3)証明書を作る　という流れになります。この順に説明します。なお以下ではこれらのファイルを /etc/httpd/conf/ 以下に作成する前提で進めますが、別ディレクトリでも構いません。その場合は適宜読み替えてください。

最初に /etc/httpd/conf に移って、(1)秘密鍵を server.key というファイル名で作成します：
# cd /etc/httpd/conf
# openssl genrsa -aes128 1024 > server.key

Generating RSA private key, 1024 bit long modulus
..................++++++
..........................................++++++
e is 65537 (0x10001)
Enter pass phrase:（パスフレーズ）
Verifying - Enter pass phrase:（同じパスフレーズ）

この例では 128 ビットの AES 方式で暗号化した 1024 ビットの秘密鍵を作っています。途中でパスフレーズ（パスワード）を聞かれるので適当なパスワードを指定し、直後に確認のため同じパスワードを入力します。これで秘密鍵が完成です。

次にこの秘密鍵ファイルとペアになる (2)公開鍵ファイルを server.csr というファイル名で作成します：
# openssl req -new -key server.key > 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]:Chiba
Locality Name (eg, city) []:Funabashi
Organization Name (eg, company) [Internet Widgits Pty Ltd]:空白
Organizational Unit Name (eg, section) []:空白
Common Name (eg, YOUR name) []:192.168.XXX.XXX
Email Address []:空白

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:空白
An optional company name []:空白

２文字の国識別コードには JP を指定、都道府県、市区町村を指定、それ以外は Common Name 欄以外は空白のままで大丈夫です。
注意点として、Common Name には実際に HTTPS として運用する際にブラウザから指定するアドレスを入力することになります。 https://www.xxx.com/ といったサーバー名でアクセスするのであれば xxx.com を、https://192.168.XXX.XXX/ といった IP アドレスでアクセスするのであれば IP アドレスを指定してください。

最後にこの秘密鍵と公開鍵を使って (3)証明書ファイルを server.crt というファイル名で作成します：
# openssl x509 -in server.csr -days 36500 -req -signkey server.key > server.crt
Signature ok
subject=/C=JP/ST=Chiba/L=Funabashi/O=Default Company Ltd/CN=192.168.XXX.XXX
Getting Private key
Enter pass phrase for server.key:（上記で指定したパスフレーズ）


この場合では X.509 形式の証明書ファイルを、有効期間36500日（約100年）の指定で作成しています。これだけ指定しておけば自分の開発期間中はまあ大丈夫でしょうｗ。


これでデジタル証明書の作成までできましたが、このまま使うと Apache HTTPD の起動時にパスフレーズの入力を求められることになります。開発期間中はそれでもいいのかもしれませんが、実際の運用はサーバーの起動と同時に HTTPD サーバーも起動させたりするので、ここまでの作業が完了していればパスフレーズは不要と言えます。パスフレーズは以下のコマンドで解除することができるので、一応紹介しておきます：
# mv server.key server.key.bak
# openssl rsa -in server.key.bak > server.key
Enter pass phrase for server.key.back:パスフレーズ
writing RSA key

デジタル鍵／証明書が用意できたので、実際にこれを使って HTTPS を構築します。mod_ssl をインストールしたタイミングで /etc/httpd/conf.d/ssl.conf が作られているはずなので、このファイルを編集して今作成したこれらのファイルを指定します：
# vi /etc/httpd/conf.d/ssl.conf

  :
<VirtualHost _default_:443>
  ErrorLog logs/ssl_error_log
  TransferLog logs/ssl_access_log
  LogLevel warn
  SSLEngine on
  SSLProtocol all -SSLv2
  SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
  SSLCertificateFile /etc/httpd/conf/server.crt
  SSLCertificateKeyFile /etc/httpd/conf/server.key
  <Files ~ "\.(cgi|shtml|phtml|php3?)$">
    :
  </Files>
</VirtualHost>

これで準備は整いました。では HTTP(S) サーバーを起動します：
# /etc/init.d/httpd start

起動後、ウェブブラウザを使ってこのサーバーにアクセスしてみます。まずは普通に http://XXX.XXX.XXX.XXX でアクセス。特に何もしていなければ Apache HTTPD のデフォルトページが表示されるはずです：
2014020801


次に同じアドレスに対して https://XXX.XXX.XXX.XXX でアクセスを試みます。SSL でのアクセスになります。証明書がオレオレなので、「信頼できないよ（第三者が保証するものではないよ）」と警告されます。
2014020802


ブラウザによってこの後の承認方法が異なりますが、Chrome であれば「このまま続行」ボタン、FireFox であれば「危険性を理解した上で接続するには」 - 「例外を追加」 - 「セキュリティ例外を承認」 を順に選択することで先に進むことができて、本来のトップページが HTTPS プロトコルで見ることができます。
2014020803
タグ ：
#centos
#httpd
#apache
#ssl

このページのトップヘ