証明書管理
ACMEが提供する自動化を活用することで、GlobalSignはACMEクライアントがAtlasからパブリックおよびプライベートの信頼されたデジタル証明書をリクエスト・更新できるようにします。Atlasポータルと連携することで、ユーザーはGUIプラットフォーム上で証明書の発行状況を確認し、それらの証明書と認証情報を一元管理できます。また、ACMEワークフローをまだ完全に導入できない環境向けに、AtlasポータルでACME以外のドメインチャレンジを利用することも可能です。
なお、当社のTLS ICAは四半期ごとにローテーションされます。Webサーバーを設定する際、ACMEクライアントは提供されたICAを使用します。詳細については、サポート記事をご参照ください。
ページ認証による証明書の発行
ページ認証(http-01)は、サイトをホストしているWebサーバーに直接アクセスできる場合に最適です。ほとんどのACMEクライアントは、ドメイン認証および証明書発行においてこの方式をサポートしています。
ACMEクライアントでページ認証を使用する際の一般的なワークフローの概要は以下の通りです。
-
WebサーバーにACMEクライアントをインストールして設定します。GlobalSignのAPIキーとACME MACを使用して、GlobalSign ACMEサーバーと通信できるように設定します。
-
ページ認証方式を使用して、ACMEクライアントから証明書リクエストを送信します。
※ページ認証はACMEのデフォルトの認証方式になりつつありますが、直接指定が必要かどうかはACMEクライアントを確認してください。 -
ドメイン認証を完了します:ACMEクライアントがWebサーバーの特定のパスに一意のトークンを配置します。ACMEサーバーはHTTP経由でこのトークンを取得し、ドメインの管理権限を確認します。
-
証明書を受け取りインストールします:認証が成功すると、ACMEクライアントが発行された証明書を取得します。設定によっては、証明書の自動インストールおよびWebサーバーの自動再起動も行われます。
Certbot固有の手順
以下の手順では、ページ認証(http-01)方式を使用してCertbotで証明書を発行する方法を説明しま
前提条件
-
GlobalSign AtlasポータルからのGlobalSign APIキーとACME MAC。
これらの認証情報は、External Account Binding(EAB)を通じてCertbotをAtlasアカウントに紐付けるために使用されます。 -
Certbotの最新バージョン
-
GlobalSign ACME URL
ドメイン認証と証明書の発行
Certbotはデフォルトでページ認証を使用します。
-
Linux環境にログインし、以下のコマンドで最新バージョンのCertbotがインストールされていることを確認します。
#certbot --version -
インストールされていない場合は、以下のコマンドでCertbotをインストールしてバージョンを確認します。
sudo yum install certbot -
設定ファイルでドキュメントルートを確認し、ルートパス「/var/www/html」をコピーします。
-
以下のCertbotコマンドを使用して、アカウントを登録し証明書を発行します。
certbot certonly \
--webroot -w /var/www/html \
--server https://emea.acme.atlas.globalsign.com/directory \
--eab-kid YOUR_KEY_ID \
--eab-hmac-key YOUR_HMAC_KEY \
-d example.com
-y --agree-tos
--key-type rsa
※認証情報はRSAまたはECC証明書製品に紐付けられています。ECC証明書用の認証情報の場合、CertbotはデフォルトでECCアルゴリズムを使用するため、key-typeフラグは不要です。 -
AtlasアカウントがすでにCertbotクライアントに登録されている場合は、以下のコマンドでページ認証方式を使用して証明書をリクエストできます。
certbot certonly \
--webroot -w /var/www/html \
--server https://emea.acme.atlas.globalsign.com/directory \
-d example.com
--key-type rsa
証明書が発行されると、ファイルの保存場所が通知されます。秘密鍵も同じ場所に保存されますので、サービス用に証明書を設定する必要がある場合にご利用ください。ApacheまたはNGINXの実装では、--nginxまたは--apacheフラグを使用してCertbotに証明書を自動インストールさせることができます。
証明書の更新
Certbotは通常、上記のプロセスで発注した証明書の自動更新を事前に設定します。ただし、ご自身のオーダーで自動更新が有効になっているか不明な場合は、以下のドキュメントで確認・設定方法をご参照ください。https://eff-certbot.readthedocs.io/en/stable/using.html#renewing-certificates (英語のみ)
なお、--manualフラグを使用して手動で生成した証明書は自動更新が設定されないため、認証フックスクリプトを通じて手動で更新する必要があります。詳細については、上記リンクの手順をご参照ください。
DNS認証による証明書の発行
DNS認証(dns-01)では、GlobalSign ACMEサーバーが提供する認証トークンを含むDNS TXTレコードを作成することで、ドメインの管理権限を証明できます。この認証方式は、ページ認証が利用できない場合、例えばワイルドカードドメインの証明書発行やパブリックアクセスができないシステムへの証明書発行時に一般的に使用されます。
DNS認証を使用する場合、ACMEのフローは以下の手順で進みます。
-
ACMEクライアントがGlobalSign ACMEサーバーにドメインの証明書をリクエストします。
-
GlobalSign ACMEサーバーがリクエストされたドメインに対する一意の認証トークンを返します。
-
ACMEクライアントは、提供されたトークンを含むDNS TXTレコードを_acme-challengeサブドメインの下に作成します(または作成するように指示します)。
-
TXTレコードがパブリックDNSで参照可能になると、ACMEクライアントがGlobalSign ACMEサーバーに認証の実行を通知します。
-
GlobalSign ACMEサーバーがドメインのDNSレコードを照会し、想定されるTXTレコードの存在を確認します。
-
認証が成功すると、証明書が発行されます。
DNS認証は、証明書リクエストに含まれる各ドメイン(またはワイルドカードドメイン)に対して実施する必要があります。
DNS認証を成功させるには、ACMEサーバーが提供する認証トークンを含む_acme-challenge.<ドメイン>に、パブリックに解決可能なTXTレコードが存在する必要があります。TTL値およびDNSプロバイダーの設定はお客様固有のものであり、認証ロジック自体には影響しません。
DNS認証でのACMEクライアントの使用
多くのACMEクライアントは、以下のいずれかの方法でDNS認証をサポートしています。
-
手動DNSアップデート — クライアントが必要なTXTレコードを出力し、認証が進むまで一時停止する方法
-
DNSプロバイダー連携 — クライアントがプロバイダー固有のAPIを使用してDNSレコードを自動的に作成・削除する方法
重要な注意事項
- DNS認証にはドメインのDNS設定に対する管理権限が必要です。
- DNSの変更は、DNSプロバイダーおよびTTL設定によっては反映に時間がかかる場合があります。
- DNS認証はワイルドカード証明書(*.example.com)を発行するために必須の方式です。
- 自動更新の場合、DNS認証では通常DNS APIアクセスまたは完全自動化されたDNSプラグインが必要です。
CNAME委任による証明書の発行
CNAMEレコード(Canonical Name レコード)はDNSの基本的な構成要素であり、あるドメイン名を別のドメイン名の別名として機能させることができます。ドメイン管理の簡素化、サードパーティサービスのサポート、コンテンツデリバリーネットワーク(CDN)を通じたトラフィックのルーティングなどに広く利用されています。www.example.comをルートドメインに向ける場合でも、カスタムサブドメインをSaaSプラットフォームに接続する場合でも、CNAMEはDNS設定を柔軟かつ効率的に管理する方法を提供します。
ACMEの実装において、dns-01認証方式ではチャレンジ固有のサブドメイン配下に特定のTXTレコードを配置する必要があります。管理下にある別のドメインにACMEチャレンジを委任するCNAMEレコードを作成することで、元のドメインのDNSがサードパーティプロバイダーによって部分的または完全に管理されている場合でも認証を完了できます。この方法により、制限されたDNS設定へのアクセスを必要とせず、証明書発行の柔軟性と管理性を確保できます。
CNAMEに関する重要な注意事項
CNAMEレコードは他のDNSレコードとは少し異なる動作をし、いくつかの重要なルールがあります。DNSリゾルバーがCNAMEを参照しながら別の種類のレコード(AレコードやMXレコードなど)を検索しようとする場合、エイリアスを辿って新しいターゲット名でクエリを再開します。ただし、リゾルバーが特にCNAMEレコードを照会している場合は、ルックアップを再開せずにCNAME自体を返します。
CNAMEの転送先は、同じDNSゾーン内か完全に別のサーバーかに関わらず、任意の有効なドメインを指定できます。ただし、以下の重要な制限事項を覚えておく必要があります:
-
CNAMEレコードを持つドメインには、他のレコードタイプ(A、MX、TXTなど)を設定できません。
-
CNAMEはドメインのルート(ゾーンの頂点とも呼ばれる)には使用できません。そのレベルではNSレコードなどが独立して存在する必要があるためです。
CNAMEレコードの作成
まず、証明書で保護したいドメインのCNAMEレコードを手動で作成します。このレコードは、実際のTXTレコードがホストされる別のドメインにdns-01チャレンジを委任します。CNAMEレコードの名前は「_acme-challenge」プレフィックスで始まる必要があります。
CNAMEレコードのターゲットドメイン(TXTレコードがホストされる場所)はアンダースコアで始めることができますが、必須ではありません。
例えば、example.comの証明書を発行する場合にTXTレコードをexample.netにホストしたい場合、以下のいずれかのCNAMEレコードを作成します:
_acme-challenge.example.com CNAME _acme-challenge.example.net
_acme-challenge.example.com CNAME example.net
これにより、ACMEクライアントとリゾルバーに対して、example.comのTXT認証トークンがexample.netで確認できることを伝えます。
ACMEを使用した証明書のリクエスト
ACMEクライアントを使用して元のドメイン(example.com)の証明書をリクエストします。dns-01認証プロセス中、ACMEクライアントは_acme-challenge.example.comのCNAMEを検出し、ターゲットドメイン(例:_acme-challenge.example.net)へ辿ります。その後、ターゲットドメインに必要なTXTレコードを配置します。これにより、元のドメインのDNSゾーンでTXTレコードを直接作成・更新することなく、チャレンジを完了できます。
認証の完了
TXTレコードがターゲットドメイン(example.net)に配置されると、ACMEクライアントはGlobalSign ACMEサーバに通知し、ドメイン認証を完了させます。GlobalSign ACMEサーバーは、元の_acme-challenge.example.comレコードを照会し、CNAMEを辿ってターゲットドメインに到達し、正しいTXT値を確認したうえでexample.comの証明書を発行します。
技術的な注意事項
-
プレフィックスは必ず「
_acme-challenge」である必要があります。GlobalSign ACMEサービスでは、CNAMEに他のプレフィックスは使用できません。
-
ドメインチャレンジプロセス中に生成されるTXTレコードは大文字・小文字を区別します。ほとんどの場合は問題になりませんが、自動化されたACMEワークフロー外でTXTレコードを移動するプロセスがある場合は、TXTレコードの大文字・小文字を必ず保持してください。保持しない場合、証明書リクエストプロセス中にエラーが発生します。
証明書の更新
CMEクライアントは、証明書の有効期限が切れる前に自動的に更新するよう設計されています。有効期限が近づくと、クライアントはACMEサーバーに新しい証明書リクエストを送信し、元の証明書と同じドメイン認証(必要な場合)および発行プロセスに従います。
証明書が手動で発行された場合、デフォルトで自動更新が設定されていないことがあります。その場合は、ACMEクライアントのドキュメントを参照して、更新の設定方法を確認してください。
証明書の失効
証明書の失効とは、予定された有効期限前に証明書を無効化することです。失効は通常、秘密鍵の漏洩、誤った公開、またはその他のセキュリティインシデントが発生した場合に使用されます。
ほとんどのACMEクライアントは証明書の失効をサポートしていますが、方法や利用可能なオプションはクライアントによって異なります。証明書を失効させると、ACMEサーバーは証明書のステータスを更新し、証明書を信頼する側がそれを検出して信頼しないようにします。
ACMEの証明書は短期間有効なものであるため、証明書を置き換える際に失効が必ずしも必要なわけではありません。クライアント固有の失効コマンドとオプションについては、ACMEクライアントのドキュメントをご参照ください。