このブログを検索

ラベル https の投稿を表示しています。 すべての投稿を表示
ラベル https の投稿を表示しています。 すべての投稿を表示

2020/10/11

ボクボク証明書(その1)

ボクボク証明書とは、自己署名証明書ではあるがオレオレ証明書よりはすこしマシな証明書のことである。

まず、証明書について基本的なことを確認しておく。

ここでいう証明書とは、インターネットのサーバにブラウザでアクセスするときにサーバが正統(正当?)であることを証明するための証明書のことである。

昔のインターネットでは、サーバ証明書などというものは必要なかったが、次第に利用されることが増え、最近では証明書を提示しないサーバとの通信は「安全でない通信」「保護されていない通信」などと表示されるようになった。

証明書を提示する通信は、「HTTPS」と呼ばれるプロトコルを使用する。

「HTTPS」とは、SecureなHTTPという意味である。

例えばオンラインショッピングでクレジットカード情報や住所等を入力するサイトである場合、そのサーバとの通信を他者に知られないように暗号化する必要がある。

HTTPSの通信が暗号化された通信であるという認識はほとんどの人が持っているだろうが、当たり前のことであるが、暗号化するには通信相手が本当に自分の通信したい相手なのかを確認する必要がある。

暗号化しているから安心だ、と、有名サイトを装った偽のサイト、いわゆるフィッシングサイトに接続してしまわないようにする必要である。

そのためにHTTPS通信ではサーバが証明書を提示し、クライアントはその証明書によりサーバがホンモノであることを確認して初めて「保護された通信」がおこなわれるのである。

しかし皆さんはおそらく『証明書がどうこうというのは知っているけど別にそれをいちいち確認してないけど』と思っているだろう。私もそうである。

サーバーがホンモノかどうか、つまり証明書が信頼できるかどうかは、ブラウザが判断している。

何をもって正統だと判断するか。

それは、証明書の発行者を見るのである。

そして、その発行者が信頼できる発行者であれば、その証明書は信頼できるとみなすのである。

ではどうやって発行者が信頼できるとみなすのか。

それは、「信頼できる証明書発行者リスト」というものを参照するのである。

それはあなたのパソコンの中にもある。


が、疑い深い人は、まだ安心できず「その『信頼できる証明書発行者リスト』が信頼できるとどうやって判断するのか、と思うだろう。


そしてここでようやくあなたの出番である。

あなたが使うパソコンにある、「信頼できる証明書発行者リスト」が信頼できるものであると、あなたが判断すれば、それを参照しているブラウザの判断も正しいとみなす。

あなたはそんなリストを登録した覚えはない、見たことすらない、というかもしれないが、

おそらくHTTPS通信というものはそういう建前で動いている。

自分で登録していなければ、ブラウザインストール時あるいはOSインストール時(インストール済みPCであれば購入時)に登録されるリストを信頼すると、あなたが受け入れていることになっているのだ。


前置きが長くなったが、ボクボク証明書を説明するために必要な前提条件である。

さて、「オレオレ証明書」とは、「発行者が自分自身である証明書」のことである。

今回発行する証明書も自分自身で署名しているのだが、一応「信頼」してもらえる証明書になる。

そのカラクリは、先ほど説明した「信頼できる証明書発行者リスト」にある。

もうお気づきであろう。

ボクボク証明書というのは、「信頼できる証明書発行者リスト」に、あなたという証明書発行者を追加してもらうことにより、信頼できる証明書としてもらうのである。


御託はこれくらいにして、以下、実践。

以前やった時とはいろいろ変わっていたので改めて手順を書く。


apacheとopensslのバージョンは以下


# httpd -v

Server version: Apache/2.4.37 (centos)

Server built:   Jun  8 2020 20:14:33


# openssl version

OpenSSL 1.1.1c FIPS  28 May 2019


手順の流れ

1.CA証明書作成

 1-1. CAの秘密鍵作成

 1-2. CA証明書のCSR発行

 1-3. CA証明書のCSRにCAの秘密鍵を用いて署名


2.WEBサーバの証明書作成

 2-1. WEBサーバの秘密鍵を作成

 2-2. WEBサーバ証明書のCSRを発行

 2-3. WEBサーバ証明書にCAの秘密鍵を用いて署名

 2-4. Apacheの設定ファイルで発行した証明書と秘密鍵の場所を指定


3. 動作確認

 3-1. CA証明書をクライアントにインストール

 3-2. サイトにアクセス


手順

以下手順では必要に応じてカレントディレクトリを移動しているので、ファイル名を指定する箇所のパス名は実施する状況に応じて変更が必要な場合があります。

ドメイン名、ホスト名等は必要に応じて変更しているので参考程度にしてください。


1.CA証明書作成

1.1 CAの秘密鍵作成

# openssl genrsa -aes256 -out ./cakey.pem 2048

Generating RSA private key, 2048 bit long modulus (2 primes)

...................................................................................+++++

..........................................+++++

e is 65537 (0x010001)

Enter pass phrase for ./cakey.pem:(パスフレーズを入力)

Verifying - Enter pass phrase for ./cakey.pem:(パスフレーズを入力)


1.2 CA証明書のCSR発行

openssl req -new -key ./cakey.pem -out ./cacert.csr


※-keyでCAの秘密鍵ファイルを、-outで発行するCSRファイルを指定する。


# openssl req -new -key ./cakey.pem -out ./cacert.csr

Enter pass phrase for ./cakey.pem:(CAの秘密鍵のパスフレーズを入力)

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) [XX]:JP

State or Province Name (full name) []:Tokyo

Locality Name (eg, city) [Default City]:Shinjuku

Organization Name (eg, company) [Default Company Ltd]:

Organizational Unit Name (eg, section) []:

Common Name (eg, your name or your server's hostname) []:ca.monqy.net

Email Address []:


Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

最後のチャレンジパスワードは書いてあるようにextraの設定なので入れなくてもよい。


1.2 CA証明書のCSRにCAの秘密鍵を用いて署名

# openssl x509 -days 825 -in ./cacert.csr -req -signkey ./cakey.pem -out ./cacert.pem

Signature ok

subject=C = JP, ST = Tokyo, L = Shinjuku, O = Default Company Ltd, CN = ca.monkey.net

Getting Private key

Enter pass phrase for ./cakey.pem:(CAの秘密鍵のパスフレーズ)


2.WEBサーバー証明書作成

以下が前提である。

opensslの設定ファイルの場所: /etc/pki/tls/openssl.cnf

openssl.cnfの設定

default_ca = CA_default
dir = /etc/pki/CA     

CAの秘密鍵の保存ディレクトリ: /etc/pki/CA/private/cakey.pem

WEBサーバ証明書等の保存ディレクトリ: /etc/pki/SSL


2.1 WEBサーバーの秘密鍵作成

# openssl genrsa -aes256 -out ./serverkey.pem 2048

Generating RSA private key, 2048 bit long modulus (2 primes)
............................................................................+++++
................+++++
e is 65537 (0x010001)
Enter pass phrase for ./server.key:(パスフレーズを入力)
Verifying - Enter pass phrase for ./server.key:(確認のためパスフレーズを再入力)


これはCAの秘密鍵を作ったときと全く同じことをしている。


2.2 WEBサーバーのCSR作成

[root@jesus SSL]# openssl req -new -key ./server.key -out ./server.csr

Enter pass phrase for ./server.key:(WEBサーバーの秘密鍵のパスフレーズ)

140637670844224:error:28078065:UI routines:UI_set_result_ex:result too small:crypto/ui/ui_lib.c:903:You must type in 4 to 1023 characters

Enter pass phrase for ./server.key:(WEBサーバーの秘密鍵のパスフレーズ)

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) [XX]:JP

State or Province Name (full name) []:Tokyo

Locality Name (eg, city) [Default City]:Xxxxx

Organization Name (eg, company) [Default Company Ltd]:

Organizational Unit Name (eg, section) []:

Common Name (eg, your name or your server's hostname) []:*.monqy.net

Email Address []:


Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:


これもCAと同じことをしている。指定する秘密鍵がWEBサーバのものであることと、Common Nameが違うだけである。

Common Nameは *.monqy.net としているが、
こうしておくとホスト名が変わっても同じ証明書が使えるそうである。

たとえば、www.monqy.net でも www2.monqy.net でも、というように。


Common NameはCNと略され、サーバにアクセスするときのfqdnである必要がある。
fqdnとCNが異なっていると正しい証明書とみなされない。
さらに、今はCNがfqdnと一致しているだけでなく、もう一か所別の設定でもfqdnを記述する必要がある。
(後述)



---------------------------------------------
(追記)
openssl.confの設定により場所が異なるが、下記ファイルが必要

index.txt
serial.txt

今やったのだと /etc/pki/CA

index.txt はあれば中身がなくてもよいが
serial.txt は4桁の数字が書いてある必要があるらしい
今やったのは 0001 で成功した。
1  だけだと失敗する
-----------------------------------------

2.3 WEBサーバ証明書にCAの秘密鍵を用いて署名

以下のように書いたテキストを作る(san.txtとする)

subjectAltName=DNS:www.monqy.net

そして、署名の際に最後に以下のようなオプションを付けて署名する。
-extfile san.txt


openssl ca -config /etc/pki/tls/openssl.cnf -in /etc/pki/SSL/server.csr -keyfile /etc
/pki/CA/private/cakey.pem -cert /etc/pki/CA/cacert.pem -out server.crt -extfile san.txt
Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for /etc/pki/CA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 0 (0x0)
        Validity
            Not Before: Oct 11 01:25:48 2020 GMT
            Not After : Oct  9 01:25:48 2030 GMT
        Subject:
            countryName               = JP
            stateOrProvinceName       = Tokyo
            organizationName          = Default Company Ltd
            commonName                = *.monkey.net
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
                31:D5:35:FC:B3:F9:6F:F0:29:84:47:4A:7C:B5:CB:8F:67:D0:26:2A
            X509v3 Authority Key Identifier:
                DirName:/C=JP/ST=Tokyo/O=Default Company Ltd/CN=*.monkey.net
                serial:5C:C5:FC:36:68:EF:F0:0A:CF:AF:DE:75:E5:1E:E6:4B:83:68:2C:38

Certificate is to be certified until Oct  9 01:25:48 2030 GMT (3650 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

確認が2回来るのでyを入力する。
有効期間が10年間になっているが、デフォルトは1年である。

openssl.cnfの下記の設定で変更できる。
default_days   = 3650


-extfileで指定した「subjectAltName」であるが、最近はCNだけではなくこちらも見るようである。

これをやらないとchromeでは NET::ERR_CERT_COMMON_NAME_INVALID のエラーになる。

(参考)
https://www.pistolfly.com/weblog/2017/06/chrome%E3%81%A7-neterr_cert_common_name_invalid-%E3%82%A8%E3%83%A9%E3%83%BC.html

ここの記述によると、最近のchromeはcnは観ずにSANのみを見るらしい。


2-4. Apacheの設定ファイルで発行した証明書と秘密鍵の場所を指定

/etc/httpd/conf.d/ssl.conf


ServerName www.monqy.net:443

SSLProtocol all -SSLv3

SSLCertificateFile /etc/pki/SSL/server.crt

SSLCertificateKeyFile /etc/pki/SSL/server.key


ServerNameのfqdnがあっていることも確認

httpd再起動




3.動作確認

3.1 CA証明書のインストール

CA証明書をクライアント(Windows10)にダウンロードし、拡張子 .crt にして保存する。

/etc/pki/CA/cacert.pem
↓
ca.crt

ca.crtをダブルクリックすると証明書の内容が表示される。
「証明書のインストール」をクリックし、「ローカルコンピューター」「信頼されたルート証明機関」にインストールする。

※ここでなくてもよいかもしれないが、ここにインストールして確認した。

3.2 ブラウザでアクセス

Chrome, Edge, FireFoxでかくに...!!!

FireFoxでは信頼されない!!

「誰かがこのサイトに偽装しようとしている可能性があります。続行しないでください。
 
ウェブサイトは証明書で同一性を証明します。証明書の発行者が不明、証明書が自己署名、またはサーバーが正しい中間証明書を送信していないため、Firefox は www.monqy.net を信頼しません。
 
エラーコード: SEC_ERROR_UNKNOWN_ISSUER」



chromeとedgeで問題なかったので、念のためFireFoxでも見ておくかと思ったらこのザマだ。


エラーメッセージについて調べると、単にCA証明書が見つからないというだけのようだ。
FireFoxは例の「信頼されたルート証明機関」を見ていないのか?

「オプション」「プライバシーとセキュリティ」「証明書」「証明書を表示...」
「認証局証明書」に認証局証明書の一覧がある。

今回作成してインストールした証明書はない。
FireFoxは独自の場所に信頼するCA証明書のリストを持っているようだ。

ここに今回作成したCA証明書をインポートしてから接続すると、
ブラウザにエラーは表示されなくなった。

しかし、証明書を表示すると「Mozillaが承認していない発行者の証明書で検証された接続です」と表示される。

これも消したいな...




2019/07/27

公開鍵と秘密鍵のどちらで暗号化するのか

先日受けた安全確保支援士試験で公開鍵か秘密鍵かを選ぶ問題があった。

あまり自信がなかったので翌日WEBで検索していたら、自分の回答が間違っている、と愕然とした。

公開鍵暗号方式とは、暗号通信をおこなうときの受信者が、暗号化するデータを送信する相手に対し公開鍵を送付し、送信者はその公開鍵を用いてデータを暗号化して送信し、受信者は秘密鍵でそれを復号する方式である。

昨日の試験で、私は「秘密鍵は公開できないからそれで復号できない」と考えたことを覚えていたのだが、公開鍵で復号できるのなら暗号化の意味がないではないか!

しまった!

しかも、同じような問題が2回出ていて同じように考えた。

これを全部間違えていたとしたら、もうアウトだ。

というか、そもそもこんな単純なことを理解していないようではたとえ合格してもセキュリティの専門家を名乗ることはできない...

検索すると「秘密鍵で暗号化するという間違った解説が蔓延している」という記事がいくつも出てきた。

...が、さらによく調べると、「秘密鍵で暗号化(この言い方は微妙なのでカッコをつける)」する場合もあるらしかった。


そして、問題を見直してみると、

「xxxを用いて署名を作成」
「xxxを用いて署名を検証」

となっていた。

2か所ともに。


これは公開鍵暗号化ではなく、デジタル署名の話だ。
だから、署名を作成するのに用いるのは秘密鍵で、検証するのは公開鍵であっている。


でも私は、「公開鍵で復号(検証)できてしまったら意味がないのでは?」
という疑問を抱くこともなかったので、
たとえ合格していてもあまり胸をはって「俺は安全確保支援士だ」と言うことはできない。


デジタル署名において秘密鍵を用いて署名を作成することを、「秘密鍵で暗号化」というのは厳密には正しくないらしいが、
よくわからない。
私が信頼していてよく参考にしているWEBサイトでもそういう言い方がされている。

https://www.ipa.go.jp/security/pki/024.html

IPAのデジタル署名を説明したサイトにも、「生成したダイジェストを自分の秘密鍵で暗号化します。」という記述がある。



公開鍵、秘密鍵、証明書、署名...

これらについての説明は何度も何度も聞いた(読んだ)ことがある。
が、何度聞いても、当たり前すぎるような、なんとも腑に落ちない感じがあった。

暗号化というのは他人に内容を知られないように、何かを書き換えることである。
そして、当然、それは読むことを期待する相手には解読(復号)できなければならない。

私たちがよくやるのは、データを暗号化し、パスワードをかけることだ。
そして、そのパスワードを相手に伝える。

メールの添付ファイルをパスワード付きzipで圧縮して、
後からそのzipファイルの解凍パスワードを送信する、というのはよく見る光景である。
私もよくやる。

その際によく言われるのが、「ファイルを添付したメールにパスワードを記載するな」ということである。

それは宛先を誤った場合に他者にファイルを解凍されてしまうからだ。


この方式は、方式というほどのことではないくらいの簡単な方式だが、「共通鍵暗号」方式という。

私がそうなのだが、暗号化なんてこれしか方法がないんじゃないかと考える人が多いのではないだろうか。

しかし、これもすぐ気づくことであるが、共通鍵暗号方式では共通鍵を他者に知られないように、通信相手に渡す必要がある。


解読するための鍵をさらに暗号化しても、やっぱりそれを復号する鍵が必要になり、
何重に鍵をかけようと、この課題はついて回る。

その課題を解消するのが公開鍵暗号方式である。


公開鍵暗号方式では、暗号化する鍵と復号化する鍵をペアで用意する。

このとき重要なのは、二つの鍵はそれぞれ暗号専用、復号専用であるだけでなく、
当然かもしれないが、ペアになっている、ということである。

つまり、Aさんの公開鍵で暗号化したデータを、Bさんの秘密鍵では復号できない。

そしてもう一つ、復号化する鍵を他者に渡してならないことは誰にでもわかるだろう。

だがそれと同じくらい重要なのが、暗号化するために、データの送信者に対して、
受信者が公開鍵を渡さなければならないということである。

そして、そのためにさらに次の重要事項が発生する。
それは、公開鍵の内容は他者に知られてもかまわないが、
その公開鍵が暗号化したデータを送信したい相手の鍵であるかを確認しなければならない、
ということである。


物理的な鍵でたとえたいのだが、「開けるときと閉めるときで違うカギを使う」
という実例はないだろうか?

よく、南京錠の絵を使って、閉めることだけができる鍵、開けることだけができる鍵、
などと説明されるが、そんな物理的鍵はこの世に存在しない...

と思って検索してみたら、「投函できるが自分は鍵をもっていないポスト」と言っている人がいた。

なるほど、これに似ている。


誰でもポストに郵便物を投函できるが、ポストを開けることはできない。
しかし郵便物は相手に、相手だけに届かなければならない。

我々がポストに郵便物を投函するのは、それが郵便ポストであり、
それを開けて配達する郵便配達員を信頼しているからである。

公開鍵を送るというのは、ポストを設置するような行為だ。

我々はポストがポストであることを、真っ赤であるとか「ポスト」と書いてあるかとかいう程度でしか確かめないが、

電子的に暗号通信、つまり鍵(ポスト)と暗号文(郵便物)を交換する際には、第三者に証明するという方法を使っている。


その一つが、HTTPS通信で使用されるサーバ証明書である。

我々はサーバ証明書を見てそれが信頼できる発行者が発行したものであることを確認してアクセスする。
(実際にはブラウザが証明書の正当性を検証し我々はその結果を信頼している)

HTTPサイトにアクセスすると提示される証明書には公開鍵が含まれている。
アクセスする者は公開鍵を受け取り、それを使ってデータを暗号化して通信する。

そして、送信先のHTTPSサイトだけが、その暗号化したデータを復号できる。



2019/06/22

さくらのVPSを1台解約するにあたって移行

2台もいらない。
低スペックの方を残す。

よく使うcgiと、メールと、twitter botと、それぐらいしか使わないから。

centos6からcentos7への移行となる。

途中で気づいたがpythonも2.7から3.6の移行となる。

python3系にするとyumでエラーになる。
yumは2系を前提としているからだ。

/bin/yum
を直すのは以前にもやった。

mod_sslをインストールしようとしたら、

Downloading packages:
  File "/usr/libexec/urlgrabber-ext-down", line 28
    except OSError, e:
                  ^
SyntaxError: invalid syntax

なんてエラーも出たので
/usr/libexec/urlgrabber-ext-down
も直す。

こんなことでいいのかな。

以前centos6でやったhttpsを使う設定をしていき、
最後にfirewallで443を開けるところまで来て、
そういえば7はiptableじゃない....

いまどうなってるかな...
firewall-cmd --list-all-zones

とやると、エラーになる。
これもpython2系にしないとダメだ。

どいつもこいつもpythonを使っていて、しかも2系なんだな...
3系にするのは先走りなのか...

サービスで開ける。

firewall-cmd --add-service=https --zone=public
firewall-cmd --add-service=https --zone=public --permanent
firewall-cmd --reload

終わり。


2019/04/27

HTTP通信が安全でない理由


前回のエントリ

で実行したcgiが、もしHTTP通信で実行されていたら、
その通信をキャプチャすると下記のように入力したパスワードがわかる。


これが「暗号化されていない通信(HTTP)は危険」である理由である。

「キャプチャすると通信内容がわかる」ということは、その通信が経由する装置、回線、サーバ、等にアクセスできる人々すべてに内容を把握されるおそれがあるということである。

これを防ぐためには、「暗号化」が必要である。

暗号化していない通信であれば、パスワードそのものでなくハッシュを保存していたとしても、サーバ管理者もユーザが入力したパスワードを知ることができてしまう。


2016/09/17

apacheでhttpsを使う

httpsを使いたい。

別にセキュアにしたいわけではなく、httpsでのアクセスを確認したいだけ。

macでやってみて証明書も自分で発行できて簡単でopensslとかならcentosも同じだろうと、やってみた。

ちょっとゴタゴタしたので、メモしておく。

# which openssl
/usr/bin/openssl

opensslは入っている。


# which mod_ssl
/usr/bin/which: no mod_ssl in (/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin)

mod_sslは入ってない。

じゃあ、入れよう。

# yum install mod_ssl
読み込んだプラグイン:fastestmirror, refresh-packagekit, security
インストール処理の設定をしています
Loading mirror speeds from cached hostfile
 * base: ftp.iij.ad.jp
 * epel: ftp.iij.ad.jp
 * extras: ftp.iij.ad.jp
 * remi-safe: mirrors.tuna.tsinghua.edu.cn
 * updates: ftp.iij.ad.jp
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> Package mod_ssl.x86_64 1:2.2.15-54.el6.centos will be インストール
--> 依存性の処理をしています: httpd = 2.2.15-54.el6.centos のパッケージ: 1:mod_ssl-2.2.15-54.el6.centos.x86_64
--> 依存性解決を終了しました。
エラー: パッケージ: 1:mod_ssl-2.2.15-54.el6.centos.x86_64 (updates)
             要求: httpd = 2.2.15-54.el6.centos
            インストール: httpd-2.2.27-1.el6.x86_64 (@CentALT)
                httpd = 2.2.27-1.el6
            利用可能: httpd-2.2.15-53.el6.centos.x86_64 (base)
                httpd = 2.2.15-53.el6.centos
            利用可能: httpd-2.2.15-54.el6.centos.x86_64 (updates)
                httpd = 2.2.15-54.el6.centos
 問題を回避するために --skip-broken を用いることができません
 これらを試行できます: rpm -Va --nofiles --nodigest


入らない。

apacheのバージョンが新しすぎるようだ。

別にバージョンなんかなんでもいいので、ダウングレードしよう。


yum downgradeをやってみたができないので、消して入れなおす。

# yum remove httpd

消えた。

インストール

# yum install httpd
読み込んだプラグイン:fastestmirror, refresh-packagekit, security
インストール処理の設定をしています
Loading mirror speeds from cached hostfile
 * base: ftp.iij.ad.jp
 * epel: ftp.iij.ad.jp
 * extras: ftp.iij.ad.jp
 * ius: hkg.mirror.rackspace.com
 * remi-safe: mirrors.tuna.tsinghua.edu.cn
 * updates: ftp.iij.ad.jp
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> Package httpd.x86_64 0:2.2.15-54.el6.centos will be インストール
--> 依存性の処理をしています: httpd-tools = 2.2.15-54.el6.centos のパッケージ: httpd-2.2.15-54.el6.centos.x86_64
--> 依存性解決を終了しました。
エラー: パッケージ: httpd-2.2.15-54.el6.centos.x86_64 (updates)
             要求: httpd-tools = 2.2.15-54.el6.centos
            インストール: httpd-tools-2.2.27-1.el6.x86_64 (@CentALT)
                httpd-tools = 2.2.27-1.el6
            利用可能: httpd-tools-2.2.15-53.el6.centos.x86_64 (base)
                httpd-tools = 2.2.15-53.el6.centos
            利用可能: httpd-tools-2.2.15-54.el6.centos.x86_64 (updates)
                httpd-tools = 2.2.15-54.el6.centos
            利用可能: httpd24u-tools-2.4.23-2.ius.centos6.x86_64 (ius)
                httpd-tools = 2.4.23-2.ius.centos6
 問題を回避するために --skip-broken を用いることができません
 これらを試行できます: rpm -Va --nofiles --nodigest


できない。

httpd-toolsとやらがひっかかってる。

こいつも消す。



# yum remove httpd-tools
読み込んだプラグイン:fastestmirror, refresh-packagekit, security
削除処理の設定をしています
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> Package httpd-tools.x86_64 0:2.2.27-1.el6 will be 削除
--> 依存性解決を終了しました。

依存性を解決しました

========================================================================================================================
 パッケージ                    アーキテクチャ           バージョン                     リポジトリー                容量
========================================================================================================================
削除:
 httpd-tools                   x86_64                   2.2.27-1.el6                   @CentALT                   137 k

トランザクションの要約
========================================================================================================================
削除                 1 パッケージ

インストール済み容量: 137 k
これでいいですか? [y/N]y
パッケージをダウンロードしています:
rpm_check_debug を実行しています
トランザクションのテストを実行しています
トランザクションのテストを成功しました
トランザクションを実行しています
  削除中                  : httpd-tools-2.2.27-1.el6.x86_64                                                         1/1
  Verifying               : httpd-tools-2.2.27-1.el6.x86_64                                                         1/1

削除しました:
  httpd-tools.x86_64 0:2.2.27-1.el6

完了しました!


「will be 削除」(笑い)


インストール

#yum install httpd

はいった。



# httpd -v
Server version: Apache/2.2.15 (Unix)
Server built:   Jul 18 2016 15:24:00


mod_sslをインストール

# yum install mod_ssl

はいった。


「will be インストール」(笑い)



これで必要なものはそろったので設定をしていく。


httpsサーバを動かすには証明書が必要。

証明書といっても、テストでhttpsアクセスするだけならお金を払って発行してもらう必要はない。

そういう場合は自己署名証明書というものを使う。

いわゆる「オレオレ証明書」である。


(参考)
http://www.maruko2.com/mw/Apache/SSL%E8%87%AA%E5%B7%B1%E8%A8%BC%E6%98%8E%E6%9B%B8%E3%81%AE%E4%BD%9C%E6%88%90%E3%81%A8mod_ssl%E3%81%AE%E8%A8%AD%E5%AE%9A


apache + ssl 設定の方法はいろんな人が書いているが、内容は微妙に異なる。



秘密鍵を作る。

よくわからないが、これがないと証明書が作れないし、簡単に作れるので作る。

暗号の強度とかはどうでもいいがいまどき 3desとか1024は古いのでナウくする。

パスワードを要求されるので2回入力する。

# openssl genrsa -aes128 -out server.key 2048
Generating RSA private key, 2048 bit long modulus
...............................................................................................................................................................................................................................+++
..............................................................................+++
e is 65537 (0x10001)
Enter pass phrase for server.key:
Verifying - Enter pass phrase for server.key:


CSRを作る。

CSRとは証明書を発行する元ネタのようなものだ。
国だの組織名だのいろいろ聞かれるが全部適当でよい。

challenge password、emailだのは入れなくてよい。
というか、確認してないが必須項目はCNのみじゃないだろうか。

CNとはサーバのfqdnだが、自己署名証明書なので一致してなくても関係ないと思う。

一応、本当のfqdnを登録した。

下記のkintamaはもちろんサンプルである。


# openssl req -new -key server.key -sha256 -out server.csr
Enter pass phrase for server.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:JP
State or Province Name (full name) []:Tokyo
Locality Name (eg, city) [Default City]:Tokyo
Organization Name (eg, company) [Default Company Ltd]:kintama
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:kintama.net
Email Address []:

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


秘密鍵とCSRがそろったら、証明書を発行する。

有効期間10年。100年とか1000年とかでもできるのだろうか?確認してない。

-in に作成したcsr、 -signkey に作成した秘密鍵の名前を指定する。

-out で指定した名前で作成される。


秘密鍵を作ったときに設定したパスワードを入力する。


# openssl x509 -in server.csr -days 3650 -req -signkey server.key -sha256 -out server.crt
Signature ok
subject=/C=JP/ST=Tokyo/L=Tokyo/O=kintama/CN=kintama.net
Getting Private key
Enter pass phrase for server.key:


証明書ができたら、ssl.confを編集する。

(参考)
http://www.ryouto.jp/linux/linux_44.html


vi /etc/httpd/conf.d/ssl.conf

変更するのは以下

DocumentRoot "/var/www/html/" #コメントを外す
ServerName kintama.net:443 #サーバ名
SSLCertificateFile /home/kintama/ssl/server.crt #コメントを外して証明書の場所を指定
SSLCertificateKeyFile /home/kintama/server.key #コメントを外して秘密鍵の場所を指定



DocumentRootは任意の場所を指定できる。

つまり、httpとhttpsで違うページを表示できる。

証明書と鍵はさっき作成したものを指定する。

場所と名前はなんでもよいがもちろんそこに先ほど作った秘密鍵と証明書がないとだめだ。



httpdを再起動する。

さっき設定したパスワードを入力する。

# service httpd restart
httpd を停止中:                                            [  OK  ]
httpd を起動中: Apache/2.2.15 mod_ssl/2.2.15 (Pass Phrase Dialog)
Some of your private key files are encrypted for security reasons.
In order to read them you have to provide the pass phrases.

Server kintama.net:443 (RSA)
Enter pass phrase:

OK: Pass Phrase Dialog successful.
                                                           [  OK  ]

iptablesで443を開ける。

-A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT


おわり。


おまけ

httpdを再起動するたびにパスワードを入力するのがウザい場合は、
下記で無効にできる。

# openssl rsa -in server.key -out server.key
Enter pass phrase for server.key:
writing RSA key

無効にするときにパスワードを聞かれてイラっとするが、これが最後なので我慢する。

centosは6です。

正式なバージョンは.....

# cat /etc/redhat-release
CentOS release 6.8 (Final)