いい加減やらないとなーとn年思いながらも放置していた案件.
結論から言うと↓を使うだけ.
得られるもの
- HTTPS化 (DV by let’s encrypt)
- 無料
- ずっと使える (let’s encryptの証明書には90日の期限があるが, 自動的に更新してくれる)
対価
https-portal
は, Webサーバにnginx, 証明書にlet’s encryptベースのリバースプロキシとして動作する. 自動で証明書の更新もしてくれる.
使い方
詳細はリポジトリのREADME参照.
Docker Composeからの利用が推奨されている. いくつか利用法が提示されているが, 基本的には以下のような docker-compose.yml
を作成する.
https-portal: image: steveltn/https-portal:1 ports: - '80:80' - '443:443' links: - wordpress environment: DOMAINS: 'www.example.com -> http://192.168.1.x, wordpress.example.com -> http://wordpress' # STAGE: 'production' wordpress: image: wordpress
イメージに steveltn/https-portal
, ポートにHTTPとHTTPS用のバインドをする. ポイントとなるのは環境変数で, DOMAINS
にFQDNと参照先 (HTTPS化したいエンドポイント) の対応を記述する. 参照先はDocker Composeのlinks機能での指定や追加でポート指定もできる. もう一つ, STAGE
で利用する証明書の種類を指定する.
local
: let’s encryptを使わずにオレオレ証明書を作成して利用する. let’s encryptを噛まさないテスト用.staging
: let’s encryptのテスト用証明書を利用する. テスト用. これがデフォルト.production
: let’s encryptの証明書を利用する. 最終的に利用する場合はコレ.
普通に (?) 利用する場合は以上を設定するだけでHTTPS化が完了する. すごーい.
NAT配下の時は
let’s encryptの認証を行う際にFQDNでの通信が発生するため, 一般的なNAT配下の場合は staging
や production
の場合認証に失敗してしまう (補足: https-portal
はACME DNS-01認証に未対応でHTTP-01での認証が必要). というかこのエラーで小一時間悩まされた.
試行錯誤した結果得られた解決策: 認証に使われるFQDNを明示的にローカルに向ける
https-portal: image: steveltn/https-portal:1 ports: - '80:80' - '443:443' extra_hosts: - 'www.example.com:127.0.0.1' - 'wordpress.example.com:127.0.0.1' links: - wordpress environment: DOMAINS: 'www.example.com -> http://192.168.1.x, wordpress.example.com -> http://wordpress' # STAGE: 'production' wordpress: image: wordpress
これでとりあえずNAT配下でも動く, やったー.
その他
- Automatic Container Discovery はセキュリティ的に怖くて使えないなぁ
- 当然だが [
https-portal
<-> エンドポイント] は暗号化されていないので注意 /var/lib/https-portal
をマウントしておくと証明書の永続化ができる
https-portal: ... volumes: - /path/to/certs/:/var/lib/https-portal/ ...