WordPressプラグイン「Broken Link Checker」でhttpsのURLが「不明なエラー」になる場合の対処法

※当ブログではアフィリエイト広告を利用しています。

WordPressプラグイン「Broken Link Checker」で、なぜか「不明なエラー」になる。

これが発生すると正しい https の URL なのにエラーになり、いちいち無視するのも面倒です。

この問題に対処したので、原因と対応手順をご紹介します。

発生した問題：WordPressプラグイン「Broken Link Checker」でhttpsのURLが「不明なエラー」になる

この問題が発生すると、正しい URL のはずなのに https の URL が「不明なエラー」で警告として検知されます。

環境は CnetOS 6.7 です。

「Broken Link Checker」の「不明なエラー」に対応した方法

結論としては以下の方法で対応できました。

• nss のアップデート
• curl のアップデート
• php-fpm の再起動
• nginx の再起動

sudo yum update nss
sudo yum update curl
sudo /etc/init.d/php-fpm restart
sudo service nginx restart

どのように問題に対応していったのかを、次でご説明します。

「Broken Link Checker」の「不明なエラー」に対応するまでの手順

ログを有効化してエラー内容を確認する

「Broken Link Checker」の設定画面の「高度な設定」でログの保存を有効化します。

デフォルトだと/wp-content/uploads/にログを出すため外部からアクセスされる可能性があるので、カスタムに変更しました。

「不明なエラー」になっている URL を「再確認」する

「リンクチェッカー」メニューから「不明なエラー」になっている URL を「再確認」します。

「Broken Link Checker」のログを確認する

先ほど設定したログファイルのパスにログが出ています。その内容を確認します。

今回はログに以下のようなエラーが出ていました。

DEBUG: blcLink:save Updating a link. SQL query:
 'UPDATE wp_blc_links SET url = \'https://ja.netbeans.org/nekobean/\', first_failure = \'2019-07-08 12:05:31\', last_check = \'2019-07-19 02:49:31\', last_success = \'2019-07-05 11:57:20\', last_check_attempt = \'2019-07-19 02:49:31\', check_count = 9, final_url = \'https://ja.netbeans.org/nekobean/\', redirect_count = 0, log = \'SSL connect error [Error #35]\\n=== (応答なし) ===\\n\\nResponse headers\\n================\\n\\nリンクエラーです。\',
 http_code = 0, request_duration = 0.302925, timeout = 0, result_hash = \'0|broken|0|https://ja.netbeans.org/nekobean/\', broken = 1, warning = 0, false_positive = 0, may_recheck = 1, being_checked = 0, status_text = \'不明なエラー\', status_code = \'warning\', dismissed = 0 WHERE link_id=943'

SSL connect error [Error #35]の部分が原因のようなので、こちらで調べ libcurl のエラーと推測しました。

curlのウェブサイトで定義を確認します。やはり SSL/TLS 接続に失敗しているようです。

CURLE_SSL_CONNECT_ERROR (35)
A problem occurred somewhere in the SSL/TLS handshake. You really want the error buffer and read the message there as it pinpoints the problem slightly more. Could be certificates (file formats, paths, permissions), passwords, and others.

引用元:libcurl – Error Codes

curl コマンドでの接続確認

WordPress を動かしているサーバーで、curl コマンドで目的の URL を開けるか確認します。

以下のように、そもそも curl コマンドでも(35) SSL connect errorになりました。

curl --verbose https://ja.netbeans.org/nekobean/
* About to connect() to ja.netbeans.org port 443 (#0)
*   Trying 137.254.56.49... connected
* Connected to ja.netbeans.org (137.254.56.49) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -12286
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error

同時にNSS error -12286というエラーも出ています。NSS は Network Security Services の略で、セキュア通信を使うソフトウェアの開発のためのライブラリです。

参考：Network Security Services – Mozilla | MDN

NSS error -12286 について調べる

NSS のエラーコード12286について調べたところ、Mozilla のウェブサイトに定義がありました。

“Cannot communicate securely with peer: no common encryption algorithm(s).”

The local and remote systems share no cipher suites in common. This can be due to a misconfiguration at either end. It can be due to a server being misconfigured to use a non-RSA certificate with the RSA key exchange algorithm.

引用元:NSS and SSL Error Codes

ローカルとアクセス先において、SSL/TLS 通信のための暗号スイートのミスマッチが原因のようです。

nss と curl をアップデートする

さらに調べたところ NSS のエラーコード12286については nss のアップデートで解決したという情報がありました。

参考サイト：CentOS 6 の Git で SSL connect error にハマった (NSS error -12286)

こちらをもとに nss をアップデートしたものの、curlコマンドでのエラーは変わらず。

sudo yum update nss

この時点でcurlのバージョンは以下でした。

$ curl -V
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

念のためcurlについてもアップデートしました。

sudo yum update curl

アップデート後はcurlのバージョンはそのままですが、NSS のバージョンが変わりました。

$ curl -V
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

この状態でcurlで目的の URL への HTTPS 通信が可能となりました。

php-fpm と nginx の再起動

curl側の問題は解消したため、再び「Broken Link Checker」で「再確認」しましたが、まだ「不明なエラー」のままでした。

そこでphp-fpmとnginxを再起動しました。

sudo /etc/init.d/php-fpm restart
sudo service nginx restart

すると「再確認」で「不明なエラー」だった URL も「200 OK」となり、アクセスできるようになりました。

おわりに

「Broken Link Checker」の「不明なエラー」に対応した方法をもう一度まとめます。

• nss のアップデート
• curl のアップデート
• php-fpm の再起動
• nginx の再起動

やはりなにか問題が起こった時はログの確認が大事でした。同じ問題に当たった方の参考になれば幸いです。