2023年8月30日:00AM (JST)、デジサートは、CA Browser Forum(以下CA/B フォーラム)のBaseline Requirement (Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates、以下BR)に準拠するため、弊社のPublic Secure Email (S/MIME対応)証明書発行プロセスを以下の通り変更します。
これらの変更は、証明書のEKU (extendedKeyUsage)にemailProtection OIDが記載され、少なくとも 1 つの電子メールアドレスを含む新規発行の証明書すべてに適用されます。メールの署名、検証、暗号化、復号に証明書を使用する場合、新規証明書、再発行証明書、更新証明書の別にかかわらず、2023年8月30日1:00AM(JST、以下断りのない限りJST表記)から、この新しい業界要件の影響を受けます。
重要:この記事は更新する可能性があります。このページのURLを保存し、定期的に最新情報をチェックしてください。 |
Public Secure Email(S/MIME対応)証明書(以下S/MIME証明書)の新しい要件:
- Organization Units(OU)の廃止
S/MIME証明書のOUフィールドは、お客様の固有の情報を格納することができるオプションフィールドですが、その利用範囲は限定的で必ずしも広く認識される情報とは限らず、認証済みではない場合があります。よって当該OUを含めるには追加の認証が必要で、このオプション・フィールドに関する混乱を減らし、認証時間を改善するため、デジサート は、Public S/MIME 証明書でのOUフィールドのサポートを終了いたします。
- 組織情報を含む証明書(BRが定義するorganization-validatedタイプおよびsponsor-validatedタイプ)に対する新しい組織認証要件の適用
S/MIME証明書に組織情報が含まれている場合、デジサートは、BRが定義する新しいS/MIME組織認証要件に従い、組織(エンティティ)の認証(既存のお客様の場合再際認証)を実施いたします。
- 組織情報を含む証明書(BRが定義するorganization-validatedタイプおよびsponsor-validatedタイプ)新しいEメール・ドメイン認証要件の適用
Public S/MIME証明書に組織情報が含まれている場合、その組織が当該ドメインを管理していることを証明できる場合に限り、本ドメインを使用するEメールアドレスを含めることができます。
これらのタイプのS/MIME証明書では、Gmail(@gmail.com)、Outlook(@outlook.com)、Yahoo(yahoo.com)などの自組織が管理しないドメインのメールアドレスを証明書に追加することはできなくなりました。証明書にEメールアドレスを含めることができるのは、そのメールアドレスのドメインについてDCV(Domain Control Validation、ドメイン・コントロール・バリデーション)が完了している場合のみとなります。
現在当該DCVが完了していないお客様は追加のDCVが必要となります。
- 組織情報を含む証明書(BRが定義するorganization-validatedタイプおよびsponsor-validatedタイプ)の サブジェクト識別名(以下SubjectDN) に新しい組織識別子(OrganizationIdentifier)を追加します。
- 証明書に記載するCertificatePolicy(CP)について、証明書タイプに基づく新しい S/MIME 証明書ポリシー・オブジェクト識別子(OID)を使用
- Mailbox-validatedタイプのCP OID: 2.23.140.1.5.1.1 (個人向けS/MIME証明書)
- Organization-validatedタイプの CP OID: 2.23.140.1.5.2.1 (組織向けS/MIME証明書)
- Sponsor-validatedタイプのCP OID: 2.23.140.1.5.3.1 (組織内個人用S/MIME)
中間認証局証明書入れ替えのスケジュールについて
新しいS/MIME証明書のBRは、S/MIME証明書の発行に使用される中間認証局(ICA)証明書にも影響します。しかし、新しい要件の影響を最小限に抑え、円滑な移行を実現するため、CA/B フォーラムは、BR適用後のS/MIME証明書を発行するために、現行のICA証明書を約1年間使用し続けることを認めています。
上記の利用期間延長は2024年9月15日までとなり、当該日以前に、弊社はS/MIME証明書の発行を新しい業界準拠の中間認証局証明書に移行いたします。
この移行について、今後新しい中間認証局証明書のご案内、および移行についてご通知いたします。この通知には新しい中間認証局証明書に関する詳細(名前、発行ルートなど)、実施予定を含みます。
S/MIME証明書への影響について
新たに発行されるS/MIME証明書
2023年8月30日1:00AMより、新規、再発行、および更新された証明書を含む、すべての新たに発行するS/MIME証明書は、CA/B フォーラムのBRに準拠しなければなりません。
この準拠は証明書のEKU (extendedKeyUsage)にemailProtection OIDが記載され、少なくとも 1 つの電子メールアドレスを含む新規発行の証明書すべてに適用されます。メールの署名、検証、暗号化、復号に証明書を使用する場合、新規証明書、再発行証明書、更新証明書の別にかかわらず、2023年8月30日1:00AMから、この新しい業界要件の影響を受けます。
既存の S/MIME 証明書
業界の変更は、2023 年 8 月 30 日 1:00AM以前に発行するS/MIME 証明書には影響しません。これらの既存の証明書は、有効期限が切れるまで使い続けることができます。
ただし、当該期日前に発行した証明書から再発行と更新の場合、その発行、並びに再発行が上記の変更期日以後であれば変更を適用いたします。
お客様での作業について
変更前の仕様並びに発行プロセスでのS/MIME証明書をご希望の場合
8月末から9月にかけて、S/MIME証明書の更新、再発行、または新規注文を予定し、変更前の仕様、プロセスで発行をご希望の場合8月29日までに証明書が発行できるよう、証明書申請を早めに行ってください。
本作業により、S/MIME証明書の発行は現在の仕様、プロセスで発行をいたします。また必要に応じて、OU(organization unit)と検証されたEメールアドレスを含めることができます。
Private S/MIME証明書への移行
お客様がパブリックでの信頼が必要でない場合、プライベートで必要な範囲にて信頼されたS/MIME証明書に移行することを推奨します。Private S/MIME証明書では、Public S/MIME証明書のルールは適用されません。
デジサート Private S/MIME 証明書については、弊社担当営業または デジサート サポートにお問い合わせください。
弊社証明書発行システムごとの固有の変更について
新しいS/MIME証明書のBRの有用な点の1つは、すべての認証局、より具体的には、すべてのデジサート証明書発行システムのPublic S/MIME証明書を標準化することです。
但し、発行システムごとに変更点が異なるため、現在または今後ご利用のシステムについて、その変更内容を以下にてご確認ください。
この変更点は、お客様/パートナー様のシステムに影響がある場合がございますので、必ず内容をご確認いただき、2023年8月30日1:00AMまでに変更を完了するようお願いいたします。
CertCentral:S/MIME 証明書発行プロセスの変更点
2023年8月30日1:00AMに、CertCentralはS/MIME証明書発行プロセスを変更し、CA/B フォーラムのBRを適用いたします。
CertCentral では現在、日本のマーケットに対して以下の S/MIME 関連証明書を提供しており、これらは当該BRによる変更を実施いたします:
- セキュアメールID
- Class1 S/MIME(日本事務器様からの販売のみ)
2023年8月30日1:00AMまでに、CertCentralは、業界に準拠した3種類の新しいS/MIME証明書タイプに合わせ、現在の提供内容を変更します:
- Mailbox-validated タイプ (個人向けS/MIME証明書)
- Organization-validated タイプ - (組織向けS/MIME証明書)
- Sponsor-validated タイプ- 組織がスポンサーとなっている個人(組織内個人)に発行するS/MIME証明書
デジサート は、お客様のご要望に基づき、個人(自然人(natural person, 証明書としてはindividual-validatedタイプ)向けS/MIME証明書の提供も検討しています。本サービスのご興味のあるお客様は弊社までご連絡ください。
特記事項:
- Organization-validated タイプおよびSponsor-validatedタイプの S/MIME証明書について、デジサートは証明書を発行する前に、証明書に含まれる組織を認証します。組織認証の有効期限は認証日より825日間です。
- 新しい証明書申請書式には、証明書発行プロセスの一環として、必要な組織認証を完了するプロセスが含みます。移行に合わせて事前認証のために組織情報の別途ご提出をお願いする予定はございません。
- Organization units(OU)は、Public S/MIME 証明書ではサポートいたしません。
この変更は、OU を含んでいる既存の S/MIME 証明書には影響しません。これは、2023年8月30日にプロセスを更新後に行われる証明書の再発行、鍵の更新、および証明書の変更に適用されます。
- Organization-validatedタイプおよびSponsor-validatedタイプには、組織が管理するドメ インのEメールアドレスのみを含めることができます。
これらのタイプのS/MIME証明書では、Gmail(@gmail.com)、Outlook(@outlook.com)、Yahoo(yahoo.com)などの自組織が管理しないドメインのメールアドレスを証明書に追加することはできません。
- gmail.comやoutlook.comなどの共有メールアドレスでS/MIME証明書を取得するには、mailbox-validated タイプのS/MIME証明書を注文する必要があります。
- BRに従い、以下のCP OIDを含みます:
- Mailbox-validated: 2.23.140.1.5.1.1
- Organization-validated: 2.23.140.1.5.2.1
- Sponsor-validated: 2.23.140.1.5.3.1
CertCentral サービス APIをご利用の場合
2023年8月30日1:00AMの変更にあたり、当該APIを利用した既存のS/MIME証明書発行システムでの変更は不要です。そのままご利用いただけます。
mailbox-validated タイプのS/MIME証明書
mailbox-validated タイプのS/MIME証明書は以下の変更を実施いたします。:
- 証明書を発行する前に、サポートされなくなったSubjectDNのフィールドをすべて削除し、証明書を発行します。本タイプで利用可能なフィールドはコモンネーム(以下CN)とEメール(以下Email)のみ使用可能です。
- CNはEメールアドレスの値でなければならず、SubjectDNのEmailとSubjectAltName (以下SAN)のrfc822Name(本フィールドが存在する場合)などのEメールアドレスと一致しなければなりません。
- 新しいCPのOIDを証明書に記載します:2.23.140.1.5.1.1
- 証明書を発行する前に、受信者にEメールにてユニークな情報(以下チャレンジ)を送信してメールボックスを認証します。
Organization-validatedタイプおよびSponsor-validatedタイプおよびの S/MIME 証明書
Organization-validatedタイプおよびSponsor-validatedタイプの S/MIME 証明書の発行にあたり、以下の変更を実施いたします。:
- 必要な場合には、お客様に組織情報のご提供をお願いいたします。
- SubjectDNのOrganization units(OU)は、Public S/MIME 証明書ではサポートいたしません。証明書申請のSubject DNにOUが含まれている場合、その値を削除して証明書を発行します。
- 認証済みのOrganizationIdentifier を、SubjectDN追加します。
- 新しいCPのOIDを証明書に記載いたします:
- Organization-validated:2.23.140.1.5.2.1
- Sponsor-validated:2.23.140.1.5.3.1
- 証明書に含まれるEメールドメインのDCVが完了している場合のみ、証明書を発行可能です。
S/MIME証明書発行における、 CertCentralのService APIを利用したワークフローの改善点について
CABF S/MIME BRに対応するシステム変更に合わせて、CertCentralのService APIによるワークフローでは以下の改善点をリリースいたします。
- 新しいSecure Email (S/MIME) 証明書申請のエンドポイント(URL)の提供
S/MIME用証明書として以下のものをご用意しております。
- 個人用S/MIME証明書
- 組織用S/MIME証明書
- 組織内自然人用S/MIME証明書
以下の開発者用のURLを参照頂き、APIに関するより詳細な情報をご確認ください。
https://dev.digicert.com/en/certcentral-apis/services-api/orders/services-api-updates-for-client-certificate-workflows.html
なお、上記のページは、新しいリリース等に合わせて新しい情報を更新いたしますので、ブックマーク頂き、定期的にご参照ご確認ください。
TrustLink Enterprise:S/MIME 証明書発行プロセスの更新
2023 年 8 月 30日 1:00AM から、TrustLink Enterprise のS/MIME 証明書は発行いたしません。ただし、TrustLink Enterprise アカウントからは、既存の S/MIME 証明書の有効期限が切れるまで、引き続き表示したり、必要に応じて失効させたりすることができます。
S/MIME証明書の変更、更新、新規取得を行うには、CertCentral EUアカウントにアップグレードする必要があります。新しいアカウントを設定し、新しいS/MIME証明書が利用可能になったら、他のタイプの証明書(TLS/SSLやコードサイニング証明書など)と一緒にこれらの証明書をご発注いただき、発行することができます。
新しいS/MIME証明書プロセスに関する注意事項:
- デジサートは、S/MIME証明書を発行する前に、S/MIME証明書に含まれる組織を認証いたします。
- 組織認証の有効期限は825日間です。デジサートは、証明書発行プロセスの一環として、CertCentral Europeに証明書を申請する際に、組織の認証を実施、完了します。
- Organization-validatedタイプおよびSponsor-validatedタイプの証明書には、自組織で管理下にあることが確認できたドメ インのEメールアドレスのみを含めることができる(gmail.com、outlook.com、またはこれらに類似するEメールアドレスを含めることはできません)。
- gmail.comやoutlook.comなどのドメインを共有しているようなメールアドレスでS/MIME証明書を取得するには、mailbox-validated S/MIME証明書を使用する必要があります。
- Organization units(OU)は、Public S/MIME 証明書ではサポートいたしません。
- S/MIME証明書では、SAN:NameフィールドにEメールアドレスの記載が必要です。
- 新しいCPのOIDを証明書に記載いたします:
- Mailbox-validated: 2.23.140.1.5.1.1
- Organization-validated: 2.23.140.1.5.2.1
- Sponsor-validated: 2.23.140.1.5.3.1
- S/MIME 証明書は、現在のTrustLink Enterprise とは異なる中間 認証局から発行いたします。
PKI Platform 8: S/MIME 証明書発行プロセスの更新
2023 年 8 月 30日 1:00AMに、PKI Platform 8 は、S/MIME 証明書発行プロセスを変更し、Public S/MIME 証明書の発行および管理に関する新しいBRを適用いたします。
PKI Platform 8 のバックエンドは、有効なEメールドメインの S/MIME 証明書要求を認証いたします。このチェックに基づき、mailbox-validatedタイプのS/MIME 証明書、organization-validatedタイプのS/MIME 証明書、またはsponsor-validatedタイプの S/MIME 証明書を発行します。
Mailbox-validated S/MIME証明書
Mailbox-validated S/MIMEの変更は、以下のテンプレートに影響します:
- Secure Email
- S/MIME (Digital Signature only)
- S/MIME (Encryption only
標準化準拠のmailbox-validated S/MIME証明書を発行するために、以下を行います:
- 証明書を発行する前に、サポートされていないト識別名(SubjectDN)フィールドをすべて削除します。コモンネームとEメールのみ使用可能です。
- コモン・ネームはEメールアドレスでなければならず、SubjectDN:EmailおよびSAN:rfc822Nameフィールドのアドレスと一致しなければなりません(存在する場合)。
- SubjectDN:Email が SAN:rfc822Name 値と異なる場合、SAN側の 値が自動的に SubjectDN:Email へコピーいたします。
- 新しいCPのOIDを証明書に記載いたします:
- 証明書を発行する前に、メールボックスを検証するためのリンクを含むチャレンジメールを送信し、受信者はそのメールに従い処理が必要です。
- 24時間以内に証明書が取得されない場合は、メールの再送によりリンクをリセットする必要があります。
- プロファイルウィザードを更新し、上記の変更について利用者に通知してください。
Sponsor-validatedタイプおよびorganization-validatedタイプの S/MIME 証明書
S/MIMEの変更は以下のテンプレートに影響します:
- Sponsor-validatedタイプ:
- Secure Email
- S/MIME (Digital Signature only)
- S/MIME (Encryption only)
- S/MIME (Digital Signature only) for Intune
- Organization-validatedタイプ:
標準化準拠のSponsor-validatedタイプのS/MIME証明書を発行するために、以下を行います:
- 既存の組織所在地をベースにした識別名(SubjectDN)フィールド(例:Country、State、 Locality、Street address)のサポートは継続してサポートします。
上記のフィールドが証明書プロファイルに存在する場合、その値は認証済み組織の詳細情報と一致する必要があります。
- 証明書の既存の SubjectDN フィールドを引き続きサポートします。PKI Platformの契約者である組織は、組織内個人の情報を精査する責任があり、その対象にはGiven Name(姓)、Last Name(名)、pseudonym(仮名)、Title(役職)、Unique Identifier(固有識別子)、UserID(ユーザーID)などのフィールドを含みます。
- Organization units(OU)は、Public S/MIME 証明書ではサポートいたしません。
- Subject DN:OUが証明書要求またはプロファイルに固定値として含まれている場合、証明書プロファイルで設定されていても、その値を削除した上で証明書を発行します。
- SubjectDN:Email が SAN:rfc822Name 値と異なる場合、SAN 側の値が自動的に SubjectDN:Emailへコピーいたします。
- Pseudonymフィールドがプロファイルに設定されていて、この申請にこのフィールドが含まれる場合:
- Pseudonym は、証明書が発行されるUser Seatに対して一意でなければなりません。同じSeat IDであれば、重複を許可します。アカウント内の異なるSeat IDにバインドされたリクエストで当該値が同じである場合、エラーを返します。
- 申請にPseudonymのフィールドを含む場合、同じ申請にはGiven NameとSurnameフィールドを含むことは出来ません。PseudonymとGiven NameまたはSurnameが含まれている場合、エラーになります。
- SubjectDN に新しい組織識別子 として、弊社側で検証済みのOrganizationID(組織 ID)追加します。
組織識別子については、弊社の実施する組織再認証にて準備をし、証明書に含むように準備をしております。もし移行後にお客様にてエラーが確認される場合、弊社サポートにご連絡ください。 |
- 新しいCPのOIDを証明書に記載いたします:
- Sponsor-validated: 2.23.140.1.5.3.1
- Organization-validated: 2.23.140.1.5.2.1
- Public S/MIME証明書の プロファイルにて、発行にEnrollment Code(登録申請 コード)を使用する場合で、Eメールドメインの DCV (Domain Control Validation)が完了しているSponsor-validatedタイプの S/MIME 証明書では、当該Enrollment Codeの有効期間を使用します。
証明書の更新
発行済み証明書の更新については、現在と同じ方式を維持します。例としてWebベースであるOS/Browser、CSR申請、DigiCert DeskTop Client、自動化した例としてPKI Clientベースの更新やEGW経由での更新などそのままです。ただし、更新により発行する証明書は、今回のS/MIME BRの変更を反映したいものとなり、SubjectDN、およびポリシーOIDなどは新しいルールに従って発行いたします。
PKI Platform 8 API 統合
APIの処理を見直し、アプリケーションが新しいS/MIME BR要件を満たすための適切なプロファイル制限に準拠していることを確認してください。申請データに、ある証明書タイプでサポートされていないフィールド(例: mailbox-validatedタイプのOrganization)が含まれている場合、それらのフィールドは削除した上で証明書を発行します(CPには適用する証明書タイプそれぞれの値を含みます)。
EメールのDCV(ドメイン認証)
PKI Platform の自動化するワークフロー(SOAP/REST APIを利用する場合を含む)では、Public S/MIME 証明書要求に含むEメール・ドメインを、認証済みドメインと照合します。
- 自動化フローまたはAPIは、発行申請に含むメールアドレスのメールドメインが事前認証されていない場合、エラーになります。
- APIまたは自動ワークフロー(MS Autoenrollment、SCEPなど)を通じて申請する場合、Mailbox-validated S/MIMEタイプの証明書を発行できません。
Trust Lifecycle Manager: S/MIME 証明書発行プロセスの変更
2023年8月30日1:00AMに、DigiCert ONE - Trust Lifecycle Managerは、Public S/MIME証明書のBRに適合するよう、S/MIME証明書発行プロセスを変更いたします。
Trust Lifecycle Manager は、Public S/MIME 証明書を発行に際して PKI Platform 8 を利用しています。この場合、PKI Platform 8 は、Trust Lifecycle Manager 経由で申請するS/MIME 証明書要求について、有効なEメールドメインを確認します。このチェックに基づき、Mailbox-validated タイプのS/MIME 証明書またはSponsor-validated タイプのS/MIME 証明書を発行します。
Sponsor-validated S/MIME証明書
S/MIME BRの適用は、PKI Platform 8にてPublic S/MIME Secure Emailプロファイルに影響を受けます。このテンプレートは、Sponsor-validated S/MIME 証明書タイプ用です。
Trust Lifecycle Manager 用の標準化準拠のSponsor-validated タイプのS/MIME 証明書を発行するために、PKI Platform 8 は以下を実行します:
- 既存の組織所在地をベースにした識別名(SubjectDN)フィールド(例:Country、State、 Locality、Street address)のサポートは継続してサポートします。
上記のフィールドが証明書プロファイルに存在する場合、その値は認証済み組織の詳細情報と一致する必要があります。
- 証明書の既存の SubjectDN フィールドを引き続きサポートします。PKI Platformの契約者である組織は、組織内個人の情報を精査する責任があり、その対象にはGiven Name(姓)、Last Name(名)、pseudonym(仮名)、Title(役職)、Unique Identifier(固有識別子)、UserID(ユーザーID)などのフィールドを含みます。
- Organization units(OU)は、Public S/MIME 証明書ではサポートいたしません。
- Subject DN:OUが証明書要求またはプロファイルに固定値として含まれている場合、証明書プロファイルで設定されていても、その値を削除した上で証明書を発行します。
- SubjectDN:Email が SAN:rfc822Name 値と異なる場合、SAN 側の値が自動的に SubjectDN:Emailへコピーいたします。
- SubjectDN に新しい組織識別子 として、弊社側で検証済みのOrganizationID(組織 ID)追加します。
組織識別子については、弊社の実施する組織再認証にて準備をし、証明書に含むように準備をしております。もし移行後にお客様にてエラーが確認される場合、弊社サポートにご連絡ください。 |
- 新しいCPのOIDを証明書に記載いたします:
- Sponsor-validated: 2.23.140.1.5.3.1
- Public S/MIME証明書の プロファイルにて、発行にEnrollment Code(登録申請 コード)を使用する場合で、Eメールドメインの DCV (Domain Control Validation)が完了しているSponsor-validatedタイプの S/MIME 証明書では、当該Enrollment Codeの有効期間を使用します。
証明書の更新
発行済み証明書の更新については、現在と同じ方式を維持します。例としてWebベースであるBrowser PKCS12申請、CSR申請、DigiCert DeskTop Client、自動化した例としてREST API経由の更新などそのままです。ただし、更新により発行する証明書は、今回のS/MIME BRの変更を反映したいものとなり、SubjectDN、およびポリシーOIDなどは新しいルールに従って発行いたします。
Trust Lifecycle Manager API統合
APIの処理を見直し、アプリケーションが新しいS/MIME BR要件を満たすための適切なプロファイル制限に準拠していることを確認してください。申請データに、ある証明書タイプでサポートされていないフィールド(例: mailbox-validatedタイプのOrganization)が含まれている場合、それらのフィールドは削除した上で証明書を発行します(CPには適用する証明書タイプそれぞれの値を含みます)。
EメールのDCV(ドメイン認証)
Trust Lifecycle Manager の自動化するワークフロー(REST APIを利用する場合を含む)では、Public S/MIME 証明書要求に含むEメール・ドメインを、認証済みドメインと照合します。
- 自動化フローまたはAPIは、発行申請に含むメールアドレスのメールドメインが事前認証されていない場合、エラーになります。
- APIを利用してMailbox-validated タイプのS/MIME証明書を発行できません。
※本ページは、こちら (英語) のページをもとに作成されています。