鯖缶

以下のものが気になっている。どちらかかな。

• X - Certificate and Key management
  • chris2511/xca: X Certificate and Key management
  • C++ 製。商用版などはない。
  • サーバ実装ではなくローカルでの管理用の GUI ツール。
• Smallstep Certificate Manager | Built for DevOps
  • step-ca server
  • smallstep/certificates: 🛡️ A private certificate authority (X.509 & SSH) & ACME server for secure automated certificate management, so you can use TLS everywhere & SSO for SSH.
  • Go 言語製。商用版あり。無料版は 10 devices までの制限あり。 (比較: step-ca versus Smallstep Certificate Manager)

• LabCA | A private Certificate Authority for internal (lab) use, based on the open source ACME Automated Certificate Management Environment implementation from Let’s Encrypt (tm).
  • hakwerk/labca: A private Certificate Authority for internal (lab) use, based on the open source ACME Automated Certificate Management Environment implementation from Let's Encrypt (tm).
  • Go 製。Let's Encrypt の Boulder という CA 実装に admin UI 等を足したものらしい？
  • Commons Clause License (over MPL-2.0) なので厳密には自由ソフトウェアではない。
• letsencrypt/boulder: An ACME-based certificate authority, written in Go.
  • Let's Encrypt で実際に使われている CA 実装。
  • MariaDB に依存。
  • Deployment & Implementation Guide · letsencrypt/boulder Wiki

XCA は GUI ツールであってサーバではないため、自動化との相性が悪そう。

LabCA は boulder の web frontend として見るなら信頼性への影響は小さい気がしてくるが、5年以上ほぼ1人で開発しているようで、今はまだ活発なものの開発の継続性には心配がある。

生の boulder はコンポーネントが多いので (テスト用途でない) 真っ当なセットアップと運用は結構ダルそうな予感がしている。

step-ca は web admin UI がないことを除けば概ね問題なさそうか。

一応書いておくと、LAN 内でのみ有効なドメインで HTTPS を提供する動機として以下のようなものがある。

• public な reverse proxy のバックエンドとして使いやすくなる
  • 名前解決だけどうにかすれば、 VPN なしでも全経路を暗号化できる
• 標準的なポートからサービスを提供できる
  • http の :80 は auto HTTPS 系の機能で無視されやすい
  • そもそも reverse proxy に食わせられるようにしておきたいなどの理由で :80 を素直に listen しない場合も多い
• 盗聴されても認証情報を守れる

そういえば Cloudflare Tunnel で Cloudflare と origin の間を HTTPS で暗号化するためにも プライベートな証明書が使えるのだった。

Cloudflare Tunnel から HTTPS で Caddy の reverse proxy へ流すときの注意:

• X-Real-IP と X-Forwarded-For はクライアントが指定していた場合 Cf Tunnel 側では信用して素通ししてしまうらしいので、 header_up X-Real-IP {http.request.header.CF-Connecting-IP} などで上書きする。
• Caddy から見てリクエスト内の Host ヘッダが Cf Tunnel でバックエンドとして指定した (今回の場合はプライベートな) ドメインになっており、アプリ側で Host を見てレスポンスを生成している場合はリンク等のドメインがおかしくなるなどの問題が発生するため、 header_up Host public.example.com のように Cf Tunnel で受けるときのドメインを明示的に与える必要がある。
  • Redmine などが影響を受ける。たとえばコメントを投稿したあとページがリロードされるが、そのタイミングでプライベートなドメインに飛ばされたりする。
• Cf Tunnel の Public Hostname Page では、以下のように設定する。
  • Service (Type & URL): HTTPS :// localhost
    • Caddy が :443 を listen するので、ポート番号を明示する必要はない。
  • TLS > Origin Server Name: cftunnel.〜.nukobu.internal
    • Host などのヘッダを上書きする必要がある都合で、 LAN 向けとは別で専用の設定を専用のドメインで用意した方が良い。
  • TLS > No TLS Verify: Enabled
    • root CA がオレオレなので検証は無効化する必要あり。
  • HTTP Settings > HTTP Host Header: cftunnel.〜.nukobu.internal
    • これが TLS > Origin Server Name と揃っている必要あり。食い違っていると Caddy が HTTPS 接続を正しく受け入れてくれない模様。

今のところ残件は子チケットの #409 だけ。