Categories: KUSANAGISecurityWordPress

kusanagi WordPressのSSL更新 or 非SSLから途中でSSL化、コマンド3つ【超簡単】

KUSANAGIコマンドでJPRSなどの有償SSLから無料SSLのLet's EncryptのSSLへ変更、もしくは非SSLのkusanagi wordpressのWEBサイトを運営途中にSSL化できます。以下メールアドレス（nishinishi@dev-labo.com）とプロファイル名（nishinishi_html）は、皆様の環境にあわせて変えてください。

コマンド打つだけなら5秒！間違わなければ、コマンド実行後、5~10分でSSL化出来ます。

kusanagiサーバーの中でプロファイル単位でバーチャルホストを複数持ち、複数のWordPressを運営されている方は、プロファイル名を間違えない様にご注意ください。

非SSLのkusanagi WordPressをSSL化

//　/etc/nginx/conf.d/nishinishi_html_ssl.confの各種書き換え
kusanagi ssl --email nishinishi@dev-labo.com nishinishi_html

//　SSLリダイレクト
kusanagi ssl --https redirect nishinishi_html

// HSTS設定
kusanagi ssl --hsts weak nishinishi_html

HSTSなどの細かいオプションについては、以下、kusanagi本家ドキュメントを参照ください。
KUSANAGIコマンド - KUSANAGI

既にSSLなkusanagi WordPressのSSL証明書の更新

kusanagi update cert nishinishi_html
プロファイル名には十分気を付けてください。

HSTS（Hypertext Strict Transport Security）

2012年にRFC 6797で規定されたもので、以下の様に2回目以降のアクセスでTLS（SSL）による接続を自動化するものです。HSTSとは、

「このサイトにはHTTPではなくHTTPSで必ず接続するように」と、サーバーがブラウザに指示するHTTPヘッダー。この指示を受け取ったブラウザは、その情報を記録しておき、以降は、そのサイトに対してアクセスするのにHTTPを使わず自動的にHTTPSで接続するようにする。

ということです。

プリロードHSTS

以下のWEBサイトより登録出来ます。上記の2回目以降に対して、アクセス1回目からTLS前提で3wayハンドシェイクしようぜ！ってことだと思う（たぶん）。
HSTS Preload List Submission

※サブドメインは使えないので気を付けてください。

kusanagiコマンドのconfファイルの場所

/usr/lib/kusanagi/conf/cmd.conf

AVASTを使われている方

手元の環境がWindows10でセキュリテイソフトにAvastを使われている方、JPRSからLet’s Encryptに証明証が変更されたことを確認する際に、Avast⇒設定⇒コンポーネント⇒ウェブシールド⇒カスタマイズ⇒「httpsウェブシールドを有効にする」のチェックをはずすと確認できます。

※kusanagiコマンドではなく、SSLサーバー証明証の一般的なインストール作業が必要な場合もあります。わからない時はサーバー構築、SSL設定を行った人に確認してから行ってください。

SSL自動更新がうまくいかないとき

ブラウザキャッシュなども消して自動更新が既に行われていないか？確認してみてください。何度もSSL更新コマンドを実行しても、既に更新されているので、何もしません！みたいな返答を返されるときは、cacheを疑ってみて下さい。Let'sEncryptかkusanagiのどちらかでSSL期限残り1ヶ月を過ぎないと更新出来ない様になっています

SSL自動更新

kusanagi autorenewal off/on

kusanagiプラグインのページキャッシュのオフかクリア

kusanagi bcache off

kusanagi bcache clear

nginxのキャッシュ（fastCGI）のオフかクリア

kusanagi fcache off

kusanagi fcache clear

なども試してみてください。

※比較的にカオスな魔改造ワードプレスでしたが、wp-config.phpのパーミッションが400あたりで上記cacheクリアを行ったら真っ白画面になり、慌ててwp-config.phpパーミッションをchmodで440や600や644などに書き替えて対応したことがあります。ワードプレスパーミッションは開発環境で本番環境の再現を出来ないケースも多々あり、リスクを考慮して慎重にキャッシュ操作を行うようにしたほうがいいです。