WordPressの管理画面から新しくプラグインをインストールしようとする際に下のようなエラーに出会うことが数回あったので、対処法をメモしておこうと思います。
インストールに失敗しました: ダウンロードに失敗しました。 cURL error 35: error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm
opensslのバージョンが原因
opensslとは、インターネット上でよく利用される暗号通信プロトコルであるSSLやTLSの機能を実装したオープンソースのライブラリのことを指します。住所やクレジットカード情報などをインターネット上で暗号化するのがSSL(Secure Sockets Layer)というものです。よく「http://からhttps://に〜」というアレです。SSL対応するとhttpではなくhttpsとなります。
このopensslのバージョンが古いことによって起こるエラーのようですが、かといって比較的安価に利用できるレンタルサーバーのほとんどが共用サーバーだと思いますので、簡単に外部からバージョンアップできるものではありません。方法としては、サーバー管理会社に問い合わせて対応してもらえるかどうかを聞くことくらいしかできないでしょう。
サーバーを引っ越すという方法もあるのですが、すでに運用されているサーバーの場合、メールサーバーとしても利用していると思います。すると、サーバーの引っ越しと共にメールサーバーの設定などの変更作業も必要になってきてしまいます。色々と大変になってきますね。
ですので、まずは即席的に対応する方法をメモしておきます。
wp-include内class-http.phpファイルを修正
先に書いておきますが、これは応急処置としての作業です。本質的な解決にはなりませんのでご注意ください。(本質的な解決方法は上記にもしましたようにopensslのバージョンアップです)
まず、WordPressを設置したサーバー内のwp-includeディレクトリにアクセスします。
その中に【class-http.php】という名前のファイルがあるので、お好きな場所へダウンロードして保存しましょう。そしてテキストエディタなどで編集します。
(WordPress4.7.5で説明しています)200行目あたりを見てください。
'reject_unsafe_urls' => apply_filters( 'http_request_reject_unsafe_urls', false ), 'blocking' => true, 'headers' => array(), 'cookies' => array(), 'body' => null, 'compress' => false, 'decompress' => true, 'sslverify' => true, 'sslcertificates' => ABSPATH . WPINC . '/certificates/ca-bundle.crt', 'stream' => false, 'filename' => null, 'limit_response_size' => null,
上のハイライト表示してある行が200行目になるかと思います。こちらの[sslverify]がデフォルトでは[true]になっていると思いますので、こちらを[false]に変更します。
'reject_unsafe_urls' => apply_filters( 'http_request_reject_unsafe_urls', false ), 'blocking' => true, 'headers' => array(), 'cookies' => array(), 'body' => null, 'compress' => false, 'decompress' => true, 'sslverify' => false, 'sslcertificates' => ABSPATH . WPINC . '/certificates/ca-bundle.crt', 'stream' => false, 'filename' => null, 'limit_response_size' => null,
これで上書き保存して、もともとあった場所へアップロードしてください。これでプラグインをインストールしてもエラーが出なくなっているはずです。
応急処置と抜本的対応
まず、今回紹介した方法は応急処置と考えてください。
というのも、WordPress本体をアップデートするたびにこのファイルは上書きされるのでその度に症状が発生するからです。アップデートするたびにエラーが表示され、クライアントも不安になりますし、こちらもファイルを修正しなくてはならなくなります。
そして、セキュリティの観点から考えても、このままで良いとは言いにくい状況でもあります。ですので、どうにかしてサーバーのopensslバージョンを上げる必要があります。
そこで、抜本的な対応なのですが、やはり2つしか考えられないでしょう。
- サーバー管理者(もしくはレンタルサーバー会社)へopensslのバージョンアップ対応を促す
- それをしてもらえないのであれば、計画的なサーバー引っ越しを検討
この2つに限られるかと思います。
将来的にクライアントのためにもなると思いますので、計画的に対応していく必要がありそうです。