サーバ管理のアーカイブ

１つのIPで複数のSSLドメインの管理が出来るという記事を以前google検索していて読んだような気がしたので、再度検索してみました。

Apache 2.2.12 以降 ＋OpenSSL0.9.8f 以降だと、SNI ( Server Name Indication )という技術を使って１つのIPで複数のSSLドメインの管理をする事が出来るらしい。 (^^)v

自分のOS 環境を調べてみました。 あいにくOpenSSL0.9.8e だったので、今回は無理をせずOS がバージョンアップするまでペンディングする事にしました。

参考にさせていただいたURL
１つのIPで複数のSSLドメインの管理
Apacheの設定を変更し、単一IPアドレス上で複数のSSLサイトを運用

SSL(Secure Socket Layer)認証の更新時期がきたので、送られてきたSSLサーバ証明書を差し替え。

私は2年毎の更新にしているので、更新手順はすっかり忘れている状態。今回は中間CA証明書のインストールで無駄な時間を費やしてしまいました。 Apache2 + mod_ssl の場合、ssl.conf のSSLCertificateChainFileを コメントアウトを外し中間CA証明書のパスとファイル名を指定します。 この設定前は firefox でうまくssl として読むことができず半日潰しました。 (^^;

更新でなければ RSA秘密鍵を生成して、RSA秘密鍵を元にCSR(Certificate Signing Request 証明書要求)ファイルを生成して認証局に送付し、認証局が受け取ったCSRを元にサーバ証明書を生成しサーバ管理者に送付。サーバ管理者は受け取ったサーバ証明書をWebサーバに組み込んで、SSLを導入します。

RSA秘密鍵生成
openssl genrsa -out hoge.key 1024
chmod 400 hoge.key
—–BEGIN RSA PRIVATE KEY—–
—–END RSA PRIVATE KEY—–

というPEM形式のフォーマットで作成される。

CSR生成
生成した RSA 秘密鍵 hoge.key を元に、CSR (証明書要求) を作成し、csr.pem に出力します。 ここではSSL/TLS を導入したいドメインの情報を入力します。
生成される csr.pem の内容は以下の通りです。
—–BEGIN CERTIFICATE REQUEST—–
—–END CERTIFICATE REQUEST—–

http://x68000.q-e-d.net/~68use……tup-1.htmlの記事に感謝です。
1. サーバ管理者が RSA 秘密鍵 (server.key) を生成します。
RSA秘密鍵生成
openssl genrsa -out hoge.key 1024
chmod 400 hoge.key

—–BEGIN RSA PRIVATE KEY—–
—–END RSA PRIVATE KEY—–
というPEM形式のフォーマットで作成される。

2. CSR生成
生成した RSA 秘密鍵 hoge.key を元に、CSR (証明書要求) を作成し、csr.pem に出力します。 ここでは SSL/TLS を導入したいドメインの情報を入力します。

生成される csr.pem の内容は以下の通りです。
—–BEGIN CERTIFICATE REQUEST—–
—–END CERTIFICATE REQUEST—–

1. サーバ管理者が RSA 秘密鍵 (server.key) を生成します。
2. サーバ管理者が RSA 秘密鍵を元に CSR (Certificate Signing Request: 証明書要求。csr.pem) ファイルを生成し、認証局に送付します。
3. 認証局が受け取った CSR を元にサーバ証明書 (server.crt) を生成し、サーバ管理者に送付します。
4. サーバ管理者は受け取ったサーバ証明書を Web サーバに組み込みます。
ポイントをまとめます。
* 秘密鍵 server.key と、CSR である csr.pem はサーバ管理者が生成します。
* サーバ管理者は csr.pem を認証局に送ります。server.key は誰にも公開してはいけません。認証局に公開してもダメです。
* 認証局は受け取った csr.pem を元に署名を行い、証明書 server.crt を生成して、サーバ管理者に送付します。
* 最終的にサーバ管理者が必要なのは、秘密鍵 server.key と証明書 server.crt です。 いったん証明書が作成されたら csr.pem は不要になります。削除しても構いません。

* それぞれのファイル名は何でもよいです。server-private-key.pem や server-certificate.pem としても別に構いません。 ファイルの 1行目が「BEGIN RSA PRIVATE KEY」なら RSA 秘密鍵、「BEGIN CERTIFICATE REQUEST」なら CSR、「BEGIN CERTIFICATE」なら証明書、と考えるとよいでしょう。
1. サーバ管理者が RSA 秘密鍵を元に CSR (Certificate Signing Request: 証明書要求。csr.pem) ファイルを生成し、認証局に送付します。
2. 認証局が受け取った CSR を元にサーバ証明書 (server.crt) を生成し、サーバ管理者に送付します。
3. サーバ管理者は受け取ったサーバ証明書を Web サーバに組み込みます。

/\.bigfish\.com$/
/\.frontbridge\.com$/
/\.messaging\.microsoft\.com$/

http://lists.policyd.org/piper……00146.html

Default whitelist entries – bigfish.com

Thomas Johnson wrote:
> My old company should probably be whitelisted.
> 
> FrontBridge (which was just acquired by Microsoft) still identifies  
> it's mail servers by it's original name: bigfish.com.
> 
> There are hundreds of these servers sitting behind loadbalancers and  
> each machine identifies itself in a "helo" with it's actual name, so  
> you may see a ton of helos coming from one IP address:
> 
> 
> | 216.148.222.61 | mail45-red-r.bigfish.com
> | 216.148.222.61 | mail62-red-r.bigfish.com
> | 216.148.222.61 | mail98-red-r.bigfish.com
> 
> At this time, all of the FrontBridge/Big Fish servers are reporting  the 
> following IP addresses:
>   12.129.199.61
>   63.161.60.29
>   63.161.60.61
>   63.161.60.93
>   206.16.192.253
>   216.35.189.221
>   216.148.222.61
>   213.206.137.197
>   217.117.146.230
>   62.209.45.166
> 
> This might be a good thing to add to doc/WHITELIST.sql in the  
> distribution, since with over 3000 enterprise customers, they could  
> fall victim to the blacklist_helo checks of policyd.

オススメのメールサーバを教えてくださいの投稿を読んだのがきっかけで、1ヶ月間は無料で使えるという、Google Apps for businessを使ってみる事にしました。

Google Apps for Business

このページの無料試用を開始するから登録を開始。
使っていないドメインがあったので、Google Appsをメールサーバーとして使うというページを参考にさせていただきながら、Google Appsを独自ドメイン用のメールサーバとして使えるようにしてみました。

無事にgmailを独自ドメインで使えるようになり、ためしにサブドメインでホームページも表示できるようにしてみました。 http://site.arakanoj.com/testsite/

まだGoogle Appsを導入して一日も過ぎていませんが、現時点で気になった事はメールのログを見る事ができるのか？というところです。

しばらくこの Google Apps を検証していきたいと思います。

COMPUTERWORLD.JP 2011年02月16日の記事

* 1章：高信頼システムの概要
* 2章：Linuxサーバ1台の稼働率を上げる設計
* 3章：複数台のサーバによる高信頼システムの設計例
* 4章：データの共有
* 5章：データベースの冗長化
* 6章：クラスタシステムの監視
* 7章：システム監視
* 8章：ロードシェアリングによるシステムの構築
* 9章：アクティブ・スタンバイクラスタによるシステムの構築
* 10章：サーバの仮想化
* 11章：仮想サーバを構築する（Xen編）
* 12章：仮想サーバを構築する（KVM編）

現在このHPは作成途中です。
有益な情報を提供したい。
そんな思いで書いていますが、 まだまだ力不足です。
どうぞよろしく。