システム奮闘記：その64
LinuxとApacheでSSL通信の設定
(2007年12月13日に掲載)
はじめに
SSLといえば、Webサーバーとブラウザ(クライアント)の間でやりとりする
通信データを暗号化する技術を連想する。
例えば、ホームページを使った認証や、入力フォームに入力した
文字列等をWebサーバーに送信するデータを暗号化する事なのだ。
| SSLを使ったWebデータの通信の暗号化と目的 |
|---|
 |
Web上で重要なデータのやりとりを行う際に、
通信データの中身を暗号化する事によって、
悪い奴が盗聴したくても、通信データ(ID、パスワード等)が
盗聴できないようにする技術だ。
|
SSLで暗号化通信を行う事は知っていたのだが
詳しい事はわかりませーん (^^)
と、いつもの調子だった。
実は、SSLは数年前に導入しようと思い、本の丸写しの設定を行ったが
うまくいかへん （ＴＴ）
だった。
それ以来、SSLには手を出さなかったのだが、ネット販売システムの
刷新の案件が入った。
ネット販売を行う上で、顧客に対して信頼性を考えた場合、
SSLは必須になっている。
「うーん、困ったなぁ。導入できるんかいな」と思いつつ、
SSLの導入に取り組む事にした。
LinuxとApache でSSLの設定に挑戦
googleで検索して、設定方法が書いてあるサイトを調べてみる。
すると2つの方法で、Webデータの暗号化を行う方法があるという。
両方とも、サーバー側の設定だ。
| WebデータをSSLで暗号化する方法 |
|---|
| (1) |
Apache-SSL + OpenSSL の組合せ |
| (2) |
Apache + mod_ssl + OpenSSL (これが主流)
|
上の表の2番目の方法が主流だという。
なので、何の迷いもなく
主流を選ぶのらー！！ (^^)
と単純に決める私だった。
mod_sslは、Apacheのモジュールになる。
以下のような構成で動く
さて、早速、インストール作業にとりかかる。
私はソースコンパイルを行うので、以下のソフトを用意する必要がある。
ソースコンパイル時に必要なソフトの一覧
バージョンは2007年10月時点の最新版です |
|---|
| apache_1.3.37.tar.gz |
| mm-1.4.2.tar.gz |
| mod_ssl-2.8.28-1.3.37.tar.gz |
| openssl-0.9.8e.tar.gz |
(注意)
mod_sslのバージョン情報「2.8.28」の後ろに「1.3.37」がある
これは適合させるApacheのバージョンを意味する。
mod_sslは、Apacheのモジュールで、個々のApacheの
バージョンに適合させるため、個別にあるようだ。
|
既に、Linux上にopensslがインストールされていても、
別に用意する必要があるという。
この時点では何故かわからなかったが、とりあえずWebサイトの方法を
真似する事にした。
まずは、OpenSSLのコンパイルから行う。
| OpenSSLのコンパイル |
|---|
[root@xxx openssl-0.9.8e]# sh config no-idea no-threads -fPIC
(途中、省略)
[root@xxx openssl-0.9.8e]# make
(途中、省略)
[root@xxx openssl-0.9.8e]# make test
(途中、省略)
[root@xxx openssl-0.9.8e]#
|
これで終了だという。
make installは行わない。
次に、mm のコンパイルを行う。
| mm のコンパイル |
|---|
[root@xxx mm-1.4.2]# ./configure --disable-shared
(途中、省略)
[root@xxx mm-1.4.2]# make
(途中、省略)
[root@xxx mm-1.4.2]#
|
configureの際、「--disable-shared」オプションを付ける事から
共有ライブラリを生成しないようだ。
mod_sslに、mmの静的ライブラリを取り込ませるようだ。
|
これも、make installは行わない。
次に、apache_1.3.37.tar.gzを展開させる。
この時点では展開させるだけで、何もしない。
そして、mod_sslのconfigureを行う。
mod_sslはconfigureのみで、コンパイルは行わないというのだ。
| mod_sslのconfigure |
|---|
[root@xxx mod_ssl-2.8.28-1.3.37]# ./configure --with-apache=../apache_1.3.37 --with-ssl=../openssl-0.9.8e --with-mm=../mm-1.4.2
|
mod_sslのconfigureが終わると、次にApacheのコンパイルの指示と
その方法が出る。
| Apacheのコンパイルの指示と、その方法 |
|---|
Now proceed with the following commands:
$ cd ../apache_1.3.37
$ make
$ make certificate
$ make install
|
そして、指示通り、Apacheのコンパイルを行うのだが・・・
エラーが出てもうたー！！ （ＴＴ）
| Apacheをmakeした際に出たエラー |
|---|
[root@xxx apache_1.3.37]# make
===> src
make[1]: 入ります ディレクトリ `/usr/local/src/apache_1.3.37'
make[2]: 入ります ディレクトリ `/usr/local/src/apache_1.3.37/src'
===> src/regex
(途中、省略)
/usr/local/src/openssl-0.9.8e/libcrypto.a(dso_dlfcn.o)(.text+0x5ad): In function `dlfcn_unload':
: undefined reference to `dlclose'
collect2: ld はステータス 1 で終了しました
make[2]: *** [target_static] エラー 1
make[2]: 出ます ディレクトリ `/usr/local/src/apache_1.3.37/src'
make[1]: *** [build-std] エラー 2
make[1]: 出ます ディレクトリ `/usr/local/src/apache_1.3.37'
make: *** [build] エラー 2
[root@xxx apache_1.3.37]#
|
ぬぬぬ、こんな所でコケるとは・・・。
Web際とや本の丸写しだと、こんな時、どう対処して良いやらわからない。
このまま、しばらく保留になるのか。そんな不安が出てきたのだった。
だが、2日後、ふと思った。
Linuxに、最初からOpenSSLが入っているから、mod_sslをconfigureする際、
SSL関連のオプションを外せば、ええやん！
そこで気を取り直して、入れ直し作業を行う事にした。
既に、OpenSSLとmmはコンパイル済みなので、何もしない。
mod_sslとApacheだが、展開していた物を一度削除して、
新たに、taar.gzファイルを展開して、綺麗さっぱりの状態から
コンパイルなどを行う事にする。
まずは、mod_sslのconfigureから。
| mod_sslのconfigure |
|---|
[root@xxx mod_ssl-2.8.28-1.3.37]# ./configure --with-apache=../apache_1.3.37 --with-mm=../mm-1.4.2
|
前回と違い、この時は「--with-ssl=../openssl-0.9.8e」の
オプションを外す事にした。
|
configureが終わると、Apacheのコンパイルの指示と方法が出てきた。
| Apacheのコンパイルの指示と方法 |
|---|
Now proceed with the following commands (Bourne-Shell syntax):
$ cd ../apache_1.3.37
$ SSL_BASE=/path/to/openssl ./configure ... --enable-module=ssl
$ make
$ make certificate
$ make install
[root@xxx mod_ssl-2.8.28-1.3.37]#
|
前回とは違う指示が出た。しかも・・・
詳細が書いてへん (^^;;
「むにゅー。どないすれば、ええねん！」と悩んでしまう。
「SSL_BASE=/path/to/openssl」の部分だが、
opensslの実行ファイルの事だと考えた。
なので、opensslの実行ファイルを絶対パスで指定する事にした。
| 「SSL_BASE=/path/to/openssl ・・・」を実行 |
|---|
[root@xxx apache_1.3.37]# SSL_BASE=/usr/bin/openssl ./configure --enable-module=ssl --enable-module=so
Configuring for Apache, Version 1.3.37
+ using installation path layout: Apache (config.layout)
Creating Makefile
Creating Configuration.apaci in src
+ configured for Linux platform
+ setting C compiler to gcc
+ setting C pre-processor to gcc -E
+ using "tr [a-z] [A-Z]" to uppercase
+ checking for system header files
+ adding selected modules
o ssl_module uses ConfigStart/End
+ SSL interface: mod_ssl/2.8.28
+ SSL interface build type: OBJ
+ SSL interface compatibility: enabled
+ SSL interface experimental code: disabled
+ SSL interface conservative code: disabled
+ SSL interface vendor extensions: disabled
+ SSL interface plugin: Built-in SDBM
Error: Cannot find SSL installation in /usr/bin/openssl
Hint: Please provide us with the location of OpenSSL
via the environment variable SSL_BASE.
[root@xxx apache_1.3.37]#
|
エラーが出てもうたー！！ （ＴＴ）
ここで、ふと思った。
「SSL_BASE」の指定だが、もしかして、OpenSSLのライブラリではないか。
そこで、展開してコンパイルしたOpenSSLのディレクトリを指定する事にした。
| 「SSL_BASE」の指定を、展開しコンパイルしたOpenSSLのディレクトリにした |
|---|
[root@xxx apache_1.3.37]# SSL_BASE=../openssl-0.9.8e ./configure --enable-module=ssl --enable-module=so
Configuring for Apache, Version 1.3.37
+ using installation path layout: Apache (config.layout)
Creating Makefile
Creating Configuration.apaci in src
Creating Makefile in src
+ configured for Linux platform
+ setting C compiler to gcc
+ setting C pre-processor to gcc -E
+ using "tr [a-z] [A-Z]" to uppercase
+ checking for system header files
+ adding selected modules
o ssl_module uses ConfigStart/End
+ SSL interface: mod_ssl/2.8.28
+ SSL interface build type: OBJ
+ SSL interface compatibility: enabled
+ SSL interface experimental code: disabled
+ SSL interface conservative code: disabled
+ SSL interface vendor extensions: disabled
+ SSL interface plugin: Built-in SDBM
+ SSL library path: /usr/local/src/openssl-0.9.8e
+ SSL library version: OpenSSL 0.9.8e 23 Feb 2007
+ SSL library type: source tree only (stand-alone)
+ enabling Extended API (EAPI)
+ using system Expat
+ using -ldl for vendor DSO support
+ checking sizeof various data types
+ doing sanity check on compiler and options
Creating Makefile in src/support
Creating Makefile in src/regex
Creating Makefile in src/os/unix
Creating Makefile in src/ap
Creating Makefile in src/main
Creating Makefile in src/modules/standard
Creating Makefile in src/modules/ssl
[root@xxx apache_1.3.37]#
|
見事、成功 (^^)V
そして、makeでコンパイルを行う。
コンパイルも成功。そして、次の作業の指示が出る。
| 次の作業の指示 |
|---|
+---------------------------------------------------------------------+
| Before you install the package you now should prepare the SSL |
| certificate system by running the 'make certificate' command. |
| For different situations the following variants are provided: |
| |
| % make certificate TYPE=dummy (dummy self-signed Snake Oil cert) |
| % make certificate TYPE=test (test cert signed by Snake Oil CA) |
| % make certificate TYPE=custom (custom cert signed by own CA) |
| % make certificate TYPE=existing (existing cert) |
| CRT=/path/to/your.crt [KEY=/path/to/your.key] |
| |
| Use TYPE=dummy when you're a vendor package maintainer, |
| the TYPE=test when you're an admin but want to do tests only, |
| the TYPE=custom when you're an admin willing to run a real server |
| and TYPE=existing when you're an admin who upgrades a server. |
| (The default is TYPE=test) |
| |
| Additionally add ALGO=RSA (default) or ALGO=DSA to select |
| the signature algorithm used for the generated certificate. |
| |
| Use 'make certificate VIEW=1' to display the generated data. |
| |
| Thanks for using Apache & mod_ssl. Ralf S. Engelschall |
| rse@engelschall.com |
| www.engelschall.com |
+---------------------------------------------------------------------+
make[1]: 出ます ディレクトリ `/usr/local/src/apache_1.3.37'
<=== src
[root@xxx apache_1.3.37]#
|
「make certificate」の指示だが、オプションが必要なようだ。
この時「make certificate」は、何の作業なのか、全く理解していなかった。
そこでWebサイトで調べると「TYPE=custom」を選んでいたので、
ここは丸写しという事で、「make certificate TYPE=custom」を選んで
実行する事にした。
すると何やら質問がやってきた。
でも、何をするのか理解していなかったため、本の丸写しで
機械的に質問に答えていく事にした。
| 「make certificate TYPE=custom」を実行 |
|---|
[root@xxx apache_1.3.37]# make certificate TYPE=custom
make[1]: 入ります ディレクトリ `/usr/local/src/apache_1.3.37/src'
SSL Certificate Generation Utility (mkcert.sh)
Copyright (c) 1998-2000 Ralf S. Engelschall, All Rights Reserved.
Generating test certificate signed by Snake Oil CA [TEST]
WARNING: Do not use this for real-life/production systems
______________________________________________________________________
STEP 0: Decide the signature algorithm used for certificate
The generated X.509 CA certificate can contain either
RSA or DSA based ingredients. Select the one you want to use.
Signature Algorithm ((R)SA or (D)SA) [R]:R
______________________________________________________________________
STEP 1: Generating RSA private key (1024 bit) [server.key]
68509 semi-random bytes loaded
Generating RSA private key, 1024 bit long modulus
.++++++
.++++++
e is 65537 (0x10001)
______________________________________________________________________
STEP 2: Generating X.509 certificate signing request [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.
-----
1. Country Name (2 letter code) [XY]:JP
2. State or Province Name (full name) [Snake Desert]:Hyogo
3. Locality Name (eg, city) [Snake Town]:Kobe
4. Organization Name (eg, company) [Snake Oil, Ltd]:XXXXX
5. Organizational Unit Name (eg, section) [Webserver Team]:YYYYY
6. Common Name (eg, FQDN) [www.snakeoil.dom]:www.xxxxx.co.jp
7. Email Address (eg, name@FQDN) [www@snakeoil.dom]:suga@xxxxx.co.jp
8. Certificate Validity (days) [365]:
______________________________________________________________________
STEP 3: Generating X.509 certificate signed by Snake Oil CA [server.crt]
Certificate Version (1 or 3) [3]:3
Signature ok
subject=/C=JP/ST=Hyogo/L=Kobe/O=XXXXX/OU=YYYYY/CN=www.xxxxx.co.jp/emailAddress=suga@xxxxx.co.jp
Getting CA Private Key
Verify: matching certificate & key modulus
Verify: matching certificate signature
../conf/ssl.crt/server.crt: /C=XY/ST=Snake Desert/L=Snake Town/O=Snake Oil, Ltd/OU=Certificate Authority/CN=Snake Oil CA/
emailAddress=ca@snakeoil.dom
error 10 at 1 depth lookup:certificate has expired
OK
______________________________________________________________________
STEP 4: Enrypting RSA private key with a pass phrase for security [server.key]
The contents of the server.key file (the generated private key) has to be
kept secret. So we strongly recommend you to encrypt the server.key file
with a Triple-DES cipher and a Pass Phrase.
Encrypt the private key now? [Y/n]:Y
writing RSA key
Enter PEM pass phrase: passphrase
Verifying - Enter PEM pass phrase: passphrase
Fine, you're using an encrypted RSA private key.
______________________________________________________________________
RESULT: Server Certification Files
o conf/ssl.key/server.key
The PEM-encoded RSA private key file which you configure
with the 'SSLCertificateKeyFile' directive (automatically done
when you install via APACI). KEEP THIS FILE PRIVATE!
o conf/ssl.crt/server.crt
The PEM-encoded X.509 certificate file which you configure
with the 'SSLCertificateFile' directive (automatically done
when you install via APACI).
o conf/ssl.csr/server.csr
The PEM-encoded X.509 certificate signing request file which
you can send to an official Certificate Authority (CA) in order
to request a real server certificate (signed by this CA instead
of our demonstration-only Snake Oil CA) which later can replace
the conf/ssl.crt/server.crt file.
WARNING: Do not use this for real-life/production systems
make[1]: 出ます ディレクトリ `/usr/local/src/apache_1.3.37/src'
[root@xxx apache_1.3.37]#
|
これで準備が完了のようだ。
そして、Apacheを起動させる
| Apacheを起動させる |
|---|
[root@xxx bin]# pwd
/usr/local/apache/bin
[root@xxx bin]# ./apachectl start
|
ブラウザを開ける前に、以下のHTMLファイルを作成してみる。
| 「test.html」を作成してみた |
|---|
<html><head><title>SSLのテスト</title></head>
<body>
うまくいくかなぁ？<br>
暗号化通信で、通信データを守っています
</body></html>
|
これで良し。
早速、ブラウザを開いて見る。
するとエラーが出た。
| ブラウザーがエラー表示 |
|---|
 |
全然、接続できへんやん （ＴＴ）
SSL通信のポートHTTPS(443)で通信の待ち受けをしているのかどうか
確認を取るため、「telnet localhost https」をやってみる。
| 「telnet localhost https」をやってみる |
|---|
[root@xxx bin]# telnet localhost https
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
[root@xxx bin]#
|
なんで、通信ができへんねん （ＴＴ）
全く原因がわからない。
mod_sslのconfigureやApacheのコンパイルを、何度かやり直したが
思い当たる所がない。
色々、触って「わからん、どないするねん」と途方に暮れそうになりながら
ふと mod_sslに付いているINSTALLファイルを眺めてみた。
すると理由がわかった。
| mod_sslに付いているINSTALLファイルの中の記述 |
|---|
7. Try out Apache with SSL (both HTTP and HTTPS protocol possible):
$ /path/to/apache/bin/apachectl startssl ALL
$ netscape http://<local-host-name><http-port>/ ALL
$ netscape https://<local-host-name><https-port>/ ALL
$ /path/to/apache/bin/apachectl stop ALL
|
「apachectl」を起動させる時のオプションで、通常「start」の所、
SSLも動かす場合は「startssl」になるという。
なので、それをやってみる事にした。
| 「apachectl startssl」で実行してみる |
|---|
[root@xxx bin]# ./apachectl startssl
Apache/1.3.37 mod_ssl/2.8.28 (Pass Phrase Dialog)
Some of your private key files are encrypted for security reasons.
In order to read them you have to provide us with the pass phrases.
Server www.xxxxx.co.jp:443 (RSA)
Enter pass phrase: passphrase
Ok: Pass Phrase Dialog successful.
./apachectl startssl: httpd started
[root@xxx bin]#
|
赤い部分は、パスフレーズだ。
「make certificate」の際に、登録したパスフレーズを入力する。
ここでは赤くしているが、実際には表示はされないのだ。
|
これで、Apacheが起動したので、ブラウザを開けてみる。
| ブラウザーの表示 |
|---|
 |
見事、成功！ (^^)V
しかし、つまらん原因で労力と時間を無駄にしてしまった・・・。
SSLのインストール設定を整理
これで、SSLを使ったWeb通信でのデータの暗号化ができるようになった。
しばらく、SSLについては調べる事はしなかった。
だが、「待てよ」と思った。
Webサイトの丸写しで終わってしまったのでは・・・
何をどうしているのかが、わからへんやん！
もし、再インストールした時に、エラーが出たのでは
慌てふためくだけで、とても対処ができない。
何度も「たまたまインストールに成功」という事では良くない。
なので、キチンとインストールの手順を理解していく事にした。
最初に行ったインストールの復習にもなる。
まずは、以下の4つのソフトを用意する。
ソースコンパイル時に必要なソフトの一覧
バージョンは2007年10月時点の最新版です |
|---|
| apache_1.3.37.tar.gz |
| mm-1.4.2.tar.gz |
| mod_ssl-2.8.28-1.3.37.tar.gz |
| openssl-0.9.8e.tar.gz |
(注意)
mod_sslのバージョン情報「2.8.28」の後ろに「1.3.37」がある
これは適合させるApacheのバージョンを意味する。
mod_sslは、Apacheのモジュールで、個々のApacheの
バージョンに適合させるため、個別にあるようだ。
|
Apache + mod_ssl の形で、SSL通信を実現させるのだ。
まずは、OpenSSLのコンパイルから行う。
| OpenSSLのコンパイル |
|---|
[root@xxx openssl-0.9.8e]# sh config no-idea no-threads -fPIC
(途中、省略)
Since you've disabled or enabled at least one algorithm, you need to do
the following before building:
make depend
Configured for linux-elf.
[root@xxx openssl-0.9.8e]# make depend
(途中、省略)
[root@xxx openssl-0.9.8e]# make
(途中、省略)
[root@xxx openssl-0.9.8e]# make test
(途中、省略)
[root@xxx openssl-0.9.8e]#
|
最初に、OpenSSLのコンパイルを行った時は「make depend」は
行わなかった。だが、configコマンドを動かした際に
「make depend」の指示が出た。それに従ったのだ。
|
これで終了だ。
make installは行わない。
ここで思った。
SSLのライブラリは共有ライブラリではなく、静的ライブラリにして
mod_sslに組み込まれるのではないか。
| こんな感じのライブラリの依存関係があると思った |
|---|
 |
mod_sslはApacheを土台に動かしているだけでなく
暗号化のためのSSLライブラリ(OpenSSL)も土台にしていると思った。
|
そうする事によって、OpenSSLが入っていないシステムであっても
mod_sslが使える。それに、OpenSSLのバージョンが低くても、
独立した形で、最新のOpenSSLの静的ライブラリを使う事が可能だ。
(注意)
もちろん、既にインストールされているOpenSSLの共有ライブラリを
活用する事もできるようだが、今回は割愛します。
さて、次に共有メモリ「mm」のコンパイルだ。
| mm のコンパイル |
|---|
[root@xxx mm-1.4.2]# ./configure --disable-shared
(途中、省略)
[root@xxx mm-1.4.2]# make
(途中、省略)
[root@xxx mm-1.4.2]#
|
これも、make installを行わない。
しかも、configureのオプションが「--disable-shared」なので
共有ライブラリを生成しないようだ。
最新の「mm」ライブラリを使うために、静的ライブラリを生成して
mod_sslに組み込むようだ。
ふと思った。
ライブラリの依存関係は、次のようになっているのではないか。
| こんな感じのライブラリの依存関係があると思った |
|---|
 |
mod_sslはApacheやOpenSSLを土台に動かしているだけでなく
共有メモリのライブラリ(mm)も土台にしているのではないかと考えた。
|
実は、上図だと誤解を生じる部分がある。
それに関しては、しばらく後に記述しています。
さて、お次ぎはmod_sslのconfigureを行うのだが、この前に
apache_1.3.37.tar.gzを展開させる。展開させるだけで何もしない。
そして、mod_sslのconfigureを行う。
このconfigure作業では、何を行うのか。
INSTALLファイルを見てみる。
| INSTALLファイルの中身 |
|---|
5. Now apply the mod_ssl source extension and source patches to the Apache
source tree, configure the Apache sources and build Apache with mod_ssl
and OpenSSL.
Actually here you have three options:
(dependent on your situation and personal skill ;-)
|
mod_sslのソースをApacheのソースに付属させるための作業だ。
平たくいえば、Apacheのソースにmod_sslというパッチを当てる事だ。
その作業方法には3つあるという。
どの方法を選ぶかについては、状況やインストールを行う人の技術力に
依存するというのだ。
|
さて、私の場合は、前回と同様、以下の方法を選ぶ。
| mod_sslのconfigure |
|---|
[root@xxx mod_ssl-2.8.28-1.3.37]# ./configure --with-apache=../apache_1.3.37 --with-mm=../mm-1.4.2
|
「--with-apache」で、Apacheを展開した先と
「--with-mm」で、展開しコンパイルした後のmmのディレクトリの
|
さて、上のコンパイルの方法は、INSTALLファイルに記述されている
以下の内容に当てはまる。
| INSTALLファイルの中身 |
|---|
b) The flexible APACI-only way [FOR REAL HACKERS]:
You configure Apache manually and have the chance to configure
and add third-party Apache modules like mod_perl, mod_php,
mod_frontpage, mod_dav, etc. But you have to provide the
SSL_BASE and EAPI_MM variables manually and either copy your
existing certificate manually to conf/ssl.crt/server.crt or use
`make certificate':
|
上の記述を見た時・・・
APACIって何やねん！
だった。
ちょっと調べてみる事にした。
すると以下の事だという事がわかった。
| APACIとは何か? |
|---|
「Apache Autoconf-style Interface」の事だという。
それだけでは、よくわからん (--;;
Apache1.3以前は、展開した全体をコンパイルする事はできず、
モジュールのコンパイルは個々に行っていたようだ。
それを一括してコンパイルできるようにした方法だというのだが、
それでも意味が理解できない。
結局、何かわからんままで終わってしまった (--;;
|
とりあえず、configureを行ってみる。
そして、configureが終わると、その後の指示が表示される。
| Apacheのコンパイルの指示と方法 |
|---|
Now proceed with the following commands (Bourne-Shell syntax):
$ cd ../apache_1.3.37
$ SSL_BASE=/path/to/openssl ./configure ... --enable-module=ssl
$ make
$ make certificate
$ make install
[root@xxx mod_ssl-2.8.28-1.3.37]#
|
そこで上の青い部分の「SSL_BASE」の処理は以下のように行う。
| 「SSL_BASE」の指定を、展開しコンパイルしたOpenSSLのディレクトリにした |
|---|
[root@xxx apache_1.3.37]# SSL_BASE=../openssl-0.9.8e ./configure --enable-module=ssl --enable-module=so
Configuring for Apache, Version 1.3.37
+ using installation path layout: Apache (config.layout)
Creating Makefile
Creating Configuration.apaci in src
Creating Makefile in src
+ configured for Linux platform
+ setting C compiler to gcc
+ setting C pre-processor to gcc -E
+ using "tr [a-z] [A-Z]" to uppercase
+ checking for system header files
+ adding selected modules
o ssl_module uses ConfigStart/End
+ SSL interface: mod_ssl/2.8.28
+ SSL interface build type: OBJ
+ SSL interface compatibility: enabled
+ SSL interface experimental code: disabled
+ SSL interface conservative code: disabled
+ SSL interface vendor extensions: disabled
+ SSL interface plugin: Built-in SDBM
+ SSL library path: /usr/local/src/openssl-0.9.8e
+ SSL library version: OpenSSL 0.9.8e 23 Feb 2007
+ SSL library type: source tree only (stand-alone)
+ enabling Extended API (EAPI)
+ using system Expat
+ using -ldl for vendor DSO support
+ checking sizeof various data types
+ doing sanity check on compiler and options
Creating Makefile in src/support
Creating Makefile in src/regex
Creating Makefile in src/os/unix
Creating Makefile in src/ap
Creating Makefile in src/main
Creating Makefile in src/modules/standard
Creating Makefile in src/modules/ssl
[root@xxx apache_1.3.37]#
|
そして、makeでコンパイルを行う。
コンパイルも成功。そして、次の作業の指示が出る。
| 次の作業の指示 |
|---|
+---------------------------------------------------------------------+
| Before you install the package you now should prepare the SSL |
| certificate system by running the 'make certificate' command. |
| For different situations the following variants are provided: |
| |
| % make certificate TYPE=dummy (dummy self-signed Snake Oil cert) |
| % make certificate TYPE=test (test cert signed by Snake Oil CA) |
| % make certificate TYPE=custom (custom cert signed by own CA) |
| % make certificate TYPE=existing (existing cert) |
| CRT=/path/to/your.crt [KEY=/path/to/your.key] |
| |
| Use TYPE=dummy when you're a vendor package maintainer, |
| the TYPE=test when you're an admin but want to do tests only, |
| the TYPE=custom when you're an admin willing to run a real server |
| and TYPE=existing when you're an admin who upgrades a server. |
| (The default is TYPE=test) |
| |
| Additionally add ALGO=RSA (default) or ALGO=DSA to select |
| the signature algorithm used for the generated certificate. |
| |
| Use 'make certificate VIEW=1' to display the generated data. |
| |
| Thanks for using Apache & mod_ssl. Ralf S. Engelschall |
| rse@engelschall.com |
| www.engelschall.com |
+---------------------------------------------------------------------+
make[1]: 出ます ディレクトリ `/usr/local/src/apache_1.3.37'
<=== src
[root@xxx apache_1.3.37]#
|
「make certificate」の指示だ。
証明書、電子署名
ふと思った。
一体、「make certificate」は何の作業だろうか。
googleなどで調べてみると「デジタル証明書」などの語彙がでてきた。
一体、デジタル証明書って何やねん！
だった (^^;;
調べて行くと、次の事だった。
| 閲覧者がWebサーバーへ接続する様子 |
|---|
 |
閲覧者がWebサーバーにあるホームページを見る際
Webサーバーへ接続する。何も目新しい事はない。
だが、以下の問題がある事に気づかなかった
|
| こんな問題がある |
 |
接続している先のWebサーバーが本物のサーバーであるかどうかの
確認ができない。
|
接続先のWebサーバーが本物かどうかの問題だ。
うーん、今まで、そんな事を考えた事がなかった
正しくURLを入力すれば良いと思っていただけに、考えた事がなかった (^^;;
本物か偽装サイトかの区別ができない場合、「なりすまし」が起こる。
以下のような事件が起こるのだ。
| こんな悪用ができる(フィッシング詐欺) |
|---|
 |
例えば、悪人がA銀行に、なりすまして、A銀行の利用者に
「預金者におしらせ」といった形で、偽のメールを送りつける。
何も知らない利用者は、そのメールを信用して、URLをクリックすると
偽サイトに接続されてしまう。もし、偽サイトが本物そっくりなら
利用者は疑う事もないだろうし、残高確認などで、口座番号や
暗証番号を入力すれば、偽サイトの手に渡ってしまう危険がある。
A銀行となりすまして、偽サイトへ誘導する。
通称、「フィッシング詐欺」と呼ばれる。
|
わかったように書いているが、正直な事を書くと・・・
この時、フィッシング詐欺の手口を知ったのだ (^^;;
Webセキュリティーの話。
そこで本物か偽装サーバーかの違いを見分けるため、そのWebサイトが
「本物である」という証明書が必要になる。
| 本物である「証明書」が必要になる |
|---|
 |
企業の存在証明は、登記簿などがある。
それと同様にネット上のサーバーで、存在証明を行う証明書がある。
|
正直な事を書きます。
今まで・・・
SSLに身元証明機能がある事を知らなかったのら！！
そう。今までSSLは、通信データの暗号化を行う技術とばかり思っていた。
初めて「サーバーの身元証明」を行う機能がある事を知ったのだ。
「make certificate」の作業の前に「certificate」を英和辞典で
意味を調べてみる事にした。
| 「certificate」の意味 |
|---|
名詞的用法では「証明書」、「許可証」、「検定書」の意味だ。
動詞では「〜を証明する」の意味がある。
なので「make certificate」は、字の如く、証明書作成になる。
単なるコマンドとして捉えると無味乾燥だが、言葉として捉えると
わかりやすい。
|
さて、「make certificate」で身元証明書を作成する。
そこで身元証明書の作成手順を見ていく事にした。
| 「make certificate」で身元証明書を作成手順を見る(1) |
|---|
[root@xxx apache_1.3.37]# make certificate
make[1]: 入ります ディレクトリ `/usr/local/src/apache_1.3.37/src'
SSL Certificate Generation Utility (mkcert.sh)
Copyright (c) 1998-2000 Ralf S. Engelschall, All Rights Reserved.
Generating test certificate signed by Snake Oil CA [TEST]
WARNING: Do not use this for real-life/production systems
______________________________________________________________________
STEP 0: Decide the signature algorithm used for certificate
The generated X.509 CA certificate can contain either
RSA or DSA based ingredients. Select the one you want to use.
Signature Algorithm ((R)SA or (D)SA) [R]:R
|
RSA、DSAは公開鍵暗号の規格だという。
ここではお勧めのRSAを選ぶため「R」を選択する。
何もせずにENTERキーを押しても、「R」を選択した事になる。
|
暗号の規格を選んだ後、次に進む。
| 「make certificate」で身元証明書を作成手順を見る(2) |
|---|
______________________________________________________________________
STEP 1: Generating RSA private key (1024 bit) [server.key]
68509 semi-random bytes loaded
Generating RSA private key, 1024 bit long modulus
.++++++
.++++++
e is 65537 (0x10001)
______________________________________________________________________
STEP 2: Generating X.509 certificate signing request [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.
-----
1. Country Name (2 letter code) [XY]:JP
|
サーバーの所在地の国の名前をアルファベッド2文字で尋ねられているので
「JP」(日本)を返す。
|
サーバーの身元証明書を作るのだから、サーバーがある国名を記入だけでなく、
詳細な所在地を記入する必要がある。
| 「make certificate」で身元証明書を作成手順を見る(3) |
|---|
2. State or Province Name (full name) [Snake Desert]:Hyogo
3. Locality Name (eg, city) [Snake Town]:Kobe
4. Organization Name (eg, company) [Snake Oil, Ltd]:XXXXX
5. Organizational Unit Name (eg, section) [Webserver Team]:YYYYY
6. Common Name (eg, FQDN) [www.snakeoil.dom]:www.xxxxx.co.jp
7. Email Address (eg, name@FQDN) [www@snakeoil.dom]:suga@xxxxx.co.jp
|
サーバーの所在地の国名の後、順番に所在地と所属先を
尋ねられるので、それに答えていく。
身元証明書に住所と所属先を記録するためだ。
日本の場合、2は県名、3は市町村、4は組織名(会社名、団体名)
5は部署、6はURL、7はメールアドレスの入力を行う。
|
サーバーの身元証明書で住所、所属先の記入の後は
身元証明書の有効期限を指定する。
| 「make certificate」で身元証明書を作成手順を見る(4) |
|---|
8. Certificate Validity (days) [365]:
|
身元証明書の有効期限を指定する。
初期値は365日(1年)の設定だ。
何も指定せずにENTERキーを叩くと、365日に設定される。
|
有効期限を指定した後、身元証明書に署名をする必要がある。
その署名方法のバージョンを尋ねてくる。
| 「make certificate」で身元証明書を作成手順を見る(5) |
|---|
______________________________________________________________________
STEP 3: Generating X.509 certificate signed by Snake Oil CA [server.crt]
Certificate Version (1 or 3) [3]:3
|
作成している電子証明書のバージョンを尋ねてくる。
バージョン3がお勧めだというのだ。
電子証明書の規格の1つに「X.509」がある。
Apache + mod_sslでは「X.509」の規格が使われるようだ。
X.509の規格には、いくつかバージョンがあるので、
上の質問では、どのバージョンを使うのかを聞いている。
現在、よく普及しているのは1996年に世に出た「X.509 v3」なので
バージョン3を選ぶのが無難。もちろん上位互換だ。
何も指定せずにENTERキーを叩くと、バージョン3が指定される。
|
| 「make certificate」で身元証明書を作成手順を見る(6) |
|---|
Signature ok
subject=/C=JP/ST=Hyogo/L=Kobe/O=XXXXX/OU=YYYYY/CN=www.xxxxx.co.jp/emailAddress=suga@xxxxx.co.jp
Getting CA Private Key
Verify: matching certificate & key modulus
Verify: matching certificate signature
../conf/ssl.crt/server.crt: /C=XY/ST=Snake Desert/L=Snake Town/O=Snake Oil, Ltd/OU=Certificate Authority/CN=Snake Oil CA/
emailAddress=ca@snakeoil.dom
error 10 at 1 depth lookup:certificate has expired
OK
______________________________________________________________________
STEP 4: Enrypting RSA private key with a pass phrase for security [server.key]
The contents of the server.key file (the generated private key) has to be
kept secret. So we strongly recommend you to encrypt the server.key file
with a Triple-DES cipher and a Pass Phrase.
Encrypt the private key now? [Y/n]:Y
|
秘密鍵を3DESの暗号で、秘密鍵を暗号化するののかを尋ねて来る。
ここでは「Y」を選ぶ。何もせず、ENTERの場合も「Y」となる。
|
| 「make certificate」で身元証明書を作成手順を見る(7) |
|---|
writing RSA key
Enter PEM pass phrase: passphrase
Verifying - Enter PEM pass phrase: passphrase
|
秘密鍵に暗号化するためのパスフレーズを入力する。
上の図では、わかりやすくするため、わざと色をつけているが
実際には入力された文字列は全く表示されない。
|
| 「make certificate」で身元証明書を作成手順を見る(8) |
|---|
Fine, you're using an encrypted RSA private key.
______________________________________________________________________
RESULT: Server Certification Files
o conf/ssl.key/server.key
The PEM-encoded RSA private key file which you configure
with the 'SSLCertificateKeyFile' directive (automatically done
when you install via APACI). KEEP THIS FILE PRIVATE!
o conf/ssl.crt/server.crt
The PEM-encoded X.509 certificate file which you configure
with the 'SSLCertificateFile' directive (automatically done
when you install via APACI).
o conf/ssl.csr/server.csr
The PEM-encoded X.509 certificate signing request file which
you can send to an official Certificate Authority (CA) in order
to request a real server certificate (signed by this CA instead
of our demonstration-only Snake Oil CA) which later can replace
the conf/ssl.crt/server.crt file.
WARNING: Do not use this for real-life/production systems
make[1]: 出ます ディレクトリ `/usr/local/src/apache_1.3.37/src'
[root@xxx apache_1.3.37]#
|
暗号化通信に使う秘密鍵の「server.key」ファイル
身元を証明するための証明書の「server.crt」ファイル
そして、第三者に証明書に署名をしてもらうために、
第三者に送る署名要求書「server.csr」ファイルの3点が
生成された事を表示している。
第三者に送る署名要求書については後述しています。
|
これで「私は本物よ」という身元証明書と、身元証明書に署名ができた。
この後、make installを行えば完了だ。
Apacheの設定ファイル「http.conf」も、mod_sslのパッチが当たる事で
SSLに関する設定部分が追加されているが、ここでは省略しています。
詳しい事は、後述しています。
さて、ライブラリの構造ですが、インストールした後、
Apacheの実行ファイル「/usr/local/apache/bin/httpd」は、
どの共有ライブラリで支えられているのか、見てみる事にした。
| httpdの共有ライブラリを見てみると |
|---|
[root@xxx bin]# ls
ab apachectl apxs checkgid dbmmanage htdigest htpasswd httpd logresolve rotatelogs
[root@xxx bin]# ldd httpd
libm.so.6 => /lib/tls/libm.so.6 (0x40020000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40042000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4006f000)
libdl.so.2 => /lib/libdl.so.2 (0x4008f000)
libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[root@xxx bin]#
|
mmライブラリや、SSLライブラリが含まれていない。
この事から、mmライブラリ、SSLライブラリ静的ライブラリとして
httpdファイルに取り込まれた事が言える。
|
という事は、ライブラリの構造は以下のようになっている。
| こんな感じのライブラリ構造になっている |
|---|
 |
Apacheの一部にmod_sslが取り込まれているが、
そのmod_sslの中に、mmライブラリや、SSLライブラリが
取り込まれている感じだ。
正確な図なのかと言われると、自信はないのだが、
だいたい、こんな感じになっているという図なのだ。
|
何のライブラリが必要なのか、わかれば、コンパイルが楽になるし、
手間のかかるコンパイルであっても、混乱する事は避けられる。
ちなみに、Apacheに付け足す事ができるPHPのモジュールの
ファイル(libphp4.so)の共有ライブラリを見てみると
SSLライブラリを含んでいる。
| libphp4.so を支える共有ライブラリ |
|---|
[root@xxx apache]# cd libexec/
[root@xxx libexec]# ls
httpd.exp libphp4.so
[root@xxx libexec]# ldd libphp4.so
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4037c000)
libpq.so.5 => /usr/local/pgsql/lib/libpq.so.5 (0x403a9000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x403c0000)
libz.so.1 => /usr/lib/libz.so.1 (0x403e3000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x403f1000)
libresolv.so.2 => /lib/libresolv.so.2 (0x40410000)
libm.so.6 => /lib/tls/libm.so.6 (0x40422000)
libdl.so.2 => /lib/libdl.so.2 (0x40444000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40447000)
libssl.so.4 => /lib/libssl.so.4 (0x4045c000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0x40491000)
libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2 (0x40583000)
libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x40596000)
libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0x405f4000)
libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0x40604000)
libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
[root@xxx libexec]#
|
証明書、電子署名、認証局
さて、身元証明書の発行が終わったのだが、これでは実は不十分なのだ。
でも、上で行った身元証明書への署名は、自分自身で行った署名だ。
| 自分自身で署名した「証明書」 |
|---|
 |
身元証明書だが、自分自身で署名ができるため、
どのサーバーも「私は本物よ」と名乗る事ができる。
簡単に身元証明書が作成できる反面、偽装も簡単にできる問題が起こる。
自分で署名した証明書の事を「自己署名付き証明書」と呼んだりする。
|
身元証明書に、自分自身の署名をつける事ができる場合、
偽装の問題が発生する。
これは重大な問題で、以下の詐欺を行う事も可能なのだ。
| オレオレ詐欺(オレオレ認証局)が行える |
|---|
 |
偽装サーバーが、自分自身で身元証明書に署名を行えば形の上で
本物と偽る事ができる。
偽物の身元証明書を相手を見せて信頼させる事によって、
相手を騙す事も可能なのだ。
自分自身で身元証明書に署名をして、偽装サーバーを
本物に見せる手口の事を「オレオレ認証局」と呼ばれる。
|
「オレオレ認証局」では、「私は本物よ」と言っても信頼できない。
なので、以下の表示が出るのだ。
もちろん、詐欺を防ぐための機能がブラウザには付いている。
もし、認証局の署名がない本人確認の身元証明書を受け取ると
以下の警告が出る。
| こんな警告が出る(Firefox) |
|---|
 |
認証局が不明のため、偽装の恐れがあるという表示だ。
これにより、少しでも「オレオレ詐欺」の被害を減らそうとしている。
ちなみに、ブラウザには認証局の情報が入っているため、
サーバーから送られて来る身元証明書で、それに該当しない所の
署名がある場合は、全て「認証局不明」と表示される。
|
そこで身元証明書に、第三者の署名をつけて信頼性を付ける必要がある。
第三者機関として署名を行う所を「認証局(CA)」と言う。
| 認証局の署名があって、身元証明書の信頼性が確保できる |
|---|
 |
第三者の署名を行う機関・認証局(CA)の署名入りの身元証明書を使う事で、
「私は本物よ」と言って信頼してもらえるようになる。
有名な認証局として、ベリサインが挙げられる。
|
「信頼できる第三者の署名入りの証明書」が用意できて、
初めて誰からも信頼してもらえる証明書を持つ事ができるのだ。
結構、ややこしいし、手間がかかるなぁと思った。
でも、日常生活に置き換えると、別に、ややこしくない上、
ごく当然の事に気づく。
証明書と電子署名の話は面倒な感じだが
意外と日常生活での身分証明書と思えば理解しやすい |
|---|
証明書を発行しても「オレオレ認証局」という偽装の危険があるので
第三者である認証局(CA)の署名が必要となると、手続きをする事や
手順を覚えるのが手間に感じる。
だが、「システムの設定」という概念で考えると面倒で手間な事でも、
日常生活と照らし合わせると、自分を証明してくれる証明書を発行と
手順と同じだ。
例えば、自分で自分自身の本人確認の証明書を作成しても、
信頼できる第三者による署名がないため、偽装の可能性がある事から
レンタルビデオ屋で会員カードを作ったり、クレジットカードを
作る事ができない。
信頼できる公的機関発行のパスポート、保険証、車の免許証が
一般的な本人確認の証明書になる。
外務省、社会保険庁、警察が本人と認めた国家の署名入りの証明書だ。
まぁ、外交機密費と称して、血税で飲み食いしている国家版横領・外務省。
国家版「振り込め詐欺」で年金を騙し取る社会保険庁。
免許更新後、半ば強制的に「安全協会」に振り込ませる、国家版恐喝の警察。
こんな所が信頼できる公的機関かと言えば、疑問に思うが・・・。
私の場合、車の免許証を持っていないため、本人確認の証明書として、
パスポートを使ったり、保険証を使ったりする。
パスポートの場合、住所が印字されていない(手書きのため)
場所によっては、パスポートが使えない所もある。
でも、顔写真が載っていない保険証を本人確認に使うのも
いかがな物かと思うのだが・・・。
|
システムの設定という観点だけ見れば、ややこしく思える事でも、
日常生活に照らし合わせると、ごく当然の行為になる。
ところで、どうやって身元証明書に認証局の署名をするのか。
そこで調べてみた。すると、署名要求書を認証局に送るというのだ。
make certificateの際に、3つのファイルが生成された。
| make certificateの際に生成される3つのファイル |
|---|
| server.key |
暗号データを復元するための秘密鍵 |
| server.crt |
自分自身で署名した身元証明書。
拡張子の「crt」は「Certificate」(証明書)の略だ。
|
| server.csr |
拡張子の「csr」は「Certificate Signing Request」の略だ。
訳せば「証明書署名要求」だ。
|
この場合、署名要求書の「server.csr」ファイルを認証局に送れば良いのだ。
| 図にすると、こんな感じ |
|---|
 |
Webサーバーは、署名要求書を認証局に送る。
認証局は署名を行った身元証明書をサーバーに送り返す。
あとは、「make certificate」の際に生成された
自己署名の身元証明書を、認証局から送られた署名入りの身元証明書に
置き換えるだけだ。
|
手順としては簡単だと思った。
さて、今の段階では「オレオレ認証局」のままだ。
顧客向けに「オレオレ認証局」を使うのは、具合が良くない。
なぜなら「信頼できないサーバー」といった表示出るからだ。
そこで認証局に署名してもらう必要があるのだが・・・
試験段階で認証局にお金を払う事はできないのらー！
そう。
導入うんぬんの問題もあるが、キチンと設定ができるかどうかの確認のために
導入費用を投じる事なんぞできるわけがない。
稟議だって降りない。困ったなぁと思った。
だが、色々調べて行くと、お試し版の署名がある事を知る。
最初、海外にある認証局・Thawte社だった。
早速、Thawte社のサイト(http://www.thawte.com)を見るが・・・
全て英語やん （ＴＴ）
南アフリカ共和国の会社で、英語、ドイツ語、フランス語、イタリア語、
スペイン語のページはあるのだが、日本語のページがない。
なので、英語嫌いの私は・・・
神国・日本に異国の言葉を持ち込むな！
と叫びたくなる。
でも、そんな事を言うと「漢字は何やねん」と突っ込まれる (^^;;
その前に「『アレルギー』は外来語やん」という突っ込みもくる。
さて、英語のサイトを適当に読みながら、お試し版の使用のための
登録作業を終える。
これでオレオレ認証局の警告が出なくなると思ったのだが、
それでも以下の表示が出た。
| 認証局で署名してもらったが、警告が出た (Firefox) |
|---|
|
オレオレ認証局のままやん （ＴＴ）
だった。
この時点では謎だった。
後でわかった話、ブラウザに認証局の情報が入っていなかったためだ。
署名をもらってから、数日後、会社に電話がかかる。
私が電話に出るとThawte社だった。
| Thawte社との電話の会話 |
|---|
| 相手 |
I would like to talk to Yuichi. |
| 私 |
I am Yuichi Suga. |
| 相手 |
Do you speak English ? |
| 私 |
a little |
どうやら営業活動の電話だった。
まぁ、「神国・日本に異国の言葉を持ち込むな！」と攘夷論(?)を
唱える私なので、私の英語力なんて、たかが知れている。
それに、電話での会話は非常に聞き取りにくい。
なので私は・・・
Pardon me!
を連発した。
すると相手は「英語が話せない人」と思ってくれたため
電話での営業活動を諦めた (^^;;
まさか私宛に国際電話がかかるとは予想もしていなかっただけに、
ビックリした。
| 実は、Thawteの日本法人があった (^^;; |
|---|
だいぶ後になり、Thawte社のホームページを開けてみた。
「contact us」で日本の事務所の電話番号とメールアドレスがあった。
もしかしてと思い「www.thawte.com」を「www.thawte.co.jp」で
打ってみると、Thawteの日本法人のページが出てきた。
「ソートジャパン株式会社」という名称だ。もちろん、日本語だった。
しかし、2007/11/25現在でも、日本語のサイトには
お試し版がなかったので、Thawte社のお試し版を使うには
英語を読まねばならないのだ (--;;
|
さて、Thawte社のお試し版で身元証明書に署名をしたが、
オレオレ認証局のままで、「信頼できない」という警告が出た。
ここで不安がよぎる。
もしかして、認証局と契約して署名をしてもらっても
オレオレ認証局のままだったら、どーする！
そうなのだ。
地雷を踏む事に関しては、相当な才能(?)を持っているため、
折角、認証局と契約して、お金は払ったけど、設定がうまくいかずに、
オレオレ認証局の表示が出ては非常にマズいのだ (--;;
他の認証局でお試し版がないかと思い、何気なく日本ベリサイン社の
サイトを開く。
すると、お試し版があった。しかも日本語だ。
そこで、日本ベリサインのお試し版の署名を手に入れる事にした。
Thawte社の場合は、サイトが英語で書かれていたので、適当にやった。
今回は、日本語のサイトな上、キチンと設定したいので
内容をしっかり読んでいこうと思ったのだが、日本語の安心感と
概略を理解したという安心感で、じっくり読まずに適当に進める事にした。
さて、まずは署名要求書をWebを使って日本ベリサインへ送信する。
| 署名要求書を日本ベリサインへ送信する様子 |
|---|
 |
「make certificate」の際に生成されたserver.csrファイルの内容を
そのまま張り付けた。
|
次に、送信した署名要求書のデータに書かれた、Webサーバーの所有や
所在地の表示が出てくる。
送信した署名要求書の情報が表示される
(申請フォームの入力) |
|---|
 |
同じページをめくっていくと、Webサーバーの担当者の情報の記入がある。
Webサーバーの担当者などの情報を記入
(申請フォームの入力) |
|---|
 |
この時、思った。
肩書きのない人間は、何を記入すれば良いのだ。
ここでは「一般社員」とした。
「平社員」と書くのも変だし、「ヒラリーマン」は・・・ (^^;;
肩書きなんぞついたら、責任が重たくなる上、仕事において、
より多くの成果物が求められるので、気楽なヒラリーマンが良いのだ。
幸い、社内評価も高くないので、まだまだ気楽なヒラリーマンができる (^^)
でも、役職の項目が必須の場合、何を書けば良いのだろうか。
|
選択肢の中で証明書の種類で「2層」と「3層」があったが、
意味がわからないため、ここは当てずっぽで「3層」を選んだ (^^;;
さて、情報を記入したので、次に進む。
ブラウザで以下のような表示が出た。
| こんな表示が出た(テキストにしています) |
|---|
テスト用 ルート証明書の入手：
まず、テスト用 ルート証明書を以下の手順で入手してください。
テスト用ルート証明書は、申請フォームで選択した 「証明書の種別（階層）」 ごとに異なります。
1. 以下より、取得したテスト用セキュア・サーバIDに該当する種別のリンク先をクリックしてください。
・2階層（現行のセキュア・サーバIDと同等） テスト用ルート証明書
For VeriSign authorized testing only. No assurances (C)VS1997
・3階層（2007年6月以降発行予定のセキュア・サーバIDと同等） テスト用ルート証明書
VeriSign Trial Secure Server Test Root CA
2. クリックした種別のテスト用ルート証明書がポップアップ表示されます。
3. 画面中の （-----BEGIN CERTIFICATE-----） から （-----END CERTIFICATE-----） までを
コピーし、「メモ帳」 などのテキストエディタに貼り付けます。
4. 拡張子を（*.cer）にして任意のファイル名、場所に保存します。
|
私は「3層」を選んでいるので、「3層」のルート証明書を選ぶ。
| ルート証明書の取得 |
|---|
 |
ここでルート証明書の取得ができる。
だが、ここで正直に暴露。
ルート証明書って何やねん！
だった (^^;;
しかも「-----BEGIN CERTIFICATE-----」と「-----END CERTIFICATE-----」が
付いていたので・・・
署名付き証明書だと思ったのらー！！
だった。
早速、自己署名の身元証明書を、ブラウザで得られたルート証明書を
置き換え、Apacheを再起動させた。
さて、ブラウザを開けてみる事にした。
ワクワクする瞬間だが・・・
なんでエラーが出るねん （ＴＴ）
だった。
| ブラウザーがエラー表示 |
|---|
|
デーモンの状態を見ると、Apacheを起動しても、すぐにコケるため、
ブラウザが表示できないのだ。
さぁ、困った。
日本ベリサインの手順を、しっかり読まなかったためだった。
そこで手順を読み返す事にする。すると、ある一文が目に入った。
| こんな記述を見た |
|---|
サポート外のCSRフォーマットについて：
PEM形式のCSRに対しては、サーバIDの発行をサポートしていません。
PKCS#10形式のCSRのみの受付となります。
|
ふと次の事が過った。
もしかして、日本ベリサインに送った署名要求書は
PEM型式のファイルなのではないだろうか。
「make certificate」の作業の後で出力される表示を見てみる。
| 「make certificate」の作業の後で出力される表示 |
|---|
o conf/ssl.csr/server.csr
The PEM-encoded X.509 certificate signing request file which
you can send to an official Certificate Authority (CA) in order
to request a real server certificate (signed by this CA instead
of our demonstration-only Snake Oil CA) which later can replace
the conf/ssl.crt/server.crt file.
|
上の青い部分を見た瞬間・・・
これではアカンのかいな (^^;;
そこで、サーバーにある署名要求書を他の型式に変える方法がないかと
調べてみる。
opensslコマンドを使えば、署名要求書の型式がPEM型式から
DER型式に変換できる事が書いてあった。
これでいけるのではと思った私は、早速、以下のコマンドを叩くのだが・・・
エラーが出るやん （ＴＴ）
| エラーの様子 |
|---|
[root@xxx ssl]# openssl x509 -in server.csr -inform DER -out server-out.csr
unable to load certificate
5970:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:939:
5970:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:304:Type=X509
[root@xxx ssl]#
|
うーん、八方塞がりだ・・・ (--;;
「わからん」と思いながら、気分転換にメールを読む。
すると、日本ベリサインからメールが来ていた。
| 日本ベリサインからきていたメール |
|---|
Dear VeriSign Customer,
Congratulations -- your Test Server ID (certificate), issued to
XXXXX.YYYYY.CO.JP, is included at the end of this message.
VeriSign has digitally signed your Certificate, providing assurance
that your
certificate has not been damaged or changed without detection.
For instructions on how to install your Test Server ID, the Test CA
Root, and the Trial Intermediate CA, please visit:
https://digitalid.verisign.co.jp/trialserver/trialStep4.htm
https://digitalid.verisign.co.jp/trialserver/trialStep5.htm
After testing your Trial Server ID, we encourage you to check out
VeriSign's full line of Secure Site Services at:
https://www.verisign.co.jp/server/index.html
VeriSign Digital ID Services
-----BEGIN CERTIFICATE-----
MIIEgjwerrugAwIBAgIQcpeTrCpbHQQicYRoKYCtizANBgkqhkiG9w0BAQUFADCB
5zELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
(途中、省略)
d3vt5psWcUHftvMafdMTe3oc+G0QaHj5TT9q64is++BcMYJ2PWCEomBBdQ7bH5vF
VzIOXN+Gt3I+apm2rf6jygwlxyt70UAeeTdT/PjlkfcBVN8cM9OXkkBCQHARpD1C
59Vzx8XY
-----END CERTIFICATE-----
|
メールの内容を見ると、署名付き証明書と書いてある。
この時、もしかして、Webで取得したのは、署名付き証明書ではなく
他の物だと思った。
|
そこで、このデータを、署名付き証明書としてサーバーに置いて
Apacheを起動させてみた。
そしてブラウザを開く。すると以下の画面が出てきた。
| 出てきた画面(Firefox) |
|---|
|
オレオレ認証局だけど、通信ができている！
どうやら日本ベリサインのお試し版の場合、署名付き証明書は
メールで送られるのだ。
それに署名要求書(CSR)のPEM型式うんぬんの問題もなさそうだ。
では、Webで取得した物は「ルート証明書」というが、一体、何だろうか。
日本ベリサインのWebに載っている手順を見てみる。
以下の記述がある。
| こんな事が書いてある |
|---|
テスト用 ルート証明書のブラウザへのインストール：
入手したテスト用 ルート証明書を、接続テストをするすべてのブラウザに事前にインストールしておきます。
以下は参考手順です（ブラウザやOSのバージョンにより表示画面などが多少異なります）。
【Microsoft Internet Explorer】
1. 入手したテスト用ルート証明書ファイル （*.cer） をダブルクリックして開きます。
セキュリティの警告が表示された場合は、「開く」または「はい」をクリックしてください。
2. 証明書の情報画面が表示されます。「証明書のインストール」ボタンをクリックします。
3. 証明書をインポートするためのウィザードが起動します。画面にそってインポート（インストール）します。
※ 初期設定のまま、特に設定を変更する必要はありません。
4. インポート完了のメッセージが表示されれば、テスト用ルート証明書のインストールは完了です。
|
上の文面を読んだ瞬間・・・
ブラウザに登録するモンだったのか！
と初めて理解した。
よい子のみなさんは、横着して説明文を流し読みすると七転八倒するので
キチンと説明書きは読みましょう (^^;;
さて、ブラウザに登録するのだが・・・
どうやって登録するねん (--;;
だった。
Firefoxに登録する方法が、日本ベリサインのWebサイトには書かれていない。
でも、適当に触っていると、だいたいわかってきた。
| Firefoxの設定画面 |
|---|
 |
|
ピンクで囲まれた部分「証明書表示」をクリックする
|
すると以下の画面が出てくる。
| 出てきた画面(Firefox) |
|---|
 |
青い部分の「認証局証明書」を選ぶと、色々な認証局の情報が表示される。
ここでピンクの部分の「インポート」を選ぶと良い
|
するとインポートするルート証明書を選ぶ画面が出てくる。
| ルート証明書の取り込み(インポート) |
|---|
 |
ここでルート証明書の取り込み(インポート)を行う。
該当のファイルを選択する。
|
該当のファイルを選択したら、以下の画面が出てくる。
| ルート証明書の適用範囲の指定 |
|---|
 |
ここでルート証明書の適用範囲を選ぶ。
適用範囲とは、Webやメールなど、どの範囲まで、
サーバーから送られた証明書と突き合わせるかを選択するのだ。
ここでは全て印を付けてみる。
|
ここでわかった事は「ルート証明書」はブラウザに取り込んで
閲覧した先のホームページから送られる署名付き証明書の署名との
照合に使われる事だ。
ブラウザには、あらかじめ認証局の情報を組み込んでおいて
そして、サーバーから送られる証明書に署名している認証局とを
突き合わせるのだ。
まるで、勘合貿易を思い出す。
| 足利義満は売国奴だ! |
|---|
勘合貿易を行った足利義満は、己の利益のために、
明の属国になったため、売国奴と言える。
隋と対等な関係で外交を行った聖徳太子に対して
申し訳がないのかと思ったりする。
これは足利義満だけでなく、現在の害務省(外務省)の
チャイナスクールのクズ共にも言える事だ。
|
さて「OK」ボタンを押して前に進めると、怪しい画面が出てきた。
| 出てきた怪しい画面(Firefox) |
|---|
 |
ルート証明書が怪しいというのだ。
「怪しい」と言われても、どうしようもないので
そのまま前に進める。
|
そこで日本ベリサインから発行された「ルート証明書」を
ブラウザ(Firefox)にインポート(取り込む)でみた。
だが・・・
それでもオレオレ認証局のままやん (--;;
だった。
つまり「信頼できないサイト」と出てしまったのだ。
もしかして、Firefoxでの設定は、マニュアル無しで適当にやったため、
うまくいかなかったのかもしれない。
そこで、日本ベリサインのサイトにある、IE(Internet Explore)の
マニュアルを見ながら、IEで試して見る事にした。
まずは、ルート証明書のアイコンをクリックする。
| ルート証明書のアイコン |
|---|
 |
上のアイコンをクリックすると、以下の画面が出てくる。
| ルート証明書のインストール画面 |
|---|
 |
インストールを選ぶ。
すると以下の画面が出てくる。
| ルート証明書の取り込み(インポート)の画面 |
|---|
 |
「次へ」を選ぶ。
すると以下の画面が出てくる。
| ルート証明書のインストール画面 |
|---|
 |
選択肢が出てくる。
ここでは「証明書の種類に基づいて、自動的に証明書ストアを選択する」
を選び、「次へ」を押す。
|
すると以下の画面が出てくる。
| ルート証明書のインストール画面 |
|---|
 |
「完了」を選ぶ。
すると何やら怪しい画面が・・・。
| 何やら怪しい画面が・・・ |
|---|
 |
「検証できない」という文字が出てくる。
でも、読んでも意味がわからなかったので、そのまま飛ばした。
|
インポート終了画面が出て、全てが完了だ。
| 取り込み(インポート)終了画面 |
|---|
 |
さて、ルート証明書を入れたIEでは、オレオレ認証局の警告が出ないと思い
サーバーに接続してみる。だが・・・
オレオレ認証局のままやん （ＴＴ）
だった。
| でも、オレオレ認証局のままだった |
|---|
 |
うーん、どないすればエエねん・・・。
八方塞がりになってしまった。
悪あがきが得意な私だが、さすがに力尽きてしまった。
SSL暗号化通信の仕組みについて
SSLを使ってWebの通信データを暗号化するのだが、
秘密鍵と公開鍵を使う事からには、公開鍵暗号の技術を使っているはず。
もし、公開鍵暗号の技術を使っているのであれば、「公開鍵」はどこに
保管されているのだろうか。
たしかに、秘密鍵の生成はしたが、公開鍵は見ていない。
つまり公開鍵暗号の技術が使われている。
でも、思った。
どこで公開鍵暗号の技術を使ってるんやろ?
そして、次の事も思った。
SSLでは、通信データを暗号化するが、どいういう風に暗号化しているのか。
まずは調べてみる前に、自分の頭の中で想像してみる事にした。
そこで、通信データの暗号化について考えてみる事にした。
もし、公開鍵暗号の技術でなければ、共通鍵を使っているだろう。
共通鍵の場合、クライアント、もしくはサーバー側で生成された物を
相手に渡して、お互い暗号化・復元化を行うだろう。
| クライアント側で共通鍵を生成し、サーバーへ送る場合 |
|---|
 |
| サーバー側で共通鍵を生成し、クライアントへ送る場合 |
 |
でも、上のように共通鍵の受け渡しを行う場合、以下のような
重大な問題が出てくる。
それは共通鍵が通信経路上で盗聴されるという問題だ。
| クライアント側で共通鍵を生成し、サーバーへ送る場合 |
|---|
 |
| サーバー側で共通鍵を生成し、クライアントへ送る場合 |
 |
共通鍵が盗聴されたら、いくら暗号強度が高くても簡単に解読されるため
全く意味がない。
そこで公開鍵暗号を使っていると考えた。
クライアントがサーバーへデータ送信する場合、
公開鍵で暗号化し、サーバーは秘密鍵で復元化すると考えた。
| クライアント側は公開鍵でデータの暗号化を行う |
|---|
 |
公開鍵は、その名の通り公開されていて、誰が見ても
問題ないという事から、何らかの形でサーバーから入手する。
クライアントがサーバーへデータを送信する際に、
公開鍵で暗号化を行う。
|
そしてサーバーがクライアントにデータ送信する場合、
秘密鍵で暗号化を行い、クライアントは公開鍵で復元化を行うと考えた。
| サーバー側は秘密鍵でデータの暗号化を行う |
|---|
 |
サーバー側は秘密鍵でデータの暗号化を行い
クライアントでは公開鍵でデータの復元を行う
|
でも、この場合も重大な問題が発生する。
クライアントからサーバーへデータ送信する場合は問題はない。
| クライアント側からサーバーへデータ送信する場合 |
|---|
 |
公開鍵でデータの暗号化を行っているため、
復元化できるのは、秘密鍵のみ。
そのため、通信経路上でデータの盗聴を行いたくても、
秘密鍵を知らない限り、盗聴は不可能。
|
だが、サーバー側から秘密鍵で暗号化してクライアントへ送る際が問題だ。
| サーバーからクライアントへデータ送信する場合 |
|---|
 |
秘密鍵で暗号化を行えば、公開鍵で復元化できる。
公開鍵は、その名の通り、誰でも見れる鍵のため、
いくら暗号強度が強くても、公開鍵さえ手に入れれば
簡単に通信経路上で盗聴が可能になる。
|
見事に盗聴されてしまう。
それに通信データの暗号化に公開鍵暗号を使う事自体、現実的ではない。
なぜなら、暗号化するのに時間がかかるため、通信速度が大幅低下する。
うーん、ちょっと自分の頭の中で考えたものの・・・
全く使えへん方法やん！
だった。
我ながら想像力の乏しさに感心してしまった (^^;;
実際に、どういった形で通信データを暗号化・復元化を行っているのかを
調べてみる事にした。
すると、公開鍵暗号と共通鍵の二刀流を使っている仕組みだった。
図にすると以下の通りだ。
| クライアント側で共通鍵を生成し、サーバーへ送る |
|---|
 |
クライアント側で共通鍵を生成する。
生成した共通鍵を、そのままサーバーへ送るのではなく
公開鍵で暗号化して、サーバーへ送る。
|
この方法だと安全に共通鍵をサーバーに送る事ができる。
| これだと盗聴されても、解読は不可能 |
|---|
 |
生成した共通鍵を、公開鍵で暗号化する事によって
途中の経路で通信データを盗聴されても、
暗号データの復元化ができないため、安全にサーバーへ
共通鍵を送る事ができる。
まぁ、何千年単位でスーパーコンピューターを稼働させれば
解読できるかもしれないが、その頃には、解読されても困らないので
基本的に「解読されない」と明言しても差し支えはないだろう。
|
そして、サーバーは、暗号化された共通鍵を受け取った後、
秘密鍵を使って復元化する。
| サーバーで復元 |
|---|
 |
クライアントから送られた暗号化された共通鍵を
秘密鍵で復元化する。
これでクライアント、サーバー共に共通鍵を使う事ができる。
|
共通鍵を手に入れたサーバー。
これでお互い暗号化通信ができる。
| 共通鍵を使ってお互い暗号化通信を行う |
|---|
 |
これだとお互いの通信が安全に行う事ができる。
| 共通鍵を使って安全に通信が行える |
|---|
 |
盗聴者は共通鍵を持っていないため、暗号化されたデータを
復元化する事ができないため、安全に通信ができる。
|
これが、SSLを使った暗号化通信の基本的な仕組みになる。
公開鍵暗号と共通鍵暗号の二刀流を使う事で、共通鍵が盗聴されずに、
安全に共通鍵の受け渡しを行い、共通鍵でデータの暗号化通信を行う。
さて、どうやって暗号化通信を行うのか仕組みを知る事ができた。
でも、疑問が残っている。
SSLでは、クライアント側が公開鍵を持っているのだが、
いつ、クライアントに公開鍵を渡しているんやろ?
調べてみると、クライアントからサーバへ接続要求があった後、
公開鍵を送っている。
それと同時にサーバーが本物である事の証明書も送っている。
図にすると以下の通りになる。
| クライアントへ公開鍵と証明書を渡す様子 |
|---|
 |
クライアントからサーバーへ接続要求を行う。
そして、サーバーはクライアントに対して公開鍵を送ると同時に
サーバー自身が本物である事を証明する証明書を送る。
|
これでSSL通信の仕組みの全体が見えてくる。
■■■ 複数のドメインの証明について ■■■
Apacheでは、1台のサーバーに、URLを2種類以上持たせる事ができる。
つまり以下のように、ドメインを2種類以上、持たせる事ができるのだ。
| ドメインを2種類以上、持たせる事ができる |
|---|
 |
図のように、1台のサーバーに、2つ以上のURLを持たせる事ができる。
用途に合わせて、ドメインを別にする事で、わかりやすくする事もあるし、
ディレクトリー構造でぶら下げるよりも、複数のドメインで分けた方が
URLがスッキリする事もある。
|
だが、こんな場合、以下の問題が発生する。
| 証明書に登録したドメインは1だけの場合 |
|---|
 |
証明書に登録したドメインが1つだけの場合
もう片方は、未登録のドメインの扱いになる
|
未登録のドメインを使って、httpsで接続した場合、
以下の画面が出てくる。
| 未登録のドメインの方でhttps接続した場合 |
|---|
 |
セキュリティーエラーが出る。
証明書に登録したドメインと、接続先のドメインとが不一致だからだ。
|
こんな場合、個々のドメインごとに証明書を発行して、
個々の証明書に認証局の署名をつけてもらう方法がある。
認証局によっては、異なる部分を任意の文字扱い(アスタリスク)にして
署名する事ができるサービスを提供している所もあるのだが・・・
値段が高いのらー！！
だ (^^;;
SSLを使わない場合は、用途によって、複数のドメインにする事で、
URLを簡潔にしたりする利点があるが、SSLを使った場合だと
費用面の問題が発生してしまうのだ。
通信データはドメインが不一致でも暗号化されるのだが、
存在証明としては、とても使えない。
■■■ 有効期限切れの証明書 ■■■
証明書を作成する時、有効期限を指定した。
さて、有効期限が切れた場合は、以下の表示が出てくる。
| 証明書が有効期限を過ぎている場合 |
|---|
 |
有効期限切れという表示が出てくる。
もちろん、通信データ自体は暗号化されているため
盗聴される心配はないのだが、存在証明としては
いささか怪しく感じてしまう。
|
最後に
今回は Apache + mod_ssl を使ったSSL通信の話を取り上げました。
SSL通信といえば、今まで暗号化通信とばかり思っていましたが、
サーバーが本物である事の証明書や、その証明書が正しい事を裏付ける
電子署名の話が出てきました。
もっと深く突っ込めば、色々な話が書ける所ですが、
突っ込んだ話を取り上げると、どんどん話が膨張しそうなため、
今回は、この辺りでやめました。
OpenSSLやPKIの突っ込んだ話は別の機会に取り上げたいと思います。
次章：「無料のオープンソースECサイト(EC-CUBE)でネット販売システムの構築」を読む
前章：「PostgreSQLのお勉強。ログ、WAL、PITR、障害時のデータ復旧」を読む
目次：Linux、オープンソースで「システム奮闘記」に戻る