前提として、商用CAのACMEでは External Account Binding（EAB）・契約/注文ID・証明書プロファイル・事前審査済み組織/ドメイン が絡むことが多く、Let’s Encryptのように「誰でも即時・無料・DVのみ」とは運用設計が異なります。DigiCertはCertCentral/TLMでACME・ARIに対応し、Sectigo SCMもACMEエンドポイントを提供し、GlobalSign AtlasもDV/OVの公開・非公開証明書をACMEで自動化できます。
目次
商用サーバ証明書におけるACME利用の前提
| 観点 | 商用CAでの考え方 |
|---|---|
| 証明書種別 | ・DVだけでなく、CA/契約によってOV・EV・ワイルドカード・マルチドメイン・プライベート/内部向け証明書に対応する場合がある。 ・DigiCertはOV/EVの自動更新が可能と案内しており、GlobalSignはDV/OVの公開・非公開証明書に対応すると説明している。 |
| 認証方式 | ・HTTP-01 / DNS-01 / TLS-ALPN-01の利用可否は、ACMEクライアントだけでなく、商用CA側のACMEエンドポイントや証明書プロファイルにも依存する。 ・Sectigo SCMではPublic ACMEとUniversal ACMEのエンドポイント種別があり、Public ACMEではDCVを登録時に完了できる。 |
| EAB | ・商用CAではEABが必要になることが多い。 ・EABは既存のCAアカウント/契約とACMEアカウントを紐づける仕組みで、KIDとHMAC Keyを使う。 |
| 契約/課金 | ・無料CAと違い、契約期間・サブスクリプション・証明書プロファイル・発行対象ドメイン数で管理されることが多い。 ・Sectigo JapanのCaaSはドメイン単位サブスクリプションでACME発行を行い、証明書の最大/デフォルト有効期間を90日と説明している。 |
| セキュリティ | ・EAB HMAC Key、DNS APIトークン、CA管理画面の権限は秘密情報。 ・Sectigo/InCommonのようにACMEシークレットが複数ドメインに効く場合、漏えい時の影響が大きいと注意されている。 |
認証方式の比較（商用証明書前提）
| 認証方式 | 商用CAでの向き・特徴 | できること | できないこと | メリット | デメリット・制約 |
|---|---|---|---|---|---|
| HTTP-01 | ・単一Webサイト、通常のApache/Nginx/IIS、公開Webサーバ向け。 ・商用DV/OVでも、CAがHTTP DCVを許可していれば使いやすい。 | ・http://対象FQDN/.well-known/acme-challenge/ に検証ファイルを置き、ドメイン管理権限を証明できる。 | ・ワイルドカード証明書の検証には使えない。 ・80番ポート以外では実行できない。 | ・DNS API不要。Webサーバ上だけで完結しやすい。 ・IIS/Apache/Nginx連携と相性がよい。 | ・80/TCP公開が必須。 ・WAF/CDN/ロードバランサ/リバースプロキシ配下では /.well-known/acme-challenge/ を確実に通す設計が必要。 |
| DNS-01 | ・ワイルドカード、閉域サーバ、複数台構成、CDN/WAF配下、商用OV/EVの事前承認ドメインに向く。 | ・_acme-challenge.example.com のTXTレコードでドメイン管理権限を証明できる。・ワイルドカード証明書に対応する。 | ・IPアドレス証明書の検証には使えない。 ・DNS APIがないと完全自動化しづらい。 | ・Webサーバを外部公開しなくてもよい。 ・複数サーバへ同一証明書を配布する構成に向く。 | ・DNS APIトークン管理が重要。 ・DNS伝播待ちにより発行/更新が遅延する場合がある。 |
| TLS-ALPN-01 | ・80番ポートを使えないが443番ポートは公開できる環境、TLS終端プロキシ/リバースプロキシ向け。 | ・443/TCPのTLSハンドシェイクと専用ALPNでドメイン管理権限を証明できる。 | ・ワイルドカード証明書には使えない。 ・対応クライアントや商用CA側対応がHTTP/DNSより限定される。 | ・80番ポート不要。 ・TLSレイヤーだけで検証できる。 | ・443/TCPで検証用応答を返す必要がある。 ・既存TLS終端、ロードバランサ、SNIルーティングとの整合が必要。 |
ACMEクライアント × 認証方式 比較表（商用サーバ証明書前提）
| 製品 | 主な特徴・向いている用途 | HTTP-01 | DNS-01 | TLS-ALPN-01 | 商用CA利用時のメリット | 商用CA利用時の制約・注意点 |
|---|---|---|---|---|---|---|
| Certbot | ・LinuxのApache/Nginx、標準的なWebサーバ、商用CAのACME導入初期に向く。 ・DigiCert等の商用ACMEでもサードパーティACMEクライアントとして利用される。 | ・対応。 ・Apache/Nginx plugin、webroot、standaloneで利用可能。 | ・対応。 ・DNSプラグインを使って自動化可能。 | ・商用CA用途では基本的に非推奨/対象外として考えるのが安全。 ・Certbot側ではTLS-ALPN-01を削除・非推奨方向としている。 | ・情報量が多く、商用CAの手順書でも採用例が多い。 ・EAB対応CAではディレクトリURL、KID、HMAC Keyを指定して利用できる。 | ・商用CAの証明書プロファイル、EAB、OV/EVの組織審査、契約IDは別途CA側で管理が必要。 ・DNS-01ではDNS API認証情報の管理が必要。 |
| lego | ・Go製のCLI/ライブラリ。独自アプリ、CI/CD、コンテナ、自動化基盤、商用CA連携ツールの部品として向く。 | ・対応。 | ・対応。 ・200以上のDNSプロバイダーをサポート。 | ・対応。 ・TLS-ALPN-01を実装。 | ・単体バイナリで扱いやすく、Traefikなど他製品のACME実装基盤としても利用される。 ・商用CAのACMEにも組み込みやすい。 | ・Webサーバ設定変更や証明書デプロイは自前実装になりやすい。 ・OV/EVや契約プロファイルの指定はCA側仕様の理解が必要。 |
| Posh-ACME | ・PowerShellでACMEを扱いたいWindows/Linux/macOS横断運用に向く。 ・IIS以外のWindows自動化、PFX出力、SecretManagement連携に強い。 | ・対応。 ・HTTPベースの検証プラグインあり。 | ・対応。 ・DNSプラグインが豊富で、ワイルドカード対応。 | ・主用途はHTTP/DNS。 ・TLS-ALPN-01中心ではない。 | ・EABに対応しており、KID/HMAC Keyを指定して商用CAアカウントを作成できる。 | ・IIS自動バインドまで含めるならwin-acmeの方が簡単な場合がある。 ・PowerShell実行ポリシー、資格情報保護、DNSプラグイン権限管理が必要。 |
商用CA別の考慮ポイント
| CA/サービス | ACME利用時のポイント |
|---|---|
| DigiCert / CertCentral / Trust Lifecycle Manager | ・CertCentralやTrust Lifecycle ManagerでACME認証情報を作成し、Certbot等のサードパーティACMEクライアントから発行・更新できる。 ・DigiCertはACMEとARIに対応し、短期化する証明書ライフサイクルの自動化を重視している。 |
| Sectigo / Sectigo Certificate Manager / CaaS | ・SCMはACMEエンドポイントを提供し、Sectigo Public ACMEとUniversal ACMEを区別している。 ・Sectigo JapanのCaaSはDV/OVのACME対応サブスクリプションとして説明されている。 |
| GlobalSign / Atlas ACME | ・Atlasを基盤に、公開/非公開のDV・OV証明書の発行、更新、失効をACMEで自動化できる。 |
| JPRSサーバー証明書 ACME対応版 | ・ACMEにより鍵ペア作成、CSR作成、認証局送信、ドメイン名利用権確認、証明書設定・更新を自動化できると説明している。 ・Certbot、lego、Posh-ACMEが代表例として挙げられている。 |
選定早見表（商用サーバ証明書前提）
| 要件 | 推奨候補 | 理由 |
|---|---|---|
| LinuxのApache/Nginxで商用DV/OVを自動更新 | Certbot | ・商用CAのACME手順で採用されやすく、Webサーバ連携または柔軟な配置がしやすい。 |
| ワイルドカード商用証明書 | DNS-01対応のCertbot / lego | ・ワイルドカードはDNS-01が必要で、DNS API連携の豊富さが運用品質に直結する。 |
| 閉域/非公開サーバに商用証明書 | DNS-01 / GlobalSign IntranetSSL等 | ・DNS-01ならWeb公開不要。 ・GlobalSignは内部エンドポイント向け非公開証明書のACME自動化も説明している。 |
| OV/EVを自動化したい | 商用CA側の事前審査 + EAB対応クライアント | ・OV/EVはドメインだけでなく組織審査やCA側プロファイルが重要。 ・DigiCertはOV/EVもACMEで自動更新可能と案内している。 |
結論
商用サーバ証明書前提では、ACMEクライアントの機能だけでなく、CA側の契約・EAB・証明書プロファイル・組織/ドメイン事前審査 を含めて選定する必要があります。
- Linux標準運用：Certbot
- 独自自動化基盤・組み込み：lego
特に商用CAでは、EAB HMAC KeyやDNS APIトークンが漏れると、契約済みドメインに対する不正発行につながる可能性があるため、最小権限・保管場所の限定・監査ログ・更新失敗監視 をセットで設計するのが重要です。