2017年4月25日火曜日

Let's Encryptで証明書を取得する

ググればいくらでも出てくるのですが、防備のために。

Ubuntu 16.04で試しました。

まず、取得のためには、Webサーバが外部に公開されている必要があります。
つまり、Port443(or 80)で外部よりサーバへアクセスできる必要があります。
また、当然ですが名前解決できる必要があります。
しかし、DDNSだと、週に取得できる上限が20個までという制限に引っ掛かる為、
一部のDDNSを除いて、取得しようとすると以下のようなエラーになります。
An unexpected error occurred:
There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for: dip.jp
Please see the logfiles in /var/log/letsencrypt for more details.
 なので、気長に待ちましょう。一日に何回もたたいても取得できないものは取得できません。

自分は取得できるまではオレオレ証明書で過ごしました。Cronで1日一回取得コマンドを叩いてチェックする感じ。一か月くらいかかったかな?

では、新規取得について。cerbotという自動取得プログラムをセットアップします。
cd /usr/local
git clone https://github.com/certbot/certbot
cd certbot
./certbot-auto -n
これで、インストールが完了しました。
必要に応じパスを通すなどしてください。
次に、証明書を取得します。自分は既にオレオレ証明書で外部にWebサーバを公開していたので、
そこを利用する設定にしました。
/usr/local/certbot/certbot-auto certonly --webroot \
-w /var/www/html -d xxxx.dip.jp \
-m admin@example.com --agree-tos -n --dry-run
-mで指定する連絡先メールアドレスは、証明書の更新期限が近づいてくると連絡が来るそうなので、管理用メアドをセットします。

まずは--dry-runにて動作を確認後、OKなら外して動かします。
デフォルトではPort443で通信するようです。

気長に待つと、そのうち下記のようなメッセージが出て、取得できます。
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for xxxx.dip.jp
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0020_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0020_csr-certbot.pem
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/xxxx.dip.jp/fullchain.pem. Your cert will
expire on 2017-0X-XX. To obtain a new or tweaked version of this
certificate in the future, simply run certbot-auto again. To
non-interactively renew *all* of your certificates, run
"certbot-auto renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le
早速取得できた証明書をApache、PostFix、Dovecotにセットします。
Apache:
SSLCertificateFile /etc/letsencrypt/live/xxxx.dip.jp/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/xxxx.dip.jp/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/xxxx.dip.jp/chain.pem
PostFix:
smtpd_tls_cert_file = /etc/letsencrypt/live/xxxx.dip.jp/cert.pem
smtpd_tls_key_file = /etc/letsencrypt/live/xxxx.dip.jp/privkey.pem
smtpd_tls_CAfile = /etc/letsencrypt/live/xxxx.dip.jp/chain.pem
Dovecot:
ssl_cert = </etc/letsencrypt/live/xxxx.dip.jp/fullchain.pem
ssl_key = </etc/letsencrypt/live/xxxx.dip.jp/privkey.pem
このパスは当然ながら最新の証明書へのシンボリックリンクとなっており、
証明書が更新されてもパス、ファイル名が変わらないようになっています。

無事セット出来たら、次は更新処理を行います。
以下のスクリプトを作成し、cron.dailyあたりに放り込んでおきます。
(なお、取得は制限がありましたが、更新は制限がないようです。)
#!/bin/bash
/usr/local/certbot/certbot-auto renew --no-self-upgrade --post-hook "service dovecot restart && service postfix restart && service apache2 restart" --dry-run
ここでは、--post-hookを利用して、証明書が無事取得できたら、Apache、PostFix、Dovecotを再起動するようにしています。
これも、ちゃんと動作するかdry-runでテストを行いますが、
dry-runでも--post-hookは発動してサービスが再起動しますので注意です。
証明書の取得更新作業は今まで大変面倒で、しかも決して安くはないうえに、来るのは数十キロバイトの文字列だし、なんで自動化できないのか。これは一部独占企業による既得権益なのか?(こら
と思っていましたがやっと自動化になりましたね。
Amazonも自動証明書発行やったり、インフラがコードでどんどん自動化、使い捨てが進んでいく流れで、自動化を推進するのは大変良いことです。

2017年4月24日月曜日

Thunderbirdで何故か違う送信者で送信される

Thunderbirdで複数アカウントを登録している場合、
正しいアカウントでメールを送信したにもかかわらず、登録されている違うアカウント名義で送られることがあります。

これ、質が悪いのが、ちゃんと正しいアカウントの送信トレイに残り、しかもそこのFromのアドレスは正しいのですが、実際送られたメールのFromは違うアカウントになっています。

で、原因はこれです。




複数アカウント毎に通常それぞれSMTPサーバが設定されているのですが、
何かの拍子に既定のSMTPサーバになることがあります(汗

でどうなるかというと、このアカウントの受信は問題ないのですが、送信時はこの規定のSMTPサーバから送られます。
この時アカウントを記憶させておくと、しれっとFROM書き換わって送られます(汗

ThunderbirdはSMTPサーバの設定がここともう一か所あります。



ここが正しいからと言って、各アカウントのSMTPサーバ設定の選択とペアで合わせないとこういうことになります。
ちなみに、何故か各アカウントのサーバ設定項目ではなく、アカウント名をクリックしたところにあるので非常に見つけにくいです。

気を付けましょう。

2017年4月5日水曜日

Ubuntu 16.04でシェルを動かすと、変数展開に失敗し、 Bad substitutionとでる。

CentOSでは問題なく動いていたスクリプトが、Ubuntu16.04に持っていくと、
変数展開する箇所で Bad substitutionと出て動かなくなりました。

これ、地味に悩んだのですが、結果はあっけなく

#!/bin/sh



#!/bin/bash

に変えるだけでした。

どうも変数展開自体がbashの機能らしく、CentOSではshでもbashが動くようですが、Ubuntuは古い動作をするようです。

CentOSなどRedHat系になれていると、UbuntuなどDebian系はいろいろ勝手が違います・・

Ubuntu 16.04でcron.daily、cron.hourlyが動かない

Ubuntu 16.04でcron.dailyやcron.hourlyに入れたスクリプトが起動しないことがあります。

でも、実行権限などは付与しており、手動では動きます。

これ、どうやらUbuntuのcronの制限で、ファイル名にドットがあるとダメのようです。

なので、
root@hogehoge:/etc/cron.hourly# ls -lah
合計 16K
drwxr-xr-x   2 root root 4.0K  4月  5 00:41 .
drwxr-xr-x 103 root root 4.0K  4月  5 00:00 ..
-rw-r--r--   1 root root  102  4月  6  2016 .placeholder
-rwxr-xr-x   1 root root  402  4月  5 00:37 log-check.sh  <--これはダメ

拡張子を省きましょう。

2017年4月1日土曜日

Dovecot+自己証明書でtlsv1 alert unknown ca:SSL alert number 48がでてつながらない

Dovecot+SSLで自己証明書を使った場合、ログインできません。
(Ubuntu 16.04+Dovecot 2.2.22で確認)

エラーログには
tlsv1 alert unknown ca:SSL alert number 48
という風に出て、中間証明書が読めていないような感じになります。

ここなんかだと、中間証明書をdovecotの設定ファイルに指定しろとありますが、
問題は解決しません。

これ、正解は自己証明書を生成したときに使った中間証明書をメーラーの信頼する認証局に登録する。です。

これ、結構見つからなかったのでメモしておきます。