4 通信機能の概要

4.1 通信機能の構成と概要

通信機能を構成する機能とその役割を解説します。

4.1.1 データ送受信の基本的な流れ

ACMS Cloudでは、各種通信手順を利用して通信相手先の外部システムや自社内の基幹システムなど多様なシステム間でデータを送受信することができます。各通信手順は、それぞれの通信プロトコル規約に従って実装されています。

4.1.1.1 事前設定

ACMS Cloudでは、あらかじめ設定された内容に従ってデータの送信や通信相手からのデータ受信が行われます。
以下に、基本的な流れを示します。

●着信リスナー※の設定
着信リスナーは、通信相手からのデータを受信するための設定項目です。ACMS Cloudでは用意された着信リスナーを利用します。
●通信ポート※と通信ポートグループの設定
データ送受信は通信ポートによって行われます。データ送受信時には、空いている通信ポートが自動的に選択され、通信が行われます。これらの通信ポートは、論理的に集約された通信ポートグループとして管理されており、効率的なポート管理が可能になります。
●通信ユーザーと論理ファイルの設定
通信ユーザーは、通信相手との接続に必要な設定を行います。また、論理ファイルでは、データの伝送処理や後続処理連携に必要な通信終了処理など、伝送データに関する各種設定を行います。 代表タスクは作成されず、通常の通信タスクの構成となります

※ACMS Cloudでは自律的・能動的に動作する主要な機能を「ロープ」と呼びます。通信ポートや着信リスナーは、自律的かつ能動的に動作する機能であるため、「ロープ」と呼ばれます。

4.1.1.2 データ送受信

通信ユーザーや論理ファイルの定義情報、ロード処理※や、外部からの通信要求、スケジュールといったトリガーによって通信タスクが生成されます。この通信タスクは、通信ポートを介して通信相手と接続し、データの送受信を実行するとともに、通信の状態や接続情報を管理します。
※ロード処理とは、データ送受信を行うために必要な通信タスクを登録する処理を指します。

4.1.1.3 後続処理

受信したデータファイルを後続の処理に連携することを通信終了処理と呼びます。通信終了処理は、定義された論理ファイルの設定に従い、受信した通信の正常終了時に実施することが可能です。

4.1.2 データ送受信で使われる通信機能

ACMS Cloudによるデータの送受信で利用される、各通信機能について解説します。

4.1.2.1 通信ユーザー

通信ユーザーは、ファイル転送を行う通信相手を管理する論理的なリソースです。接続先情報や認証情報を保持し、通信手順に応じた詳細な設定が可能です。
また、通信ユーザーは通信ポートグループと必ず紐づきます。

■通信ユーザーの作成

運用画面を開き、［マスター］－［通信］メニュー内にある［通信ユーザー］をクリックします。続けて、［新規作成］ボタンをクリックし、プロトコルを選択して通信ユーザーの新規作成画面を開きます。

作成方法は各プロトコルのマニュアル『14 新規取引先を追加するには』を参照してください。

■通信ユーザーの参照

作成した通信ユーザーは、［マスター］－［通信］メニュー内にある［通信ユーザー］の画面で確認できます。この画面では、通信ユーザーの一覧照会や検索ができるほか、操作も可能です。

画面内の以下のいずれかの項目を入力して［検索］ボタンをクリックすることで、入力した内容に合致する通信ユーザーのみを表示することができます。

■通信ユーザーの検索条件

項目	概要
業務グループ	業務グループを指定します。
通信ユーザー名	通信ユーザー名を指定します。
プロトコル	プロトコルを指定します。
状態	［有効］、［停止］を指定します。

■通信ユーザー一覧の表示内容

項目	概要
業務グループ	所属する業務グループです。
通信ユーザー名	通信ユーザーの名前です。
プロトコル	プロトコルです。
状態	状態です。 ・有効：通信が行える状態です ・停止：通信が行えない状態です
貸出	所属していない業務グループへの貸出状況です。指定された業務グループ専用であるか、他の業務グループでも利用可能であるかを表示します。
注釈	注釈です。

■通信ユーザーに対して実施できる操作

操作	概要
開始	状態を有効に変更します。
停止	状態を停止に変更します。

4.1.2.2 論理ファイル

論理ファイルは、ファイル転送を行う通信相手とのファイルの種類を管理する論理的なリソースです。データの伝送処理や後続処理連携に必要な通信終了処理など、通信手順に応じた詳細な設定が可能です。
論理ファイルは通信ユーザーと必ず紐づきます。

■論理ファイルの作成

運用画面を開き、［マスター］－［通信］メニュー内にある［論理ファイル］をクリックします。続けて、［新規作成］ボタンをクリックし、プロトコルを選択して論理ファイルの新規作成画面を開きます。

作成方法は各プロトコルのマニュアル『14 新規取引先を追加するには』を参照してください

■論理ファイルの参照

作成した論理ファイルは、［マスター］－［通信］メニュー内にある［論理ファイル］の画面で確認できます。この画面では、論理ファイルの一覧照会や検索ができるほか、操作も可能です。

画面内の以下のいずれかの項目を入力して［検索］ボタンをクリックすることで、入力した内容に合致する論理ファイルのみを表示することができます。

■論理ファイルの検索条件

項目	概要
業務グループ	業務グループを指定します。
通信ユーザー名	通信ユーザー名を指定します。
論理ファイル名	論理ファイル名を指定します。
プロトコル	プロトコルを指定します。
状態	［有効］、［停止］を指定します。
発着信	［発信］または［着信］のいずれかを指定します。
送受信	［送信］または［受信］のいずれかを指定します。

■論理ファイル一覧の表示内容

項目	概要
業務グループ	所属する業務グループです。
通信ユーザー名	所属する通信ユーザー名です。
論理ファイル名	論理ファイルの名前です。
プロトコル	プロトコルです。
状態	状態です。 ・有効：通信が行える状態です ・停止：通信が行えない状態です
貸出	所属していない業務グループへの貸出状況です。
送受信	送受信の方向です。 　・送信：当方が送信します 　・受信：当方が受信します
発着信	通信の起動方向です。 　・発信：当方から発信します 　・着信：相手から発信します
注釈	注釈です。

■論理ファイルに対して実施できる操作

操作	概要
開始	状態を有効に変更します。
停止	状態を停止に変更します。
ロード（通信）	ロードを行い、通信タスクを作成します。

4.1.3データ送受信のパターン

ACMS Cloudのデータ送受信は下記の4パターンに分けられます。

通信パターン	通信の起点	ACMS Cloudの送受信	通信相手の動作
発信/送信	ACMS Cloud	送信	受信
着信/送信	通信相手	送信	受信
発信/受信	ACMS Cloud	受信	送信
着信/受信	通信相手	受信	送信

受信後のデータは、「通信終了処理」の入力として利用でき、フローを起動して処理を実行できます。

4.1.3.1 ACMS Cloudを起点とする送信（発信/送信）

発信/送信は、ロードで送信データの登録を行うことにより通信相手にデータが送信されます。

①ロードにより通信タスクを作成する、通信タスクが処理待ち状態となる
②通信タスクを処理する通信ポートが確定する
③通信ポートは指定された通信手順で通信相手に接続し、データファイルを送信する
　通信終了後、通信タスクの状態を更新する

4.1.3.2　ACMS Cloudを起点とする受信（発信/受信）

発信/受信は、ロードで受信要求を行うことにより通信相手からデータを受信します。

（①～②は発信/送信と同様）
③通信ポートは指定された通信手順で通信相手に接続し、データファイルを受信する
④通信終了後、通信タスクの状態を更新し、論理ファイルの設定に従って通信終了処理が自動的に起動される
　この時、受信ファイルは後続の処理に連携することができる

4.1.3.3　通信相手を起点とする送信（着信/送信）

着信/送信は、ロードで送信データの登録を行います。通信相手からの通信要求によりデータが送信されます。

①ロードにより通信タスクを作成する
②着信リスナーで通信相手から通信要求を受信する
③通信手順を起動し、処理を行う通信ポートグループを決定するために通信ユーザーを特定する
④着信リスナーから通信ポートへ処理を委譲する
⑤通信ポートは通信内容から論理ファイルおよび通信タスクを決定し、データファイルを送信する
⑥通信終了後、通信タスクの状態を更新する

4.1.3.4 通信相手を起点とする受信（着信/受信）

着信/受信は、通信相手からの通信要求によりデータを受信します。ロードで受信要求は必要ありません。

①着信リスナーで通信相手から通信要求を受信する
②通信手順を起動し、処理を行う通信ポートグループを決定するために通信ユーザーを特定する
③着信リスナーから通信ポートへ処理を委譲する
④通信ポートは通信内容から論理ファイルを決定し、通信タスクを作成してデータファイルを受信する
⑤通信終了後、通信タスクの状態を更新し、論理ファイルの設定に従って通信終了処理が自動的に起動される
　この時、受信ファイルは後続の処理に連携することができる

4.1.4 識別子重複についての注意事項

■通信ユーザーの登録

ACMS Cloudでは通信ユーザーの登録時、プロトコルキーとなる識別子が重複しないよう重複チェックを行います。重複している場合は、登録できません。
そのため、「プロトコルのキーが重複しています。」と表示され、 通信ユーザーが登録できない場合は、重複しない値に変更して、登録してください。

識別子の重複について、プロトコルのキーは全体で共用しています。

着信を許容する着信リスナーが異なる場合は、登録することが可能です。

【SFTPサーバーのみ、ログインユーザー名についての注意事項】
SFTPサーバー手順のログインユーザー名については重複していると登録することができません。

意識して重複しないユニークな名称とすることを推奨します。
例）テナントID+user@domain
※識別子の重複についてACMS CloudではACMS ApexまたはACMS B2Bと異なり、通信ユーザーのプロトコルキー重複登録を不可能としています。
登録した場合、着信での通信が行えなくなることから挙動を改善しています。プロトコルキー重複登録を不可能な設定をユーザー側で変更することはできません。 

■プロトコルキー

プロトコルキーは以下の通りです。

項目名	説明
全銀	相手センター確認コード 当方センター確認コード
ebXML MS 2.0	ebXML CPA ID 当方のPartyIDタイプ 当方のPartyID 相手のPartyIDタイプ 相手のPartyID
JXサーバー	相手URI 相手識別子 当方URI
AS2	当方識別子 相手識別子
SFTPサーバー	ログインユーザー名

4.2 ファイル転送

タスクが親子構成となるファイル転送について解説します。 タスクが親子構成となるファイル転送について解説します。

4.2.1 概要

ACMS Cloudには、通常の1ファイルごとの通信方法以外に、1回の接続で複数ファイルを通信できる機能があります。

各機能の詳細は次章以降を参照してください。

• 連結送信
  
• マルチファイル転送
  
• MIMEマルチパート転送
  
• 連続受信

これらの通信では、1回の接続で通信するファイルを明確にするため、代表となるタスクを生成し、親子構成のタスクを組みます。
通信エラーや再送時の再実行を考慮し、一度確定したタスク構成は分解できません。
タスクの構成を維持することで、代表タスクを再実行するだけで再送が可能となります。

通信手順毎の対応表

[凡例] 単独：1ファイルごとの通信、連結：連結送信、連続：連続受信、MIME：MIMEマルチパート転送

通信手順	発信送信		発信受信		着信送信		着信 受信	マルチファイル転送
	単独	任意連結	単独	連続	単独	任意連結		任意	MIME
全銀	○	○	○	－	○	○	○	○	－
SFTPクライアント	○	○	○	○	－	－	－	○	－
SFTPサーバー	－	－	－	－	○	○	○	－	－
JXクライアント	○	－		○	－	－	－	－	－
JXサーバー	－	－	－	－	○	○	○	－	－
AS2	○	－	－	－	－	－	○	－	○
ebXML MS 2.0	○	－	－	－	－	－	○	－	○

4.2.2連結送信

連結送信とは、同種ファイルの通信タスクを一つにまとめて通信相手へ送信する機能です。

【任意の連結送信】

• 予め通信タスクを作成します
• 通信手順が連結可能な通信タスクを収集し、連結送信を実行します
• 通信タスクは代表-子構成になります
  

4.2.2.1 任意の連結送信

■設定

論理ファイルの「任意連結送信」項目を「する」にすると有効となります。

なお、「任意連結送信」項目は障害停止「する」、並行実行数「1」の場合に有効になります。

■利用方法

発信の場合、ターゲットの定義情報の状態が「有効」である場合、タスクが「処理待ち」で登録された時点で実行されるため、任意の連結送信を実施することはできません。

そのため、発信時に任意の連結送信を行うためには、「処理待ち」状態のタスク（連結送信のタスク）を作成する前に、対象のターゲットの定義を停止する必要があります。

なお、論理ファイルを停止/開始することで、同一通信ユーザーを利用する他の通信には影響を与えずに連結送信が可能です。

着信の場合、処理待ち状態の通信タスクを複数個作成した後に、通信相手からの着信時に任意編成の連結送信が実施されます。
任意の連結送信実施時には代表タスクが作成され、連結対象となった通信タスクは代表タスクに関連付けられます。

• 連結送信最大数は「100」です。

4.2.2.2 障害再送時の追加連結

障害再送時の追加連結とは、着信送信にて通信異常が発生した場合に、その後に新規作成された通信タスクを再送時(通信相手からの着信時)に追加連結する機能です。発信送信は対象ではありません。
全銀手順、SFTPサーバー手順が該当します。
また、本機能は「4.2.2連結送信」が有効な状態でプロパティ指定により有効になります。プロパティの詳細は対象プロトコルのマニュアルを参照してください。

• 連結送信最大数は「100」です。
  

4.2.3 マルチファイル転送

マルチファイル転送とは一回の接続で複数回のファイル転送を実施する機能です。

【任意編成のマルチファイル転送】（ファイル未指定方式）

• 通信ユーザーの「マルチファイル転送」項目を「する」に設定します
  
• 通信ユーザーの状態を「停止」にし、処理待ち状態の通信タスクを複数個作成した後、
  通信ユーザーを「開始」にすると、処理待ちの通信タスクを対象にマルチファイル転送が実施されます
  
• タスクの構成は、代表-子構成とはならず、通常の通信タスクの構成となります
  
• 転送はタスクの登録順で実行されます
  

4.2.3.1 任意編成のマルチファイル転送

任意編成のマルチファイル転送とは、通信処理の中でマルチファイル転送をする通信タスクを決定する機能です。

■設定

通信ユーザーの「マルチファイル転送」項目を「する」にすると有効になります。

■利用方法

通信ユーザーの状態を「停止」にし、処理待ち状態の通信タスクを複数個作成した後に通信ユーザーを「開始」にするとマルチファイル転送が実施されます。

任意編成のマルチファイル転送は、タスクが登録された順で実行します。

4.2.4 MIMEマルチパート転送

MIMEマルチパート転送とは、AS2手順、ebXML2.0手順において、MIMEマルチパート形式によるファイルの受信を実施する機能です。

ACMS CloudではMIMEマルチパート形式によるファイルの送信はできません。

4.2.4.1　MIMEマルチパート転送 受信

ACMS Cloudでは受信処理を行う際、通信手順でデコード処理を行ってから通信タスクの登録を行います。

MIMEパート分の子タスクを作成し、代表-子構成になります。

■設定

利用可能な通信手順については2.1 概要を参照してください。設定は各手順のマニュアルを参照してください。

■MIMEパート部の構成

受信したMIMEパート部は、論理ファイルの子ファイルリストの順番と一致する必要があります。
ただし、子ファイルを特定するキーを「指定しない」にすることで、受信したMIMEパートの順番を問わないとするワイルドカード機能を使用することが可能です。

　　<例>ebXML MS 2.0の場合、キーは「コンテンツタイプ」

• 実行例1
  

  

パターン①：受信可能
子ファイルリストの順番と一致、ファイルの個数は問わない

パターン②：受信可能
子ファイルリストの順番と一致しファイルAを受信
ワイルドカード機能によって、論理ファイル-CでファイルBを受信

パターン③：受信可能
ワイルドカード機能によって、論理ファイル-Cで全ファイルを受信

• 実行例2
  

パターン①②：受信可能
子ファイルリストの順番と一致

パターン③：受信可能
ワイルドカード機能によって、論理ファイル-Cで全ファイルを受信

• 実行例3
  

パターン①②：受信不可
子ファイルリストの順番と一致しないためエラー

パターン③：受信可能
ワイルドカード機能によって、論理ファイル-Cで全ファイルを受信

パターンの判定は、論理ファイルに設定された順序に基づいて行われます。
特に、1つ目のファイルは必ず存在している必要があり、これがパターン判定の起点となります。
一方で、2つ目以降のファイルについては、存在していれば設定された順序に従って判定が行われますが、存在しない場合でもエラーとはなりません。
つまり、「順番」だけでなく、「どのファイルが存在するか」も重要な判定条件となります。
実行例3のように、先頭ファイルが存在しない場合には、そのパターン自体が不成立となります。

4.2.5 連続受信

連続受信とは、一回の接続で同種ファイルのファイル受信を複数回実施する機能です。 連続受信の最大数は100となります。
サーバー側に用意されたデータがなくなるまで、１ファイルずつ受信します。 連続受信実施時には起点となったタスクが代表タスクとなり、連続受信で作成される通信タスクは代表タスクに関連付けられた子タスクとなります。

JX手順クライアントの連続受信、SFTPクライアントのMGETが該当します。

※JX手順クライアントでは、「ドキュメント種別を指定しない」設定にしている場合、異なる種別のファイルを連続して受信する可能性があります。

4.3 通信後の処理

通信後に起動する終了処理について解説します。

4.3.1 正常時終了処理

データ受信時に限り、通信終了処理の正常時終了処理として設定することができます。
通信タスクが「完了」となった場合のみ、「正常時終了処理」を起動します。
通信タスクが「永続障害」「即時障害」「強制障害」となった際は実行されません。

4.3.2 通信終了処理の起動単位

データ受信時に限り、通信終了処理の起動単位を選択することができます。

• 通常のタスク単位で起動する
  
• 代表のタスク単位で起動する
  
• 通常／代表のタスクの両方で起動する
  

連結送信では代表タスクが作成され、通常の通信タスクは代表の通信タスクに閨連付けられます。代表のタスクと通常の通信タスクの両方で通信終了処理を起動すると、データの二重処理となってしまいます。

「通常／代表のタスクの両方で起動する」を選択すると、代表のタスクと通常のタスクの処理がそれぞれ起動し、データを二重に処理することになりますので注意してください。

なお、代表タスクに関連付けられた通常の通信タスクの通信終了処理の起動方法は、代表タスクの論理ファイルの設定に従います。

4.3.2.1 連結通信

4.4 PKI

ACMS Cloudが提供するPKI（Public Key Infrastructure：公開鍵基盤）について解説します。

4.4.1 キーペア

PKCS12形式またはOpenSSH形式で作成された証明書をキーペアとして登録します。
登録したキーペアはキーペアを利用する機能で指定します。
ACMS Cloudでは、SSL/TLSサーバー認証のキーペア、SSHファイル転送プロトコル(SFTP手順)のSFTPサーバーで使用するキーペアは登録済みとなるため、操作は必要ありません。
SSL/TLSサーバー認証でACMS Cloudがサーバーになる場合、SSL/TLSクライアント認証でACMS Cloudがクライアントになる場合には、
通信相手先へ認証局の証明書を提供してください。（全銀手順、JX手順、AS2手順、ebXML2.0手順）
認証局の証明書はインテック社の以下URLからダウンロードしてください。
https://www.einspki.jp/site_repository/repository_edi/

SSHファイル転送プロトコル（SFTP手順）でサーバー認証を行い、ACMS Cloudがサーバーとなる場合は、通信相手先に公開鍵を提供してください。
なお、ACMS Cloudでは、SFTPサーバーはサーバー認証を行わない設定でも接続可能です。サーバー認証を行うかどうかは、SFTPクライアントの設定によって決定します。そのため、サーバー認証を行わない場合は、公開鍵の提供は不要です。

公開鍵は以下URLからダウンロードしてください。
・EDI接続
https://www.dal.co.jp/download/acmscloud/publickey/ed-ssh-keypair.pub
・基幹システムとの接続
https://www.dal.co.jp/download/acmscloud/publickey/es-ssh-keypair.pub

上記に該当しないキーペアは、ユーザー自身で用意または購入してください。
また、通信相手先からキーペアを提供されるケースもあります。
いずれの場合も、必要なキーペアを準備したうえで、ACMS Cloudに登録してください。
ユーザー独自の設定が必要な場合のみ追加します。ここでの説明はユーザー独自の設定について記載致します。

• SSL/TLSのサーバー認証／クライアント認証、署名の作成、暗号データの復号をおこなう機能では、PKCS12形式を指定します。
  
• SSHプロトコルを利用する機能(SFTP手順)では、OpenSSH形式を指定します。
  
  

  

  
  

キーペアを利用する機能では、利用開始日時、利用終了日時を設定します。この範囲がキーペアの有効期限として利用可否の判定条件になります。

詳細は本ページ内の「4.4.1.4キーペアの切り替え」を参照してください。

■キーペアを利用する機能とACMS Cloud定義・項目名の一覧

機能	ACMS Cloud
	定義	項目名
SSL/TLSクライアント認証	通信ユーザー 全銀 ebXML MS 2.0 JXクライアント AS2	SSL/TLSクライアント認証で使用するキーペア
デジタル署名の生成	通信ユーザー ebXML MS 2.0 AS2	署名の作成で使用するキーペア
	JWT情報	署名で利用するキー
暗号データの復号	通信ユーザー AS2	暗号の復号で使用するキーペア
SSHファイル転送プロトコル(SFTP手順)	通信ユーザー SFTPクライアント	SFTPクライアントで使用するキーペア

4.4.1.1 キーペアの登録

運用管理画面を開き、［マスター］－［PKI］メニュー内にある［キーペア］をクリックします。続けて、［新規作成］ボタンをクリックし、キーペアのインポート画面を開きます。

インポートするキーペアをダイアログから選択し、キーペアの登録画面を開きます。

基本情報を入力し、［保存］ボタンをクリックします。

キーペア	説明
ファイル	PKCS12形式またはOpenSSH形式の証明書を指定します。
パスワード	証明書のパスワードを指定します。

　　　

■基本情報

項目名	説明
業務グループ	キーペアが所属する業務グループを設定します。
キーペア名	キーペアの名前を設定します。
貸出	キーペアを設定した業務グループ以外へ貸出すかを選択します。
注釈	キーペアの注釈を設定します。

4.4.1.2 キーペアの更新

運用画面を開き、［マスター］－［PKI］メニュー内にある［キーペア］をクリックします。続けて、更新するキーペア名の［詳細］リンクをクリックします。

［編集］－［キーペア更新］ボタンをクリックし、キーペアのインポート画面を開きます。

インポート画面以降の操作は4.1.1キーペアの登録と同様です。

ただし、異なるコモンネームのキーペアを更新しようとした場合は、警告が表示されます。警告を無視して更新することは可能です。

4.4.1.3 キーペアの照会

登録したキーペアは、［マスター］－［PKI］メニュー内にある［キーペア］の画面で確認することができるほか、キーペア名などで検索も可能です。

画面内の以下のいずれかの項目を入力して［検索］ボタンをクリックすることで、入力した内容に合致するキーペアのみを表示することができます。

■キーペアの検索条件

項目	概要
業務グループ	業務グループを指定します。
キーペア名	キーペア名を指定します。
証明書形式	［PKCS#12］、［OpenSSH］を指定します。
有効期間	[期間内]、[期間外]、[期限切れ]を指定します。 その後、基準日時を指定します。

有効期間と基準日時について

[期間内]を指定すると、証明書の有効期間に基準日時が含まれる証明書が表示されます。

[期間外]を指定すると、証明書の有効期間の有効開始日より前、または有効終了日より後に基準日時が含まれる証明書が表示されます。

[期限切れ]を指定すると、証明書の有効期間の有効終了日より後に基準日時が含まれる証明書が表示されます。

■キーペア一覧の表示内容

項目	概要
業務グループ	所属する業務グループです。
キーペア名	キーペアの名前です。
証明書形式	証明書の形式です。 　・PKCS#12：PKCS#12形式のキーペアです 　・OpenSSH：OpenSSH形式のキーペアです
主体者コモンネーム	キーペアに含まれる主体者のコモンネーム（CommonName）です。
発行者コモンネーム	キーペアに含まれる発行者のコモンネーム（CommonName）です。
有効開始日	キーペアの有効開始日です。
有効終了日	キーペアの有効終了日です。
貸出	所属していない業務グループへの貸出状況です。
注釈	注釈です。

4.4.1.4 キーペアの切り替え

PKCS#12形式の証明書には有効期限が存在しますが、キーペアの利用可否は証明書の有効期限ではなく、利用する機能で設定される利用開始日時と利用終了日時によって決まります。

利用開始日時と利用終了日時は、キーペアの有効期間内に設定するか、またはキーペアの利用期間に従うかのどちらかを設定します。

有効期限が切れる前に新しいキーペアに切り替える対応が必要になります。

キーペアを切り替える方法は2つあります。

1. 切り替えタイミングを予約する方法
   
2. キーペアを更新して即時に切り替える方法
   

①切り替えタイミングを予約する方法

使用するキーペアは2つ登録してください。

2つのキーペアの利用開始日時と利用終了日時に基づいて切り替えるタイミングを予約できます。

切り替え条件は以下のとおりになります。

• 登録された2つのキーペアが有効期間内である場合には、開始日が早い（古い）キーペアが優先されます。
  
• 古いキーペアの有効期間が終了すると、自動的に新しいキーペアに切り替わります。
  ＜例＞
  

  

  
  

利用開始日時の早いキーペア1が採用され、キーペア1の有効期間内はキーペア1が使用されます。

[20XX/03/31 23:59:59]にキーペア1が利用終了となるため、[20XX/04/01 00:00:00]以降は、キーペア2が使用されます。

②キーペアを更新して即時に切り替える方法

使用するキーペアは1つ登録してください。

キーペアを更新したタイミングで、利用するキーペアを即時に切り替えることができます。

使用するキーペアの利用期間は「キーペアに従う」に設定する必要があります。

※「キーペアに従わない」に設定している場合は、利用開始日時、利用終了日時はキーペア更新前の情報が残るため、利用開始日時、利用終了日時を改めて設定し直す必要があります。

＜例＞

キーペア1を更新した[20XX/04/01]以降は新キーペア1が使用されます。

4.4.2 末端の証明書

X.509形式またはOpenSSH形式で作成された証明書を末端の証明書として登録します。
登録した末端の証明書は末端の証明書を利用する機能で指定します。

登録する末端の証明書は、ユーザー自身で用意または購入してください。
また、通信相手先から末端の証明書を提供されるケースもあります。
いずれの場合も、必要な末端の証明書を準備したうえで、ACMS Cloudに登録してください。

• SSL/TLSのクライアント認証の同一性検証、署名の検証、暗号化をおこなう機能では、X.509形式を指定します。
  
• SSHプロトコルを利用する機能(SFTP手順)では、OpenSSH形式を指定します。
  

  

  
  

末端の証明書を利用する機能では、利用開始日時、利用終了日時を設定します。この範囲が末端の証明書の有効期限として利用可否の判定条件になります。

詳細は4.4.2.4末端の証明書の切り替えに記載します。

■末端の証明書を利用する機能とACMS Cloud定義・項目名の一覧

機能	ACMS Cloud
	定義	項目名
SSL/TLSクライアント認証の同一性検証	通信ユーザー 全銀 ebXML MS 2.0 JXサーバー AS2	SSL/TLSクライアント認証の同一性検証で使用する証明書
デジタル署名の検証	通信ユーザー ebXML MS 2.0 AS2	署名の検証で使用する通信相手の証明書
データの暗号	通信ユーザー AS2	暗号の作成で使用する通信相手の証明書
SSHファイル転送プロトコル(SFTP手順)	通信ユーザー SFTPクライアント	SFTPサーバー認証
	通信ユーザー SFTPサーバー	SFTPユーザー認証

4.4.2.1 末端の証明書の登録

運用画面を開き、［マスター］－［PKI］メニュー内にある［末端の証明書］をクリックします。続けて、［新規作成］ボタンをクリックし、末端の証明書のインポート画面を開きます。

インポートする末端の証明書をダイアログから選択し、末端の証明書の登録画面を開きます。

基本情報を入力し、［保存］ボタンをクリックします。

末端の証明書	説明
証明書ファイル	X509形式またはOpenSSH形式の証明書ファイルを指定します。

■基本情報

項目名	説明
業務グループ	末端の証明書が所属する業務グループを設定します。
末端の証明書名	末端の証明書の名前を設定します。
貸出	末端の証明書を設定した業務グループ以外へ貸出すかを選択します。
注釈	末端の証明書の注釈を設定します。

4.4.2.2 末端の証明書の更新

運用画面を開き、［マスター］－［PKI］メニュー内にある［末端の証明書］をクリックします。続けて、更新するキーペア名の［詳細］リンクをクリックします。

［編集］－［証明書更新］ボタンをクリックし、末端の証明書のインポート画面を開きます。

インポート画面以降の操作は4.2.1末端の証明書の登録と同様です。

ただし、異なるコモンネームの証明書を更新しようとした場合は、警告が表示されます。警告を無視して更新することは可能です。

4.4.2.3 末端の証明書の照会

登録した末端の証明書は、［マスター］－［PKI］メニュー内にある［末端の証明書］の画面で確認することができるほか、末端の証明書名などで検索も可能です。

画面内の以下のいずれかの項目を入力して［検索］ボタンをクリックすることで、入力した内容に合致する末端の証明書のみを表示することができます。

■末端の証明書の検索条件

項目	概要
業務グループ	業務グループを指定します。
末端の証明書名	末端の証明書名を指定します。
証明書形式	［X.509］、［OpenSSH］を指定します。
有効期間	[期間内]、[期間外]、[期限切れ]を指定します。 その後、日時を指定します。

有効期間と基準日時の詳細については、4.4.1.3キーペアの照会のキーペアの検索条件をご覧ください。

■末端の証明書一覧の表示内容

項目	概要
業務グループ	所属する業務グループです。
末端の証明書名	末端の証明書の名前です。
証明書形式	証明書の形式です。 　・X509：X509形式の証明書です 　・OpenSSH：OpenSSH形式の証明書です
主体者コモンネーム	証明書に含まれる主体者のコモンネーム（CommonName）です。
発行者コモンネーム	証明書に含まれる発行者のコモンネーム（CommonName）です。
有効開始日	証明書の有効開始日です。
有効終了日	証明書の有効終了日です。
貸出	所属していない業務グループへの貸出状況です。
注釈	注釈です。

4.4.2.4 末端の証明書の切り替え

X.509形式の証明書には有効期限が存在しますが、末端の証明書の利用可否は証明書の有効期限ではなく、利用する機能で設定される利用開始日時と利用終了日時によって決まります。

利用開始日時と利用終了日時は、証明書の有効期限内に設定するか、または証明書の利用期間に従うかのどちらかを設定します。

※切り替え手順は本ページ内の「4.4.1.4キーペアの切り替え」と同一です。

4.4.3 認証局の証明書

証明書形式(pem/crt/cer/der形式など)で作成された公開鍵やルート/中間証明書を認証局の証明書として登録します。登録した認証局の証明書は認証局の証明書を利用する機能で指定します。
署名検証やSSL/TLSクライアント認証でACMS Cloudがサーバーになる場合、また、サーバー認証でACMS Cloudがクライアントになる場合、信頼性の検証をおこなう機能は、ここで登録した証明書を使用します。
通信相手先から受領した認証局の証明書を登録してください。
インテック社が公開するルート/中間証明書は、あらかじめ登録されています。お客様で登録する必要はありません。
その他、あらかじめ登録されている認証局の証明書は4.4.3.5 登録済みの認証局の証明書一覧を参照してください。

上記に該当しない認証局の証明書は、ユーザー自身で用意または購入してください。
また、通信相手先から認証局の証明書のご利用を指定され、提供されるケースもあります。
いずれの場合も、必要な認証局の証明書を準備したうえで、ACMS Cloudに登録してください。

■認証局の証明書を利用する機能とACMS Cloud定義・項目名の一覧

機能	ACMS Cloud
	定義	項目名
SSL/TLSサーバー認証の信頼性検証	通信ユーザー 全銀 ebXML MS 2.0 JXクライアント AS2	SSL/TLSサーバー認証で使用する認証局グループ ※指定しない場合には「システム全体で信頼する」認証局グループを使用します。
デジタル署名検証の信頼性検証	通信ユーザー ebXML MS 2.0 AS2	署名検証で使用する認証局グループ ※指定しない場合には「システム全体で信頼する」認証局グループを使用します。

4.4.3.1 認証局の証明書グループの登録

運用画面を開き、［マスター］－［PKI］メニュー内にある［認証局の証明書グループ］をクリックします。続けて、［新規作成］ボタンをクリックし、新規作成画面を開きます。

■基本情報

項目名	説明
業務グループ	認証局の証明書グループが所属する業務グループを設定します。
貸出	認証局の証明書グループを設定した業務グループ以外へ貸出すかを選択します。
認証局の証明書グループ名	認証局の証明書グループの名前を設定します。
注釈	認証局の証明書グループの注釈を設定します。

4.4.3.2 認証局の証明書グループの照会

登録した認証局の証明書グループは、［マスター］－［PKI］メニュー内にある［認証局の証明書グループ］の画面で確認することができるほか、認証局の証明書グループ名などで検索も可能です。

画面内の以下のいずれかの項目を入力して［検索］ボタンをクリックすることで、入力した内容に合致する認証局の証明書グループのみを表示することができます。

■認証局の証明書グループの検索条件

項目	概要
業務グループ	業務グループを指定します。
認証局の証明書グループ	認証局の証明書グループ名を指定します。

■認証局の証明書グループ一覧の表示内容

項目	概要
業務グループ	所属する業務グループです。
認証局の証明書グループ	認証局の証明書グループの名前です。
貸出	所属していない業務グループへの貸出状況です。
注釈	注釈です。

4.4.3.3 認証局の証明書の登録

運用画面を開き、［マスター］－［PKI］メニュー内にある［認証局の証明書］をクリックします。続けて、［新規作成］ボタンをクリックし、認証局の証明書のインポート画面を開きます。

インポートする認証局の証明書をダイアログから選択し、認証局の証明書の新規作成画面を開きます。

認証局の証明書	説明
証明書ファイル	認証局の証明書ファイルを指定します。

■基本情報

項目名	説明
業務グループ	認証局の証明書が所属する業務グループを設定します。
認証局の証明書名	認証局の証明書の名前を設定します。
認証局の証明書グループ	認証局の証明書グループを設定します。
注釈	認証局の証明書の注釈を設定します。

4.4.3.4 認証局の証明書の照会

登録した認証局の証明書は、［マスター］－［PKI］メニュー内にある［認証局の証明書］の画面で確認することができるほか、認証局の証明書名などで検索も可能です。

画面内の以下のいずれかの項目を入力して［検索］ボタンをクリックすることで、入力した内容に合致する認証局の証明書のみを表示することができます。

■認証局の証明書の検索条件

項目	概要
業務グループ	業務グループを指定します。
認証局の証明書名	認証局の証明書名を指定します。
認証局の証明書グループ	認証局の証明書グループを指定します。
認証局の種類	［限定的な用途で信頼する］、［システム全体で信頼する］を指定します。
有効期間	[期間内]、[期間外]、[期限切れ]を指定します。 その後、日時を指定します。

有効期間と基準日時の詳細については、4.4.1.3キーペアの照会のキーペアの検索条件をご覧ください。

■認証局の証明書一覧の表示内容

項目	概要
業務グループ	所属する業務グループです。
認証局の証明書名	認証局の証明書の名前です。
主体者コモンネーム	認証局の証明書に含まれる主体者のコモンネーム（CommonName）です。
発行者コモンネーム	認証局の証明書に含まれる発行者のコモンネーム（CommonName）です。
認証局の種類	認証局の証明書の種類です。 　・限定的な用途で信頼する：特定の用途でのみ信頼します
有効開始日	証明書の有効開始日です。
有効終了日	証明書の有効終了日です。
貸出	所属していない業務グループへの貸出状況です。
注釈	注釈です。

4.4.3.5 登録済みの認証局の証明書一覧

ACMS Cloudにあらかじめ登録している認証局の証明書一覧です。ここに記載されている認証局の証明書はお客様で登録する必要はありません。

主体者コモンネーム

EINS/PKI for EDI Certificate Authority V2 EINS/PKI for EDI Root Certificate Authority V2 Actalis Authentication Root CA AffirmTrust Commercial AffirmTrust Networking AffirmTrust Premium AffirmTrust Premium ECC Amazon Root CA 1 Amazon Root CA 2 Amazon Root CA 3 Amazon Root CA 4 Baltimore CyberTrust Root Buypass Class 2 Root CA Buypass Class 3 Root CA Chambers of Commerce Root – 2008 Chambers of Commerce Root Global Chambersign Root – 2008 Certainly Root E1 Certainly Root R1 Certigna Certigna Root CA Certum CA Certum Trusted Network CA Chunghwa Telecom Co., Ltd. ※ AAA Certificate Services COMODO ECC Certification Authority COMODO RSA Certification Authority DigiCert Assured ID Root G2 DigiCert Assured ID Root G3 DigiCert Assured ID Root CA DigiCert CS ECC P384 Root G5 DigiCert CS RSA4096 Root G5 DigiCert Global Root CA DigiCert Global Root G2 DigiCert Global Root G3 DigiCert High Assurance EV Root CA DigiCert TLS ECC P384 Root G5 DigiCert TLS RSA4096 Root G5 DigiCert Trusted Root G4 D-TRUST Root Class 3 CA 2 2009 D-TRUST Root Class 3 CA 2 EV 2009 emSign ECC Root CA – G3 emSign Root CA – G1 emSign Root CA – G2 Entrust.net Certification Authority (2048) Entrust Root Certification Authority Entrust Root Certification Authority – EC1 Entrust Root Certification Authority – G2 Entrust Root Certification Authority – G4 GeoTrust Primary Certification Authority GeoTrust Primary Certification Authority – G2 GeoTrust Primary Certification Authority – G3 GeoTrust Universal CA GlobalSign Root CA GlobalSign Root E46 GlobalSign GlobalSign GlobalSign GlobalSign Root R46 GlobalSign The Go Daddy Group, Inc.　※ Go Daddy Root Certificate Authority – G2 GTS Root R1 GTS Root R2 GTS Root R3 GTS Root R4 Hellenic Academic and Research Institutions ECC RootCA 2015 Hellenic Academic and Research Institutions RootCA 2015 IdenTrust Commercial Root CA 1 IdenTrust Public Sector Root CA 1 ISRG Root X1 ISRG Root X2 LuxTrust Global Root 2 Microsoft ECC Root Certificate Authority 2017 Microsoft RSA Root Certificate Authority 2017 QuoVadis Root CA 1 G3 QuoVadis Root CA 2 QuoVadis Root CA 2 G3 QuoVadis Root CA 3 QuoVadis Root CA 3 G3 SecureTrust Corporation　※ SecureTrust CA SSL.com Root Certification Authority ECC SSL.com EV Root Certification Authority RSA R2 SSL.com Root Certification Authority RSA SSL.com TLS ECC Root CA 2022 SSL.com TLS RSA Root CA 2022 Starfield Technologies, Inc.　※ Starfield Root Certificate Authority – G2 Starfield Services Root Certificate Authority – G2 SwissSign Gold CA – G2 SwissSign Platinum CA – G2 SwissSign Silver CA – G2 Telia Root CA v2 TeliaSonera Root CA v1 thawte Primary Root CA thawte Primary Root CA – G2 thawte Primary Root CA – G3 T-TeleSec GlobalRoot Class 2 T-TeleSec GlobalRoot Class 3 TWCA Global Root CA USERTrust ECC Certification Authority USERTrust RSA Certification Authority VeriSign Class 3 Public Primary Certification Authority – G3 VeriSign Class 3 Public Primary Certification Authority – G4 VeriSign Class 3 Public Primary Certification Authority – G5 VeriSign Universal Root Certification Authority XRamp Global Certification Authority EINS/PKI for EDI Root Certificate Authority V2 EINS/PKI for EDI Root Certificate Authority V2 EINS/PKI for EDI Certificate Authority V2 ※主体者コモンネームではなく組織名(O)となります。