ブログ

今月になって（2021年10月1日）突然、トップページの「ブログ」などの更新情報が表示されなくなりました。

（「ブログ」などの更新情報は「墨田区のお知らせ「すみだ」 …」の部分です。）
サーバーの負荷増大やメインテナンス等も考えられますので様子を見ていましたが、更新情報が表示されるようになりませんでした。

トップページは、サーバーから営業日程等の情報を得ての現在の営業情報の表示（「本日（2021年10月 …」の部分）、サーバーからイベント等情報を得ての開催情報（「毎週火曜日 …」の部分）、サーバーから告知等の情報を得ての告知情報（「カフェワークパスで …」の部分）、Twitterのツィートなどを表示して、その後にサーバーから「ブログ」などの更新情報を得ての更新情報（「墨田区のお知らせ「すみだ」 …」の部分）の表示を実行します。
「ブログ」などの更新情報を得る処理は、ブラウザで実行されるJavascriptからサーバーへ要求（サーバーのphpファイル実行）、要求を受けたサーバーは「ブログ」など（WordPressのブログシステム）へRSS配信を依頼して取得、取得したRSSから必要な情報を取り出してブラウザのJavascriptへ返信、返信を受けたJavascriptが更新情報を表示、で完結します。

ブラウザで確認をしたところ、ブラウザで実行されるJavascriptが受け取る返信がエラーでした。
ブラウザで実行されるJavascriptからの要求で実行するサーバーのphpファイルを単独で実行したところ、「SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed」が発生していました。
「joincafe.jp」ドメインのWebサイトでは証明書はLet’s Encryptの証明書を利用しています。
Let’s Encryptを調べたところ、Let’s Encryptが使っているルート証明書の有効期限が2021年9月30日で、ルート証明書が更新されていないサーバーやクライアントは有効期限が切れた2021年10月1日からエラー発生となることが見つかりました。

このサーバーのphpファイルの処理は、実行時に指示された条件（パラメーター）から該当のWordPressのブログシステム（「ブログ」か、「こだわり拘る」か、「パソスマヘルプ」の「お手伝い記録」か）を選択、選択したWordPressのブログシステムへリクエストされたプロトコルと同じプロトコルでRSS配信を要求、取得したRSSから必要な情報を取り出してJSONフォーマットで返信、です。
この「選択したWordPressのブログシステムへリクエストされたプロトコルと同じプロトコル」が「https:」で、引用されるLet’s Encryptのルート証明書が期限切れと判断されてエラー発生です。
エラーの原因となっているLet’s Encryptのルート証明書はサーバーにインストールされたものですので、レンタルサーバー会社へルート証明書の更新を依頼することにしました。

レンタルサーバー会社のサポート窓口へ、Let’s Encryptの証明書を利用しているサーバーからLet’s Encryptの証明書を利用しているサーバーへのリクエストでエラーが発生すること、エラーは「SSL operation failed with code 1. OpenSSL Error messages: error:14090086 …」、サーバーにインストールされているLet’s Encryptのルート証明書の期限切れが原因と考えられる、Let’s Encryptのルート証明書の更新をお願いしたい、と依頼しました。
レンタルサーバー会社からの返事は「システムの調査をするので、しばらくお待ちを」とのことでした。
レンタルサーバーで使っているオペレーティングシステムやWebサーバーなどのソフトウェアを確認、実際にエラーの再現確認をする、だろうと思いました。

数日後にレンタルサーバー会社から連絡があり、実際にエラーの再現確認、Let’s Encryptのルート証明書の期限切れを確認、とのことでした。
ただし「解消にはメンテナンスが必要な内容となる」とのことで、「回避策として以下の適用をご検討いただけますでしょうか」として、2つの回避策を提案していただきました。

1つめの回避策は、「https:」実行時に証明書の検証をしないオプション設定をphpファイルに追加記述する方法です。
エラーの原因は「https:」で引用されるLet’s Encryptのルート証明書が期限切れと判断されての証明書エラーですから、検証しなければエラーは発生しません。
この方法は、エラーの直接原因でないphpファイルを修正しなければならないこと、Let’s Encryptのルート証明書が更新されて期限切れが解消された場合は再度修正しなければならないこと（元に戻す）、そもそも「https:」でアクセスしているのに証明書を検証しないのは不合理、などと考えて、今回の対応では実施すべきではないと考えました。

2つめの回避策は、証明書ファイルを準備して、その証明書をphpシステム内で引用できるようにオプション追加して、オプション追加した証明書が有効となる範囲（ディレクトリー）を設定する、方法です。
準備する証明書は新しいLet’s Encryptのルート証明書（期限切れとならないルート証明書）と同等のもの、オプション追加した証明書が有効となる範囲（ディレクトリー）をエラーが発生しているphpファイルのディレクトリーに限定する、ならば回避策として実施すべきと考えました（phpファイルの修正は不要ですし）。

2つめの回避策を実施するためには、オプション追加した証明書が有効となる範囲（ディレクトリー）を特定しなければなりません。
エラーは「ブラウザで実行されるJavascriptからの要求で実行するサーバーのphpファイル」の「https:」の戻り値です。
この「https:」の処理には、「https:」で依頼するphpファイル（ブラウザで実行されるJavascriptからの要求で実行されるphpファイル）、「https:」で依頼されるphpファイル（WordPressのブログからRSSを作成して返信するphpファイル）、の2つのphpファイルが関係していて、この2つは別の範囲（ディレクトリー）となっています。
2つめの回避策の限定先は、「https:」で依頼するphpファイルのディレクトリーを限定先とするのか、「https:」で依頼されるphpファイルのディレクトリーを限定先とするのか、両方のphpファイルのディレクトリーを限定先とするのか、の3通りが考えられます。
「https:」のリクエストがエラーとなるので、まずは「https:」で依頼されるphpファイルのディレクトリーを限定先としてphpファイルを単独で実行しました。結果は「回避策効果なし」でした。
次に「https:」で依頼するphpファイルのディレクトリーを限定先としてphpファイルを単独で実行しました。結果は「回避策効果あり」でした。
依頼するphpファイルのディレクトリーを限定先とすることで「回避策効果あり」でしたので、両方のphpファイルのディレクトリーを限定先としてのphpファイルを単独で実行は不要となりました。
「https:」で依頼するphpファイルのディレクトリーを限定先としてトップページを閲覧すると、無事に「ブログ」などの更新情報が表示されました。

現在は、2つめの回避策を実施した状態で動いています。
状況をレンタルサーバー会社へ連絡を入れました。
レンタルサーバー会社から返信があり、内容の確認とサーバーにインストールされているルート証明書の更新作業を実施後に連絡をいただくこととなりました。
とりあえず、一段落です。

（回避策の詳細は掲載をしませんが、お問い合わせをいただければお答えします。メニューの「お問い合わせ」からお問い合わせください。）