Entry

Photo Lib

Forum

Links

Glossary

Misc.

サイトを SSL 化したときのメモ

httpd.conf 中の変更する行： httpd.conf 以外の変更:
Firewall で Let's Encrypt の Challenge を通すようにしておくこと、但し IP が変化する（下記追加情報）。
Firewall の設定で、hhtpd に向けて port 443 の通行を許可する。
Router の静的 NAT の port 443 を開ける（つなぐ）。
Router の IPv4 パケットフィルターで TCP の port 443 を通す。

［実行］
Firewall と Router の窓を開けたのち、サイトサーバーを正規の IP （NAT で指定した IP）として 外部にさらした後で Apache を再起動する。
しばらく（5 分以内）して Let's Encrypt サーバーから認証ファイルが送られてきて、{HTTP_HOST}/md/domains/wista.jp に格納される。　 その中の job.json ファイルを開いて、valid-from の行が今日の日付になっていれば成功している。　 もしファイルが無かったり日付が過去のものだったりする場合は失敗してる。　 その時は {HTTP_HOST}/md/staging/wista.jp/job.json を見て、あれば challenge の途中で失敗している。
失敗する場合は Firewall を全開放して再度試みる。
テスト用のサイトならば偽物(dummy)が送られて来るが、それにより通信が成功していることが確認できる。
テストが成功したら md フォルダーの中を消去し、httpd.conf の MDCertificateAuthority 行を本物のサイトに書き直して、再度立ち上げなおす。
しばらくして本物の認証ファイルが格納されたら、もう一度 Apache を立ち上げなおす。
以上の工程が 50 回失敗すると、7 日間は認証要求ができなくなる。

Web サーバーのある LAN 内からサーバーにアクセスすると、ドメイン名が異なるので拒否されるようになるから、アクセスする側の PC の hosts ファイルを書き換えてドメイン名を LAN 内 IP アドレスに紐づけしておくこと。

Qualys の SSL Server Test や ImmuniWeb （ImmuniWeb は非推奨）を使って外部から SSL が動作していることを確認する。 なお、これらのテストサイトは UserAgent 無しでアクセスしてくる。

全 html 文書の header にある canonical の記述を http:// から https:// に書き換える。
sitemap.xml の <loc> の内容を http:// から https:// に書き換え、<lastmod> の日付を当日にする。
sitemap.xml を Google に送付する。

［更新時に失敗した場合］
Firewall がアクセスを拒否したときは失敗するが、その場合の回復方法は以下の通り：
１．管理者権限で cmd を 開き net stop apache2.4 で Apache を止める。
２．{HTTP_HOST}/md/staging/wista.jp/ の中身を消去する。　ほかのフォルダーは触らないこと。
３．net start apache2.4 でApache を開始する。
４．{HTTP_HOST}/md/domains/wista.jp/job.json がアップデートされたことを確認する。
５．Apache を停止し、再度開始する。

［追加情報］
LE の Challenge は、４つ別々のノードから打って来て、３つが成功しなければ認証されない。　 Firewall で阻止していると認証されないことになる。　 Challenge サーバーの IP アドレスは 公開されていない。
今は Amazon や Google のクラウドを使うことが多いが、過去には Akamai や Cloudflare も使っていた。　 実際に最初に来たのは 3.143.233.9、35.92.222.63、172.65.32.248 の3つだった。
それらを含め私が作ったリストは==> これ。
Lte's Encrypt 側としては Whitelist の使用を推奨していないが、かといって HPPT-01 を使った場合の代替え策は提示していない。　 推奨しない理由は、IP を変化させるので認証が失敗する可能性があるため。
私が 2026 年 5 月現在 LE Challenge のために Firewall に開けてある IP Range は以下の通り：

Challenge のアクセスは次のような形式（一部書き換え）で、２秒以内の間隔で別々の IP から４回来る：

 ip:     3.20.206.24   など多分上記レンジ内のもの
 port:   80
 method: GET 
 URI:    /.well-known/acme-challenge/xxxxxx_long_alphanumeric_string_xxxxxxxx
 agent:  Mozilla/5.0 (compatible; Let's Encrypt validation server; +/www.letsencrypt.org)

Challenge してくるアクセスは、まず最初に 23.178.112.0/24 から URI の /.well-known/acme-challenge/ に来て、 続いて１～２秒以内に３つの別々の IP から同じ URI に来る。　 失敗した場合（例えば Firewall が阻止していた時）はこの回数が増えるのと、秒数が別れるので失敗していることが分かる。

［希望的方法］
http-01 ではできれば White List は使わないほうが良い。　Challenge は実に多くの IP を変化させながら撃ってくるのでその対応が面倒くさい。 それで、次のような方法ができないものか：
「Amazon の IP をすべて閉鎖しておく。　その上で、一旦 IP 23.178.112.0/24 からアクセスが来たら、直ちに(1ms以内に) IP 群 3.0.0.0/8, 13.0.0.0/8, 16.0.0.0/8, 18.0.0.0/8, 34.0.0.0/8, 35.0.0.0/8, 47.0.0.0/8, 51.0.0.0/8, 52.0.0.0/8, 54.0.0.0/8, 64.0.0.0/8, 66.0.0.0/8, 172.0.0.0/8 に対して通過を許可して、４秒後に再度閉鎖する。」
これは時間軸でダイナミックに Firewall 条件を変化させるやり方なので、現状で広く使われている静的な Firewall では実現できない。
別途 PowerShell で Script を書く必要があるが、Log や、既にある Firewall との競合についても入り組んだ考察が必要になる。

あるいは：
「Amazon はすべて閉じておくが、例外的に、IP 群 3.0.0.0/8, 13.0.0.0/8, などからの Port=80 経由で URI=/.well-known/acme-challenge/ への アクセスは許可する」
という方法が取れるかもしれない。 NGINX を使えば実現できそう。


［Reject の取り扱い］
不正なアクセスが :80 に来た時に直ちに 403 を返したいが、通常の Redirect を行うと 301 が返ってしまう。　 SSL 化していなかったときは Environment 変数を設定して
　　Require not env (変数)
を使って 403 のレスポンスを返していたが、SSL 化したときは <VietualHost> の中では <Directory > に到達する前に Redirect になるのが理由。
対応は上記の［実装］のようにした。　以下に経過を示す。

Case 1

SetEnvIf User-Agent ".*botnet" reject
<VirtualHost *:80>
  ServerName wista.jp
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
<VirtualHost *:443>
  SSLEngine on
  ServerName wista.jp              
  SSLSessionTickets on
  DocumentRoot "c:\documentroot" 
</VirtualHost>
<Directory "c:\documentroot">
  Options FollowSymLinks Multiviews
  AllowOverride none
  <RequireAll>
    Require not env reject
    Require all granted
  </RequireAll>
</Directory>

この方法では :80 への不正アクセスには 301 のレスポンスになる。　 Require not env reject は Directory の中にあるので動作しない。　 また Directory セクションは VirtualHost の中へは入れられないルールがある。

Case 2

SetEnvIf User-Agent ".*botnet" reject
<VirtualHost *:80>
  ServerName wista.jp
  RewriteEngine On
  RewriteCond %{ENV:reject} 1
  RewriteRule ^(.*)$ - [F,L]
  RewriteCond %{HTTPS} off
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
（以下同）

この方法では 500 （サーバー内部エラー）を返す。　 理由は [F] によって 403 を返すべく Redirect しようとしてループに入ってしまうため。

Case 3

SetEnvIf User-Agent ".*botnet" reject
<VirtualHost *:80>
  ServerName wista.jp
  RewriteEngine On
  RewriteCond %{ENV:rejected} 1
  RewriteRule ^(.*)$ - [L]
  RewriteCond %{ENV:reject} 1
  RewriteRule ^(.*)$ - [E=rejected:1,F,L]
  RewriteCond %{HTTPS} off
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
（以下同）

この方法では [E=rejected:1,F,L] の部分がうまく働かず、下に抜けて https に Redirect されてしまう。　結果として http:// からは 301 が、https:// からは 403 が返ってくる。

Case 4

（前述の［実装］に書いてある方法）

この方法で :80 へのアクセスに対して 403 を返すことができる。


［特殊な注意事項］
１． ユーザーからのアクセスは https:// で行うようになったわけだが、Google の検索結果はしばらくは http:// で表示されていて Redirect が頻繁に発生する。
この Redirect を避けるために Google の Search Console の「インデックス作成」の「削除」で、 「このプレフィックスで始まる URL をすべて削除」を使って http://wista.jp/ で始まるすべてのページを削除したくなるが、これは絶対にしてはならない。
やると、https:// 以下の全ページが表示されなくなる。

２． httpd.conf の設定の中で
　MDRenewWindow 33%
を指定してある。　これで６０日後かその翌日に自動で更新を実行するので、その日辺りの Apatch log を見ること。　 上記の White List の内、23.178.112.0/24 は必ず最初にくるので、それを見れば来た事が分かる。
Challenge があったら、サーバーの ocsp や staging フォルダーを見て成功していることを確認すること。
同時に Apache Error Log も見て、md モジュールでエラーが出ていないか確認すること。 失敗したときは Timeout エラーが記録される。
また、Firewall の Log を見て、同時刻(+１秒以内）に :80 へのアクセスを阻止している IP があれば Let's Encrypt からのアクセスである可能性があるので、一旦その IP のレンジ(*.*.*.0/24)は通過するように変更しておくこと。
これらの作業は６０日ごとに行う。

３．OCSP
Let's Eccrypt は今後 OCSP サービスを終了する方針なので、使わないこと。
参照： Let's Encrypt の発表 2024/7/23　Intent to End OCSP Service

---

［2025.12.07 追記］
Port 80 を閉鎖することにした。
SSL 導入後ほぼ３年を経過し、Port 80 への正規のアクセスはほとんど無くなって、アタックだけになってきた。　 Firefox も Chrome も Edge も http:// でアクセスすると自動的に https:// に切り替えるようになった。　 もう Redirect は不要で、Port 443 のみで運用できる環境になったと判断する。　 そこで、httpd.conf を書き換えて次のようにした。　これで Let's Encrypt 以外のアクセスが Port 80 に来た場合は 403 を返すことになる。

#MDomain wista.jp                                 Remove this line
MDStapling off                                    Disable OCSP
<VirtualHost *:80>
    ServerName wista.jp
    RewriteEngine On
    RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/ [NC]
    RewriteRule ^ - [F,L]                         Close port 80 except for LE
</VirtualHost>
<VirtualHost *:443>
    ServerName wista.jp
    MDomain wista.jp                              Move into :443 section
    SSLEngine on
    SSLSessionTickets on
    DocumentRoot "c:\documentroot"
</VirtualHost>

注：　上記は最小限の部分だけを記述してあり、実際にはもっと複雑。

---

［2025.12.16 追記］
今日、Let's Encrypt は認証期間を 90 日から 45 日に短縮する計画を発表した。
　==>12/16発表文
2027.2.10 から 64 日に、2028.2.16 から 45 日になる。 SSL mod_md Let's Encrypt letsencrypt httpd.conf

(1/16/2023)

---

SSL mod_md Let's Encrypt letsencrypt httpd.conf
作者： 藤原　武 Tak Fujiwara