ACME（Automated Certificate Management Environment）クライアントには、ブラウザベース（GetHTTPSなど）とコマンドライン（Certbotやacme.shなど）の2つの形態があります。どちらも同じLet’s Encrypt APIと通信し、同一の証明書を発行します。違いは、作業がどこで行われ、誰が鍵を管理するかです。
比較
| ブラウザベース（GetHTTPS） | CLI（Certbot、acme.sh） | |
|---|---|---|
| 実行場所 | ブラウザタブ | サーバーのコマンドライン |
| インストール | 不要 | 必要（snap、pip、シェルスクリプト） |
| 鍵の生成 | ブラウザ（Web Crypto API） | サーバー（OpenSSL） |
| 鍵の保存 | ユーザーがダウンロード | サーバーのファイルシステム |
| 自動更新 | ❌ 手動 | ✅ Cron/systemd |
| サーバーアクセス | 不要 | 必要 |
| GUI | ✅ | ❌ |
| 事前チェック検証 | ✅（GetHTTPS） | ❌ |
| スクリプト対応 | ❌ | ✅ |
| 依存関係 | モダンブラウザ | OpenSSL、curl、cron |
ブラウザベースが優れるケース
- サーバーアクセスなし — 共有ホスティング、マネージドプラットフォーム、ソフトウェアをインストールできないサーバー
- 最大限の鍵プライバシー — 秘密鍵はダウンロードするまでブラウザメモリ内にのみ存在
- 非技術者 — ターミナルよりWebのUIの方が扱いやすい
- 一回限りの証明書 — 1つの証明書のためにCLIツールをセットアップするより高速
- 他者のサポート — CLIコマンドを口頭で伝えるより、ブラウザの操作を画面共有する方が簡単
CLIが優れるケース
- 自動更新 — 本番サーバーに必須、特に47日間の有効期限が導入される場合
- 大規模インフラ — スクリプト化、コンテナ化、構成管理ツールで設定可能
- DNS API自動化 — acme.shなどのCLIツールは150以上のDNSプロバイダーのプラグインを搭載
- CI/CD統合 — デプロイパイプラインの一部として証明書を発行
- サーバー自動設定 — CertbotのNginx/Apacheプラグインがサーバーを直接設定
ハイブリッドアプローチ
多くのチームが両方を使用しています：
- GetHTTPSで最初の証明書を取得（セットアップ時間ゼロ）
- Certbotまたはacme.shを後からインストールして自動更新
これにより、CLIツールのセットアップの初期コストなしにすぐに運用を開始でき、準備ができたら自動化を追加できます。
ブラウザベースACMEクライアント
ブラウザベースのACMEクライアントカテゴリは比較的新しいものです。選択肢は以下の通りです：
| クライアント | オープンソース | 鍵の生成 | 直接ACME | 事前チェック |
|---|---|---|---|---|
| GetHTTPS | いいえ | ブラウザ（Web Crypto） | はい | はい |
| SSL For Free | いいえ | ⚠️ サーバーサイド | ZeroSSL経由 | いいえ |
| ZeroSSLダッシュボード | いいえ | ⚠️ サーバーサイドの可能性 | ZeroSSL API経由 | いいえ |
GetHTTPSは、Web Crypto APIを使用してローカルで鍵を生成し、ミドルウェアなしでLet’s EncryptのACME APIに直接接続する唯一のブラウザベースクライアントです。
CLI ACMEクライアント
CLIエコシステムはより成熟しています：
| クライアント | 言語 | root必要 | 自動更新 | DNSプラグイン | サーバー設定 |
|---|---|---|---|---|---|
| Certbot | Python | はい（snap/pip） | はい（systemd） | プラグイン経由 | Nginx/Apache自動設定 |
| acme.sh | Shell | いいえ | はい（cron） | 150以上内蔵 | 手動 |
| Lego | Go | いいえ | はい | 100以上 | 手動 |
| Caddy | Go | N/A（内蔵） | はい（自動） | DNSモジュール経由 | Caddyサーバーに内蔵 |
| dehydrated | Shell | いいえ | はい（cron） | フック経由 | 手動 |
詳細な比較：GetHTTPS vs Certbot → | GetHTTPS vs acme.sh →
将来：47日間の証明書
2029年までに証明書の有効期限が47日間に短縮されるため、本番環境でのCLIクライアントの優位性はさらに高まります。30〜35日ごとに手動で更新する（ブラウザベース）ことは可能ですが、面倒です。
しかし、ブラウザベースのクライアントは消えません。以下のような永続的に有用なニッチに対応します：
- CLIアクセスのない環境 — 共有ホスティング、マネージドプラットフォーム、制限の厳しい企業環境
- 初回セットアップ — 5分でHTTPSを動作させ、その後CLIツールをインストールするかどうかを判断
- 緊急更新 — サーバーのCertbotが壊れ、今すぐ証明書が必要な場合
- 他者のための証明書 — サーバーにアクセスせずに、クライアントやチームメイトの証明書を生成
- プライバシー重視のシナリオ — 鍵が一時的にでもサーバー上に存在すべきではない場合
よくある質問
ブラウザベースのクライアントはセキュリティが低いですか？
本質的にそうではありません。GetHTTPSはWeb Crypto API（TLS自体が使用するのと同じ暗号プリミティブ）で鍵を生成し、HTTPS経由でLet’s Encryptと直接通信します。鍵はサードパーティのサーバーに触れることはありません。主なトレードオフはセキュリティではなく、自動更新の欠如です。
47日間の証明書でブラウザベースのクライアントは時代遅れになりますか？
時代遅れにはなりませんが、唯一の更新手段としては不便になります。初期セットアップ、緊急更新、サーバーアクセスのないシナリオでは引き続き価値があります。しかし、30〜40日ごとに更新する本番ワークロードでは、CLI自動化が実用的な長期的選択です。
どのCLIクライアントを使うべきですか？
Nginx/Apacheの自動設定が必要でroot権限を許容できるならCertbot。root権限なしでの動作、DNS APIプラグイン、軽量なフットプリントが必要ならacme.sh。Webサーバーを切り替えるならCaddy — 設定ゼロでHTTPSを自動的に処理します。
ブラウザベースのクライアントは自動化パイプラインで使えますか？
直接は使えません。ブラウザベースのクライアントは手動操作が必要です。CI/CDパイプラインやInfrastructure as Codeには、CLIクライアントをご利用ください。GetHTTPSは人間が操作するワークフロー用に設計されています。Certbotやacme.shはマシンが操作するワークフロー用に設計されています。