[Let's Encrypt - ACME]TLS 証明書の自動証明書管理の構成<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 概要 この記事では、証明書インベントリと管理ストアアプリでの Let's Encrypt [ACME] 自動証明書管理のルーティングポリシーと必要な認証情報を構成する手順について説明します。 開始する前に 証明書インベントリ管理プラグインをアクティブ化する必要があります。MID サーバーが正しくセットアップされている必要があります。必要なロール:pki_admin または admin ステップ 1:認証情報の作成 この認証情報は、認証局 (CA) での認証に使用されます。 A.認証情報に移動 [接続] > [認証情報] > [認証情報] に移動します。[新規] をクリックします。適切なタイプを選択します。 証明書管理認証情報 B.認証情報の詳細を入力 ドロップダウンから CA タイプとして [Let's Encrypt] を選択します。認証情報の適切な名前を指定します。秘密鍵: 秘密鍵は、サーバーに送信されるすべての要求に署名するために必要です。1024 ビット、2048 ビット、または 4096 ビットのサイズの任意のタイプの秘密鍵 (RSA または ECDSA) を指定できます。 秘密鍵を生成するための提案: OpenSSL の使用 (一般的に使用され、広く利用可能)ssh-keygen の使用 (単純な RSA キー生成用) キータイプ:秘密鍵のタイプ、RSA または ECDSA。連絡先:このフィールドはオプションです。Let's Encrypt 側から注文ステータスの更新を受け取る場合は、メール ID のカンマ区切りリストを指定できます。認証情報の認証情報エイリアスを選択または作成します。これは、すべての認証情報で一意である必要があります。後で MID が CA との接続を確立するために使用されます (ルーティングポリシーで同じものを指定する必要があります) 新しい認証情報エイリアスを作成するには、次の手順に従います。 認証情報エイリアスフィールドの横にある検索アイコンをクリックします。[新規] をクリックします。タイプとして [認証情報] を選択します。 認証情報エイリアスに適切な名前を入力して送信します。 ステップ 2:ルーティングポリシーの作成 このルーティングポリシーは、証明書要求を適切な CA アカウントにルーティングするために使用されます。 A.[証明書ルーティングポリシー] に移動します。 証明書管理に移動 >証明書 フローを自動化 > 証明書ルーティングポリシー[新規] をクリックします。 B.ルーティングポリシーの詳細を入力します。 認証局:[認証局] に [暗号化しましょう] を選択します。 選択した CA のベース URL を確認します。これは、[証明書管理] > [認証局>証明書の自動化フロー] に移動することで変更できます。 名前:ルーティングポリシーに名前を入力します。DNS チャレンジアクション:選択すると、ドロップダウンから選択したサブフローアクションを使用して DNS チャレンジが自動的に解決されます。ServiceNow は、GoDaddy ドメインの OOB アクション「ACME DNS チャレンジ - GoDaddy」を提供します。この GoDaddy アクションを使用して DNS チャレンジを自動的に解決するには、認証情報に GoDaddy API キーを入力する必要があります。[接続と認証情報] > [認証情報] > GoDaddy (OOB レコード) に移動し、アカウントの API キーを sso-key [API_KEY]:[API_SECRET] 形式で入力します。GoDaddy ポータルで新しい API キーを生成するには、次の手順に従います。 Developer Portal にアクセスしてください。developer.godaddy.com.developer.godaddy.com に移動します。サインイン:GoDaddy アカウントの資格情報でログインします。API キーへのアクセス:上部のナビゲーションメニューで [API キー] をクリックします。新しい API キーを作成:[新しい API キーを作成] ボタンをクリックします。詳細を入力: 名前:API キーの名前を入力します (例:MyAppAPIKey)。環境:[本番] または [テスト] から選択します。キーの保存:作成後、API キーとシークレットをコピーして安全に保存します。これらは二度と表示されません。 DNS タスクアサイン先グループ:DNS チャレンジを完了するために DNS タスクをアサインするグループを選択します。DNS チャレンジの詳細については、 パート C を確認してください。アサイン先グループ:このルーティングポリシーを介して要求された証明書に関連して、更新タスクなどの手動タスクをアサインするグループを選択します。最大有効期間:証明書の最大許容有効期間を日数単位で取得します。このフィールドを使用して、最大許容有効期間を制限できます。組織 ID:これは、組織によって検証された証明書要求にのみ必要です。認証情報エイリアス:これは、ステップ 1 で Digicert の認証情報を追加したものと同じである必要があります。重複要求を許可:有効にすると、同じ CSR を持つ重複要求が許可されます。承認が必要 > タスク承認グループ:新しい証明書を要求したり、証明書を更新したりする場合、多くの PKI チームは履行前に人手によって検証することを希望します。その場合は、[承認が必要] チェックボックスをオンにして、承認のためにタスクをアサインするグループを選択します。MID サーバー:このルーティングポリシーに一致するすべての要求の送信先となる特定の MID サーバーを選択できます。次のフィールドは、ルーティングポリシーを照合するために使用されます。 RegEx では、サブジェクトの共通名とサブジェクトの代替名がサポートされています。正規表現形式には次の制限があります。 カンマを含めることはできません。スラッシュ (/) で開始および終了しないでください。* はいずれかに一致します。 組織、組織単位、市区町村、州、国、およびメールは CSR 属性であり、カンマ区切りの値を受け入れます。*は任意とみなされます。 環境:これは、証明書要求を異なる CA または CA のアカウントにルーティングするために使用できる単なるメタデータです。証明書の目的 (内部/外部):環境と同様に、証明書要求のルーティングに使用できます。 C.DNS チャレンジを解決する方法 ACME (Automatic Certificate Management Environment) プロトコルの DNS チャレンジは、DNS-01 チャレンジと呼ばれます。これは、Let's Encrypt などの認証局 (CA) に SSL/TLS 証明書を要求するときに、ドメインの制御を証明するために使用される方法です。 仕組み： 1.CA はチャレンジの一環としてランダムなトークンを提供します。証明書タスクから DNS タスクに移動できます。 2.DNSタスクページには、完了する必要があるすべてのDNSチャレンジが表示されます。 3.ドメインに DNS レコードを作成します。ドメインに TXT レコードを追加する手順は、ドメイン プロバイダーによって異なります。ドメインに TXT レコードを追加する方法については、ドメイン プロバイダのドキュメントを参照してください。 トラブルシューティングガイド 証明書の要求中に次のオプションが発生する可能性があります。 オプション説明単一のルーティングポリシーが一致する場合次の条件を確認します。 ルーティングポリシーテーブル、ドメイン名、または * で指定された RegEx パターンを使用して、サブジェクトの共通名を検証します。証明書要求の有効期間がルーティングポリシーテーブルの最大有効期間を超えていないことを確認します。ルーティングポリシーテーブルで重複証明書要求が許可されているフラグを確認します。 複数のルーティングポリシーが適格である場合タスクはデフォルトの承認者グループにアサインされます。ルーティングポリシーが見つからない場合タスクはデフォルトの承認者グループにアサインされます。単一のポリシーが一致し、[承認が必要] フラグが true の場合タスクは、ルーティングポリシーで定義されたタスク承認グループにアサインされます。 注:デフォルトの承認グループは、システムプロパティ「sn_disco_certmgmt.cert_task_default_approval_group」を使用して設定できます 承認グループ名は、一致するポリシーがない場合や、一致するポリシーが 3 つ以上ある場合などに、証明書要求が手動モードに移行する場合に使用されるデフォルトのグループです。複数の承認グループをカンマで区切って追加できます。タスクドメインに属するリスト上の最初のグループが承認に使用されます。ドメイン固有のグループが見つからない場合は、グローバルドメインリストの最初の名前がデフォルトとして使用されます。