カテゴリー: Linux

# certonly: 証明書の発行と配置のみで、Webサーバの設定ファイルの書き換えは行わない。
# -w: Webサーバルートディレクトリを指定
# -d: ドメインを指定
# --agree-tos: 規約に同意
# -m: アカウントの登録や回復などに使用する電子メールアドレス
# --keep-until-expiring: リクエストされた SSL/TLS サーバ証明書が既に存在している証明書とマッチする場合には、証明書の更新が必要になるまでは、新規の証明書を取得しない
# --non-interactive: ユーザからの入力を一切求めない
# --staging: SSL/TLS サーバ証明書の取得時に、ステージングサーバを使用して、無効な証明書を取得する
certbot certonly --nginx -w /srv/wordpress/ -d test.oki2a24.com --agree-tos -m oki2a24@gmail.com --keep-until-expiring --non-interactive --staging

WordPress を動かしているリバースプロキシとWebサーバの Nginx で、Let’s Encrypt と certbot で SSL/TLS の発行、導入をしました記録♪ – oki2a24
- SSL/TLS の URL にアクセス。表示が変＞＜。CSS、JavaScript の URL 修正
- SSL/TLS の管理者 URL にアクセス。エラー発生＞＜。リバースプロキシ使用時の WordPress 設定ファイル修正

Ansible の cron モジュール

cron – Manage cron.d and crontab entries — Ansible Documentation
name は必須ではないが、値を設定しておいたほうがよい。

# crontab -l
#Ansible: None
* 0,12 * * * python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew
#

# crontab -l
#Ansible: renew cert
* 0,12 * * * python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew
#

certbot エラーへの対処

DNS レコード設定をしていないと、certbot コマンドはエラーになる。

certbot 実行時にエラーとなりました＞＜。Ansible の出力は見づらいこともあり、ログを確認しました。どうやら、ドメイン名と DNS の A/AAAA レコードと IP アドレスの設定が誤っているのでは？ という内容です。

2018-07-10 17:16:24,442:DEBUG:certbot.reporter:Reporting to user: The following errors were reported by the server:

Domain: test.oki2a24.com
Type:   connection
Detail: Fetching http://test.oki2a24.com/.well-known/acme-challenge/_Ao4A2VfgQWKNAYtTH842j9AHCYGLrea9VW6TVvzSMc: Timeout during connect (likely firewall problem)

To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. Additionally, please check that your computer has a publicly routable IP address and that no firewalls are preventing the server from communicating with the client. If you're using the webroot plugin, you should also verify that you are serving files from the webroot path you provided.

確かに、仮想マシンを作成しなおせば IP アドレスも変わります。そして、DNS レコードの設定は修正してませんでした。そこで、これを修正し、無事エラーは出なくなりました♪

SELinux の影響で、ウェブブラウザから WordPress 本体の更新が不可能になった＞＜

これは、、、まずは諦めようと思います。つまり、SELinux は Enforcing にしたままとします。諦めて、サーバに SSH 接続し、root ユーザで　WP-CLI を使って更新をしようと思います。コマンドは次のようになります。

# wp core check-update
+---------+-------------+----------------------------------------------------------------+
| version | update_type | package_url                                                    |
+---------+-------------+----------------------------------------------------------------+
| 4.9.7   | minor       | https://downloads.wordpress.org/release/ja/wordpress-4.9.7.zip |
+---------+-------------+----------------------------------------------------------------+
# wp core update
Updating to version 4.9.7 (ja)...
https://downloads.wordpress.org/release/ja/wordpress-4.9.7.zip から更新をダウンロード中...
更新を展開しています…
Success: WordPress updated successfully.
# wp core check-update
Success: WordPress is at the latest version.
#

うまい SELinux 設定方法が無いか調べましたけれども、次のページでも同様に運用しているということで、それに倣うことといたしました。

HASHコンサルティングはWordPressを使っています | EGセキュアソリューションズオフィシャルブログ
- SELinuxの副作用

Ansible の Handler は 1 回かけばどこでも使えるグローバルスコープだった！

notify をもつタスクを別の場所に移したとき、handler も移すのを忘れていました。けれども、元の場所にあった handler が動いたことで、気が付きました。

AnsibleでHandlerをいい感じに使ってplaybookをきれいにしよう – Qiita

実際に動かしてみると、Ansible の出力は次のようになりました。

TASK [ssl : Replace Nginx default.conf] ***************************************************************************
changed: [163.44.169.218]

TASK [ssl : Set renew cert] ***************************************************************************************
changed: [163.44.169.218]

RUNNING HANDLER [mariadb : Restart mariadb] ***********************************************************************
changed: [163.44.169.218]

RUNNING HANDLER [nginx : Restart nginx] ***************************************************************************
changed: [163.44.169.218]

RUNNING HANDLER [php-fpm : Restart php-fpm] ***********************************************************************
changed: [163.44.169.218]

Let’s Encrypt の制限に引っかかる＞＜。

プレイブックが完成し、ブラッシュアップしようと弄っては実行していましたら、次のエラーとなりました。

{
  "type": "urn:acme:error:rateLimited",
  "detail": "Error creating new cert :: too many certificates already issued for exact set of domains: test.oki2a24.com: see https://letsencrypt.org/docs/rate-limits/",
  "status": 429
}

ログの Rate Limits – Let’s Encrypt – Free SSL/TLS Certificates を見てみますと、、、たしかに、やっちまったようです。。。どうやら、1 ドメインで 1 週間あたり 20 証明書まで のようです。

お試しの場合は、Staging Environment – Let’s Encrypt – Free SSL/TLS Certificates を使え！とのことです。。。

certbot ならば、–staging を付ければ Staging Environment となる。
Staging Environment ならば、1 ドメインで 1 週間あたり 30000 証明書まで。
Staging Environment で発行した証明書は正規のものではないため、ウェブサイトは “このサイトへの接続は保護されていません” といった警告がブラウザに出る。

certbot コマンドのエラー＞＜。Webサーバの SSL 対応後の設定ファイルは、certbot コマンド実行後に入れ替える

なぜならば、certbot --nginx の場合、certbot 実行中に nginx 設定ファイルのチェックを行うようです。

したがって、その時点では正しくない設定ファイルですと、エラーとなってしまいました。

ログが、その時の状況をよく物語っております＞＜。

2018-07-11 14:00:36,456:ERROR:certbot.util:Error while running nginx -c /etc/nginx/nginx.conf -t.

nginx: [emerg] BIO_new_file("/etc/letsencrypt/live/test.oki2a24.com/fullchain.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/test.oki2a24.com/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
nginx: configuration file /etc/nginx/nginx.conf test failed