ブラウザとサーバー間の暗号化プロトコル
であるSSL(TLL)のお話です。
ECサイトなどの個人情報をやり取りするときは
httpではなく、https（鍵マーク付き）の暗号化
通信で行うことは常識ですが、最初に出たときは
ブラウザとサーバー間の暗号化プロトコルは
SSL（セキュアソケットレイヤー）というものでした。
実はこのSSL、バージョンが1.0から2.0、そして
3.0と開発改良されましたが、その間致命的な
な脆弱性が見つかったり、設計を根本から見直す
必要性に迫られたため、SSL4.0は開発されず、
まったく新しい仕組みを持ったTSL1.0に変更
されてしまいました。
ですから、本来はTLS（トランスポートレイヤー
セキュリティ）と呼ぶはずなのですが、拙生を含め
いまだに慣れ親しんだSSLと言ってしまいます。
現在においては、よく見るTLS/SSLやSSLの実態は
ほぼ間違いなくTLSになります。
ただしOpenSSL含め、いまだに慣習でSSLという
呼称が定着しているので、記述にSSLとあれば、
TSLと読み替えていただければ幸いです。
（TLS/SSLは苦肉の策かな？ｗ）
httpsでリクエストするだけ
以下SSLについて簡単に説明していきますが、
簡単とは言え3行で書けるものではありません。。。
しかし仕組みは意識しなくとも、ユーザーは
ブラウザのアドレスバーからhttpではなく
httpsでリクエストすれば、そのドメインが
安全な暗号化通信が確保されるのかは、
OSやブラウザとサーバー間の仕組みの中で
勝手に判断してくれるので、決して面倒な
ことはありません。
以下、意識しなくても大丈夫だけども
面倒くさい仕組みを極力簡潔化して
書いてみます。ｗ
お断り
あくまでこれを書いた時点での拙生の知識や認識であり、
更に簡単に書くために無理やりかみ砕いているので、
舌足らずだったり、最近新しく開発された仕組みが
組み入れられたりすれば、説明に齟齬が生じるかも。。。
もちろん拙生のことですから、大きな勘違いも
あるかと思いますので、間違いがあればご指摘
いただければ幸いです。
暗号化通信
ECサイトの決済など、個人情報を扱う通信において、
SSLプロトコルを採用することで、通信の暗号化が
確保されます。
個人情報を扱うECサイトの決済などには必須の
プロトコルとなります。
それだけでよい？
では通信が暗号化されているだけで安心でしょうか。
それだけでは通信中の情報を悪意のある第三者に
盗み見られても解読できないということだけです。
アクセスしているECサイトが正規なものであるとか、
運営会社が実在している、などが保証されなければ
フィッシング詐欺に使用するサイトの可能性もあり
安全とは言えないでしょう。
そのためSSLは暗号化だけではなく、セキュリティ
向上のために、3段階の電子認証を組み入れており、
それは以下の3種類になります。
１ ルート証明書
２ 中間証明書
３ サーバー証明書
クライアント側
SSL認証が信頼おけるものか判断する機能は、
WindowsやMacOSなどのOSの証明書ストアに
保管されていて、MirosoftEdgeやChromeなどの
ブラウザは、OSの情報を参照して判断します。
証明書の確認はOSでもブラウザからもできます。
ただし拙生が使っているFirefoxだけ(?)は、
独自の基準を抱いているため、極々稀ですが
Chromeでは閲覧可能なのに、Firefoxでは
警告が出る、なんてサイトもありますが。。。
証明書確認の例
Windows11
検索欄からcertmgr.msc開く。
MicrosoftEdge
その他のツール➡インターネットオプション
➡コンテンツ➡証明書
Firefox（独自の基準）
設定➡プライバシーとセキュリティ
➡証明書の証明書を表示
OS・ブラウザには安全の基準が設けられていて、
証明書はその基準を満たすか厳格な調査が行われ、
基準を満たしたときだけ信頼できるルート証明書
として証明書ストアに保管されます。
保管した情報にないものや一致しないものは
信頼できないとか危険という警告を表示します。
ルート証明書
ルート証明書とは、最上位となるルート証明機関が
発行するCA証明書になります。
このように世界的な認証局監査の厳びしい規準を
クリアーしたものをパブリック認証局と呼びます。
中間証明書
さらに自力で信頼性を担保できないため、
上位のルート証明機関による署名で成り立つのが
中間証明機関などの下位証明機関であり
発行されるのが中間証明書と言うCA証明書になります。
パブリック認証局に対して自社の規準で認証する
中間証明機関は、プライベート認証局と呼びます。
ここまでがhttpsでのリクエストに対して、勝手に
安全を判断してくれる仕組みです。
以降はサイト運営者が使用ドメインに対して、
認証局からお墨付きをもらう仕組みです。
＊社内だけがアクセスするサイトなどは、自前で
認証局を立ててOSに登録もできますが、ここでは
省きます。
サーバー側
サイトに暗号化通信（https）を導入するには
暗号化に必要な鍵と、サイトの使用ドメインに対する
安全性や運営者情報などが含まれたサーバ証明書を
インストールしなければなりません。
サーバー証明はOSやブラウザに登録されている
パブリック・またはプライベート認証局に
申請して発行してもらいます。
証明は厳格さにより3段階あります。
１ DV(Domain Validation ) 証明書
２ OV(Organization Validation)証明書
３ EV(Extended Validation)証明書
基本は１のDVですが、これは申請人が申請された
ドメインをちゃんと管理しているのかどうかの
確認ができれば発行してもらえるというものです。
確認方法はそのドメインでメールアドレスを作成して
メールのやり取りをするとか、webサイトに
認証局から送られたテキストを表示させるなどの、
方法がありますが、それにより確かにそのドメインを
管理していると判断できることになります。
２のOVはドメイン管理だけでなく、運営組織の
実在を電話や郵便などで確認して証明書を発行します。
３のEVは更に厳しく、運営組織の実在を、国際基準に
沿って厳格に確認します。
もちろん厳格さにより掛かるコストが違います。
大規模なECサイトだけでなく、大企業のサイトは
自社サイトである信頼性を得るために、多額の
コストを掛けて２や３でサイト運用をする場合が
ありますが、小規模なECサイトや、個人情報を
やり取りするメールフォームなどがある場合は
1のみの証明書で運用しているサイトが多いです。
このサイトもMailmeとかバックグラウンドでは
個人情報を扱うため、ドメインバリデーションで
認証を取っているので、https://oba-q.comで
アクセスしても、安全なサイトとして表示されます。
お値段
2のOVや3のEVは高価です。
価格は様々ですが、EVで安いところでも10数万円。。。
個人サイトには無理厳しい価格で、大企業大がかりな
ECサイトや、運営組織の実在をアピールする大企業が
採用していますので、貧乏サイト管理者としては
DVのみについて書くことにします。。。ｗ
DV（ドメインバリデーション）は探せば年千数百円
などという格安のものがあります。
このサイトでも書いている時点で年1,600円くらいの
ものを使っています。
やっと出てきますがサーバーに表題のOpenSSLを
インストールすると、秘密鍵と一緒に認証局に
申請するためのCSRを作成することができます。
CSRはドメイン名に対し、その所在地や組織名、
連絡先メールなどの情報を付加して作成します。
CSRで申請すると、送った情報と有効期限が
反映されたサーバー証明が発行されます。
格安のSSL証明はほぼプライベート認証局に
よるものなので、中間証明書も一緒に送られて
きていました。
それを所定の位置に保管しておくことになります。
ページ末尾にやり方の一例を書いておきます。
無料でもできる！
ドメインだけの認証であれば、無料で発行して
くれるところもあります。
無料だからと言って暗号化の強度が低いわけでは
ありません。
AlmaLinux使用の拙生の環境でLet’s Encryptという
代表的な無料の証明書をインストールするには、
WebサーバーのApacheやOpenSSL、mod_sslが
導入されていれば、certbotをインストールするだけ。
あとは１行のコマンドですべての証明書が作成され
所定の位置に保管されるので、自身でセットする
手間もなく、イタツク（至れり尽くせりの略。）
なのです。。。ｗｗｗｗ
後はApacheの設定ファイルに証明書の所在を追記。
ただし有料のものは有効期限1年のところ、３ヶ月
しかないので、３ヶ月ごとの期限を自動更新する
設定を行えば完璧です。
これもページ末尾にやり方を載せています。
##########################################
格安SSL証明書をWeb上から申し込み認証を得る
（参考 http://define.jp/ 年1000円ちょっと！）
環境 AlmeLinux（書いた当時はCentOS)
openssl mod_ssl
例は ドメイン hogehoge.com
秘密鍵（プライベートキー）hoge.key
CSR hoge.csr
パスフレーズ harehore123
プライベートキーを作成
キー保管場所に移動
#cd /etc/pki/tls/private
キー作成
#openssl genrsa -des3 -out hoge.key 2048
パスフレーズを訊かれるので
harehore（例）を2回入力する。
ここでのパスフレーズは後から
重要になるので、忘れないように。
プライベートキーを基に
証明書署名要求（CSR）
を作成
# openssl req -new -key hoge.key -out hoge.csr
Enter pass phrase for hoge.key:harehore123 ←パスフレーズ
（以降情報を記入－記入箇所太字）
Country Name (2 letter code) [XX]:JP ←日本はJP
State or Province Name (full name) []:HOKKAIDO ←都道府県名
Locality Name (eg, city) [Default City]:SAPPORO ←市町村名
Organization Name (eg, company) [Default Company Ltd]:Hoge Co.,Ltd.
↑組織名
Organizational Unit Name (eg, section) []:IT ←部署名
Common Name (eg, your name or your server’s hostname) []:hogehoge.com
↑ドメインやホスト名
Email Address []:info@hogehoge.com ←届くメール
Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []: ←そのままEnter
An optional company name []: ←そのままEnter
これで /etc/pki/tls/private/配下にhoge.csrが作成される。
申込
Ｗｅｂ上での申し込み段階で、csrの内容を貼り付ける手順がある。
#cat /etc/pki/tls/private/hoge.csr
表示されたものを貼り付ける。
こんな感じのやつ
—–BEGIN CERTIFICATE REQUEST—–
MIIBzTCCATYCAQAwgYwxCzAJBgNVBAYTAkpQMREwDwYDVQQIDAhIb2trYWlkbzEQ
MA4GA1UEBwwHU2FwcG9ybzEYMBYGA1UECgwPQ29tc29uIENvLixMdGQuMQswCQYD
VQQLDAJJVDESMBAGA1UEAwwJY29tc29uLmpwMR0wGwYJKoZIhvcNAQkBFg5pbmZv
QGNvbXNvbi5QcDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwjN8UHRGWYNt
3oqW21T1YumikFMPJCtgeg1SEc9GMVCO45rfI/tAH6jv8MLXj25URMMuyG5evz94
wP4WJDKLAmJOpgHqRUeLII/WwL/jKQvGnVwvER1x8W1OmIyLjfLAgFFBSwurldJX
Hq2G3E0D0kF1vaChPoD1aQPys7VP6gMCAwEAAaAAMA0GCSqGSIb3DQEBBQUAA4GB
AK0PNoTF+EAbwW0UuP1Q3jf2+DkfHZSBq7vt9zKuhQBXpvQAbGbbt3btirayLNHE
ickkeCDQ7vyem4mE/6gfRkhlrL5lGIJOFpOCa6Wo0Tq2+qsQWeEGbTYYg2K5VPtw
SKGO2kKBzigutPg2S4OpMPj1BDHHnmTE40I5bhPxdp0h
—–END CERTIFICATE REQUEST—–
（本物ではありません。アレンジが入ってます。）
CRTが発行された旨のメールが届くので、メールから
コピーし貼り付ける。
#vi /etc/pki/tls/certs/hoge.crt
メールで送られてきたものをペースト。
一緒に送られてくるか指定サイトでダウンロードした
中間証明書（例としてca.crt）を/etc/pki/tls/certs/
下に保管。
これらのファイルの置き場をssl.confで指定
# vi /etc/httpd/conf.d/ssl.conf
### 行頭に#はコメント行となります。
######### 基本設定（ディフォルトのまま）###########
LoadModule ssl_module modules/mod_ssl.so
Listen 443
SSLPassPhraseDialog builtin
SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout 300
SSLMutex default
SSLRandomSeed startup file:/dev/urandom 256
SSLRandomSeed connect builtin
SSLCryptoDevice builtin
####### hogehoge.com #############################
DocumentRoot “/home/hoge/public_html”
ServerName hoge.com:443
ErrorLog /var/log/httpd/ssl_error_log
TransferLog /var/log/httpd/ssl_access_log
LogLevel warn
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLCertificateFile /etc/pki/tls/certs/hoge.crt
SSLCertificateKeyFile /etc/pki/tls/private/hoge.key
SSLCACertificateFile /etc/pki/tls/certs/ca.crt
SSLOptions +StdEnvVars
SSLOptions +StdEnvVars
SetEnvIf User-Agent “.*MSIE.*” \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
CustomLog logs/ssl_request_log \
“%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \”%r\” %b”
##########################################################
httpdを再起動しますが、このままだと
（システムを含む）再起動時に、設定した
パスフレーズを尋ねられます。
—————————————————————
サーバー機及びHTTPD再起動時、パスフレーズを
尋ねられない設定にする
#cd /etc/pki/tls/private
#/usr/bin/openssl rsa -in hoge.key -out hoge.key
# パスフレーズ入力
（再起動時、パスフレーズを尋ねられないが
その分セキュリティは甘くなります。）
—————————————————————–
httpdを再起動します。
# systemctl restart httpd.service
サイトを確認します。
https://hogehoge.com に鍵のマークが付いて
警告が出なければOKです。
＊上記記入例ではhogehoge.comにしか
有効ではありません。
www.hogehoge.comやshop.hogehoge.comなども
有効にしたい場合は Wildcardを申し込みまが
いきなり高くなります。（1万円/年以上とか）
＊実在証明（運用者情報）の証明はされません。
##########################################
無料のLet’s Encryptを試す
環境は上記同様
AlmeLinux
openssl
mod_ssl
例も上記同様
ドメイン hogehoge.com
秘密鍵（プライベートキー）hoge.key
パスフレーズ harehore
CSRは必要なし
certbotをインストール
# dnf install epel-release
# dnf install certbot
次に対話型で進みます。
# certbot certonly –webroot -w /home/hoge/puburic_html/ -d hogehoge.com
# 初回のみメールアドレスの登録と利用条件に同意
# 実際に届くメールアドレスを指定
# サイトのドキュメントルートはご自身の環境で
(Enter ‘c’ to cancel):info@hogehoge.com
(Y)es/(N)o: Y
# [Successfully received certificate] と表示されたらおしまい
対話の途中でも表示されますが、生成されたファイルは
SSLCertificateFile /etc/letsencrypt/live/hogehoge.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/hogehoge.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/hogehoge.com/chain.pem
なので、上記同様ssl.confに書き込んでhttpdを
再起動します。
自動更新
certbot導入の際にsystemdのtimerユニットファイルも
インストールされるので、タイマーを有効化しておきます。
#systemctl enable certbot-renew.timer
タイマーの内容は
# cat /usr/lib/systemd/system/certbot-renew.timer
[Unit]
Description=This is the timer to set the schedule for automated renewals
[Timer]
OnCalendar=*-*-* 00/12:00:00
RandomizedDelaySec=12hours
Persistent=true
[Install]
WantedBy=timers.target
ですので、ディフォルトでは毎日２回更新されます。
更新されたらhttpdを再起動させます。
# /etc/sysconfig/certbot
POST_HOOK=
を、上にある例文をコピペして
POST_HOOK=”–post-hook ‘systemctl restart httpd'”
にしておけば更新が反映されます。
試してはいませんが
/etc/letsencrypt/renewal-hooks/post/
下にスクリプトを置いてもよいみたいです。
# vim /etc/letsencrypt/renewal-hooks/post/httpd_restart.sh
# chmod 755 /etc/letsencrypt/renewal-hooks/post/httpd_restart.sh
crontab -e で
00 04 01 * * certbot renew && systemctl restart httpd
などでも行けるようです。
ブラウザアドレスバーの鍵マークをクリックすると
認証局が表示されますが、最近はLet’s Encryptが
多くなってきていますね。
このサイトも現在の認証局の期限が切れたら
Let’s Encryptにしようかと思っています。
####################################################################
改行を考慮せず書いているので、１行が長くて
改行されているところはお気を付けください。
複数ドメインやワイルドカードも可能なので
その辺は気が向いたら。。。ということで。ｗｗ
