フィルタリング: compliance x 消去

Browser support ending for TLS 1.0 and 1.1

In 2020, the four major browsers are ending support for Transport Layer Security (TLS) 1.0 and 1.1.

This change doesn't affect your DigiCert certificates. Your certificates will continue to work as they always have.

What you need to know

This change affects browser-dependent services and applications relying on TLS 1.0 or 1.1. Once browser support for TLS 1.0 or 1.1 ends, these out-of-date systems will be unable to make HTTPS connections.

What you need to do

If you are affected by this change, plan to enable or upgrade to TLS 1.2 or TLS 1.3 now. Give yourself lead time to deal with any problems. Before you start, make sure to identify all systems that might use TLS 1.0 or 1.1.

Remember to check web servers like Apache or Microsoft IIS, .NET Framework, server monitoring agents, and other commerce applications that might use it.

Helpful resources

With so many different types of systems relying on TLS, we can't cover all available upgrade paths, but here are a few references that may help:


Apple のプライベート SSL 証明書への新しい準拠要件

Apple は最近、SSL/TLS 証明書のいくつかの新しいセキュリティ要件が iOS 13 および macOS 10.15 のリリースと同時に実施されると発表しました。これらの要件は、2019年7月1日発行のパブリックおよびプライベート証明書について有効となります。

パブリック DigiCert SSL/TLS 証明書については、特に必要な対応はありません。

DigiCert パブリック SSL/TLS 証明書はすでに、これらすべてのセキュリティ要件を満たしています。お使いのパブリック SSL/TLS 証明書は、これらの新しい要件の影響は受けず、iOS 13 および macOS 10.15 での信頼を得ています。


Apple は、デザイン上、プライベート SSL/TLS 証明書に影響を及ぼす、すべての SSL/TLS 証明書向けに追加のセキュリティ要件を実装します。「iOS 13 および macOS 10.15 のトラスト証明書の要件」 を参照してください。DigiCert プライベート SSL/TLS 証明書は、パブリック証明書要件にしたがってアカウント管理者が発行した場合は、これらの要件を満たしています。

以下は、プライベート SSL/TLS 証明書に影響を及ぼす可能性がある要件のリストです。幸い、これらのバージョンの Apple の OS は、本年秋にリリース予定です。すなわち、準備する時間があることになります。

  • 署名アルゴリズムの SHA-2 ファミリーのアルゴリズムを使用する必要があります。SHA-1 署名証明書は、SSL/TLS 向けには信頼がありません。
  • 有効期間が 825日またはそれ以下である必要があります。有効期間が825日またはそれ以上の SSL/TLS 証明書は、信頼されません。

これらの要件を満たしていないプライベート証明書をお持ちで、Apple iOS および macOS トラストがお使いのプライベート証明書に必要な場合、2019年7月1日以降に発行されたプライベート SSL/TLS 証明書が初回発行あるいは iOS 13 および macOS 10.15 の一般利用前に再発行されていることの確認が必要になります。「SSL/TLS 証明書を再発行する」 を参照してください。


Firefox ending key generation support

With the release of Firefox 69, Firefox will finally drop support for Keygen. Firefox uses Keygen to facilitate generating key material for submitting the public key when generating Code Signing, Client, and SMIME certificates in their browser.

Note: Chrome already dropped support for key generation, and Edge and Opera never supported it.

How does this affect you?

After DigiCert issues your Code Signing, Client, or SMIME certificates, we send you an email with a link to create and install your certificate.

Once Firefox 69 is released, you can only use two browsers to generate these certificates: Internet Explorer and Safari. If company policy requires the use of Firefox, you can use Firefox ESR or a portable copy of Firefox.

For more information, see Keygen support to be dropped with Firefox 69.

Tips and tricks

  • You can still use Firefox 69 for client authentication. First, generate the SMIME certificate in IE 11 or Safari. Then, import the SMIME certificate to Firefox.
  • To bypass generating Code Signing, Client, or SMIME certificates in your browser, generate and submit a CSR with your order. Instead of a link, DigiCert will send you an email with your certificate attached.

We added a new status, Emailed to Recipient, to the Orders and Order Details pages, for Code Signing and Client certificate orders, making it easier to identify where these orders are in the issuance process.

This new status indicates the DigiCert has validated the order, and the certificate is waiting for the user/email recipient to generate it in one of the supported browsers: IE 11, Safari, Firefox 68, and portable Firefox.

(In the sidebar menu, click Certificates > Orders. Then, on the Orders page, click the order number for the Code Signing or Client certificate order.)


We updated our Extended Validation (EV) Code Signing (CS) and Document Signing (DS) certificate reissue processes, enabling you to reissue these certificates without automatically revoking the current certificate (original or previously reissued certificate).

Note: If you don't need the current certificate (original or previously reissued certificate), you'll need to contact support so they can revoke it for you.

Now, the next time you reissue an EV CS or DS certificate, you can keep the previously issued certificate active to its current validity period (or for as long as you need it).


Industry standards compliance reminder

For public and private certificates, Certificate Authorities (CAs) don't accept abbreviations for these parts of an address in your certificate orders or organization pre-validation requests:

  • State or Province*
  • City or Locality*

*This applies to organization and jurisdiction addresses.


We made it easier to define the domain validation scope for your account when submitting your domains for validation (pre-validation or via certificate orders).

On the Division Preferences page, we added two domain validation scope options:

  • Submit exact domain names for validation
    With this option, requests for new domains are submitted for validation exactly as named (i.e., request for sub.example.com is submitted for validation exactly as sub.example.com). Validation for the “higher level” domain (e.g., example.com) also works. This is the default behavior for CertCentral.
  • Restrict validation to base domain only
    This option allows you to restrict domain validation to the base domain (e.g., example.com). For request that include new subdomains (e.g., sub.example.com), we only accept domain validation for the base domain (e.g., example.com). Validation for the subdomain (e.g., sub.example.com) won’t work.

To configure the domain validation scope for your account, in the sidebar menu, click Settings > Preferences. On the Division Preference page, expand Advanced Settings. In the Domain Control Validation (DCV) section, under Domain Validation Scope, you'll see the new settings.


We fixed a bug where we were limiting the maximum allowed number of SANS to 10 on Wildcard SSL certificate reissue and new certificate orders.

Now, when reissuing or ordering a new Wildcard SSL certificate, you can add up to 250 SANs.



2019年7月31日 (19:30 UTC) 現在、証明書オーダーで IP アドレスの利用権を確認するには、HTTP 実際的証明 DCV 方法を使用する必要があります。

HTTP 実際的証明 DCV 方法についての詳細は、以下の説明を参照してください。

現在、IP アドレスの利用権を証明する他の DCV 方法の使用許可に使用する業界基準ただし、バロット SC7 のパスにより、IP アドレス認証の規則が変更になりました。

バロット SC7:IP アドレス認証方法を更新する

このバロットにより、証明書に記載の IP アドレスの顧客による利用権の認証の許可プロセスと手順が再定義されています。バロット SC7 への準拠変更は、2019年7月31日 (19:30 UTC) に発効となります。

2019年7月31日 (19:30 UTC) 現在で準拠を維持するため、DigiCert は顧客に HTTP 実際的証明 DCV 方法を使用した IP アドレスの認証にかぎり許可しています。

Ipv6 サポートの削除

2019年7月31日 (19:30 UTC) 現在、DigiCert は、IPv6 アドレスについての証明書のサポートを削除しました。サーバー上の制限により、DigiCert は IPv6 アドレスを利用して、 HTTP 実際的証明 DCV 方法向けに顧客のウェブサイトに配置されたファイルを確認することはできません。


当社では CertCentral SAML フェデレーション設定を更新し、[SAML シングルサインオン IdP 選択] および [SAML 証明書申請 IdP 選択] ページで、IdP のリストでのフェデレーション名の非表示が可能になります。

現在、[IDP のメタデータ]下の[フェデレーション設定]ページで、[フェデレーション名を含める] オプションが追加されています。IdP 選択ページ の IdP のリストでフェデレーション名を非表示にする場合は、,「IdP のリストにフェデレーション名を追加する」のチェックを外します。


グローバル サーバーID TLS/SSL 証明書は、CertCentral で利用できます。グローバル サーバーID により、ドメインごとの課金となり、証明書の基本コストはありません。1個のドメインを追加すると、1個ごとに課金されます。9個のドメインが必要な場合は、9個について課金されます。1つの証明書で最大250のドメインを安全保護します。

当社には2つのタイプのグローバル サーバーID 証明書があり、1つは OV 証明書用、もう1つは EV 証明書用です。

  • グローバル サーバーID SSL
    お客様のニースに適した OV 証明書を取得します。1個のドメイン、1個のワイルドカードドメインおよびすべてのサブドメインの暗号化と認証を行うか、あるいはサブジェクトの別名 (SAN) を使用して、複数のドメインとワイルドカードドメインを1個の証明書で安全保護します。
  • グローバル サーバーID EV SSL
    お客様のニーズに適した拡張認証証明書を取得します。暗号化と認証により1個のドメインを安全保護する、あるいはサブジェクトの別名 (SAN) を使用して複数のサイトを1個の証明書で安全保護します (完全適格ドメイン名)。

各グローバル サーバーID 証明書に付属の特典

各グローバル サーバーID 証明書には – 追加コスト不要で – CertCentral への将来のプレミアム機能追加への初回アクセス (例. CT ログ監視と認証管理) が含まれます。


  • 優先認証
  • 優先サポート
  • 2つのプレミアムサイトシール
  • マルウェアチェック
  • 業界最高の保障

グローバル サーバーID 証明書を CertCentral アカウントについて有効にするには、アカウントマネージャまたは当社の サポートチームにお問い合わせください。

グローバル サーバーID 証明書についての詳細は、「DigiCert グローバル サーバーID」を参照してください。


パブリック SSL 証明書は、下線付きドメイン名を安全保護することはできません ("_")。ドメイン名に下線が付いた、以前発行済の証明書はすべて、この日付前に有効期限切れとならなければなりません。

注意:下線を含み、証明書の代わる、下線の推奨解決方法 (FQDN)ただし、名前変更ができない状況では、プライベート証明書 を使用でき、また状況によっては、ドメイン全体を安全保護する ワイルドカード証明書 を使用することができます。



CanSignHttpExchanges 拡張子を ECC SSL/TLS 証明書に含める業界基準の要件:

  • "cansignhttpexchanges=yes" パラメータ* を含むドメインの CAA リソースレコード
  • 楕円曲線暗号 (ECC) 鍵ペア
  • CanSignHttpExchanges 拡張子
  • 最大90日の有効期間*
  • Signed HTTP Exchange のみに使用

*注意:これらの要件は、2019年5月1日発効済です。Signed HTTP Exchanges 拡張子は、鋭意開発中です。業界の開発が継続している中で、要件がさらに変更される場合があります。


CanSignHttpExchanges 拡張子

最近、新しい証明書プロフィール HTTP Signed Exchanges を追加し、お使いのブランドがアドレスバーに表示されない AMP URL 表示問題への対応を支援しました。「Signed Exchanges 付き AMP URL の表示を改善する」 を参照してください。

この新しいプロフィールにより、お客様は CanSignHttpExchanges 拡張子を OV と EV SSL/TLS 証明書に含めることができます。お使いのアカウントについて有効にした場合、[CanSignHttpExchanges 拡張子を証明書に含める] オプションが、[追加証明書オプション] 下の OV と EV SSL/TLS 証明書申請フォームに表示されます。「Signed HTTP Exchanges 証明書を取得する」 を参照してください。



CA は、ドメイン名に下線を含む30日パブリック SSL 証明書を発行することはできません (コモンネームおよびサブジェクトの別名)。

注意:下線を含み、証明書の代わる、下線の推奨解決方法 (FQDN)ただし、名前変更ができない状況では、プライベート証明書 を使用でき、また状況によっては、ドメイン全体を安全保護する ワイルドカード証明書 を使用することができます。



最終日、ドメイン名の下線を含む、30日パブリック SSL 証明書 (コモンネームとサブジェクトの別名) を CA からオーダーすることができます。

注意:下線を含み、証明書の代わる、下線の推奨解決方法 (FQDN)ただし、名前変更ができない状況では、プライベート証明書 を使用でき、また状況によっては、ドメイン全体を安全保護する ワイルドカード証明書 を使用することができます。




2019年2月13日現在、DigiCert では SHA-2 512 (SHA-512) の曲線ハッシュペア P-384 がある ECC TLS/SSL 証明書 (すなわち、ECDSA キー付き証明書) を発行していません。この曲線ハッシュペアは、Mozilla のルートストアポリシーに準拠していません。

Mozilla のルートストアポリシー がサポートしているのは、以下の曲線ハッシュペアのみです。

  • SHA-256 付き P‐256
  • SHA-384 付き P‐384

注意:SHA-512 曲線ハッシュペアのある P-384 付き証明書を持っていますか?心配ありません。証明書の更新時に、サポート対象の曲線ハッシュペアを使用して自動発行されます。


認証局 (CA) は、1日 (UTC 時間) の終わりまでに、30日以上の最大有効期間のある(コモンネームとサブジェクトの別名に)下線を含むすべてのパブリック SSL 証明書を失効にしました。

SSL 証明書が2019年1月14日以降有効期限切れとなる 31 日以上 (すべての1年、2年および3年証明書を含む) の合計有効期間を有する場合、その証明書を発行した CA は、失効にする必要があります。



DigiCert は、限定期間中、下線を含むパブリック SSL 証明書の発行を開始します。

  • ドメイン名に下線を含む、パブリック SSL 証明書向け最長30日の有効期間。
  • 下線は、ベースドメインに含まれては いけません ("example_domain.com" は使え ません)。
  • 下線は、もっとも左のドメインレベルに含まれてはいけません ("_example.domain.com" と "example_domain.example.com" は使え ません)。



トップメニューに、2つの新しいサポート連絡オプション(電話とチャットアイコン)を追加し、CertCentral から (メール、チャットまたは電話で) サポートに連絡しやすくなりました。

電話アイコン にはメールと電話オプションが付いています。チャットアイコン には、チャットウインドウがあり、当社の専属サポートチーム担当者の1人とチャットを開始できます。


サイドバーメニュー を強化し、,移動先のページのメニューオプションを確認しやすくなりました。CertCentral のページに移動したとき、そのページのメニューオプションの横に水平青色バーが表示されます。


認証ステータス (EV と OV 認証済) が証明書オーダーの一部として追加および認証された新しい組織に含まれない、 SSL/TLS 証明書申請フォームの [組織を追加する] 機能にあるバグを修正しました。

これで、SSL 証明書をオーダー時に追加された新しい組織が 認証済 ステータスを示します。



業界基準準拠の変更パブリックトラスト証明書については、サブドメインに下線 ( _ ) 含めることはできません。これで RFC 5280 は、サブドメインにも施行されます。

「パブリックトラスト証明書 – 業界基準に違反するデータエントリ」を参照してください。

8月 1, 2018


業界基準により、2つのドメイン名の利用権確認 (DCV) 方法がベースライン要件 (BR) から変更および削除されました。

2018年8月1日以降、認証局は以下のドメイン名の利用権確認 (DCV) 方法を使用することはできなくなります。

  • 申請者をドメイン連絡先として認証する
    この方法では、CA は、申請者がドメイン名レジストラで直接ドメイン連絡先となることを確認し、SSL/TLS 証明書オーダーについて、証明書申請者のドメイン名の利用権を確認することができます。
  • ドメイン名認証ドキュメント
    この方法では、CA は、ドメイン認証ドキュメントに記載のとおり、当該ドメインについて申請者が証明書をオーダーする権限を確認することにより、SSL/TLS 証明書オーダーについて証明書申請者のドメイン名の利用権を確認することができます。
    「項目 218:確認方法 1 と 5 を削除する」を参照してください。

利用可能な DCV 方法のいくつかについて詳細を確認するには、「ドメイン名の利用権確認 (DCV) 方法」を参照してください。

5月 25, 2018


DigiCert の GDPR への準拠

一般データ保護規則 (GDPR) は、欧州連合(EU) 圏内の個人すべてを対象としたデータ保護およびプライバシーに関する EU 法です。主な目的は、EU の市民と住民に個人データの管理権を付与し、EU での規制を統合することで国際ビジネス向けに規制環境を簡素化することです。GDPR は、2018年5月25日発効。もっと詳しく »

DigiCert 声明

DigiCert は、 GDPR を理解し準拠することに努めてきました。2018年5月25日の発効時に GDPR と連携しています。「一般データ保護規則 (GDPR)」を参照してください。


WHOIS ベースのメールドメイン名の利用権確認 (DCV) への GDPR の影響

EU の一般データ保護規則(GDPR) は2018年5月25日に発効。GDPR は、欧州連合 (EU) 圏内に在住の自然人(法人ではない)についてデータ保護を求めています。

DigiCert は ICANN と連携して、WHOIS 情報が常に利用できるように取り組んでいます。ICANN は、レジストリとレジストラに、GDPR への対応のため、少しの変更があった場合に、WHOIS に情報を提出するように求め続けることを発表しています。「WHOIS、GDPR およびドメイン名の利用権確認に関する注意」を参照してください。

WHOIS ベースのメールドメイン名の利用権確認に依拠していますか?

ドメインレジストラが GDPR 準拠の一部として、CA による WHOIS データアクセスの方法として匿名メールまたはウェブフォームを使用しているかを見つけるには、同ドメインレジストラに確認してください。


レジストラは CA が WHOIS データにアクセスする方法として、匿名メールを使用していますか、またはウェブフォームを利用していますか?上記いずれかの場合、当社で DCV メールを WHOIS レコードに記載のアドレスに送信することができます。


  • 構築メール
  • HTTP 実際的証明

構築メールとアドレスおよびその他代替 DCV 方法についての詳細は、「ドメイン名の利用権確認 (DCV) 方法」を参照してください。

5月 10, 2018


業界基準により、認証局 (CA) は、"issue"/"issuewild" プロパティタグを含まない CAA レコードのみを有するドメインについて、SSL/TLS 証明書を発行することができます。

CA がドメインの CAA RR を照会し、"issue" または "issuewild" プロパティタグがそこに含まれないレコードを見つけた場合、CA は、これをそのドメインについて SSL/TLS 証明書を発行する権限と解釈する場合があります。「項目 219:"issue"/"issuewild" プロパティタグを含まない CAA レコードセットの取扱いを明確にする」を参照してください。

CAA RR チェックプロセスについての詳細は、「DNS CAA リソースレコードチェック」 ページを参照してください。

4月 1, 2018


業界全体による TLS 1.0/1.1 からの移行の一部として、また PCI 準拠を維持するため、DigiCert は2018年4月1日をもって、TLS 1.0/1.1 を無効にしています。DigiCert は TLS 1.2 およびそれ以降のみをサポートします。「TLS 1.0 & 1.1 の廃止」を参照してください。

3月 2, 2018


DigiCert は、修正済組織部門 (OU) 確認プロセスを実行します。


"CA は、CA がセクション 11.2 にしたがってこの情報を確認しないかぎり、OU 属性が名前、DBA, 商号、商標、住所、場所、あるいは個別の自然人または法人を示すその他のテキストを含めるのを防止するプロセスを実行します…"

注意:OU フィールドは任意フィールドです。証明書申請に組織部門を含める必要はありません。


2018年3月1日現在、825日は、再発行済(または複製発行済)の3年パブリック SSL/TLS 証明書の許容最大長です。

2017年3月1日以降発行の3年 OV 証明書については、3年証明書試用期間の初年度期間中、すべての再発行および複製証明書の使用期間は "元の" 証明書より短くなる可能性があり、これらの再発行済証明書が先に有効期限切れとなりますので、留意してください。

2月 21, 2018


2018年2月21日現在、DigiCert は、パブリック SSL 証明書の最大長を825日(約27ヵ月)に制限する業界基準の変更により、提供できるのは、1年および2年パブリック SSL/TLS 証明書のみです。「2018年2月28日、新しい3年証明書オーダーの最終日」を参照してください。



2018年2月1日現在、DigiCert はすべての新規発行のパブリック SSL/TLS 証明書をパブリック CT ログ向けにパブリッシュしています。これは、2018年2月1日以より前に発行された OV 証明書には影響しません。2015年以降、EV 証明書には CT ログ記録が必要になっていますので、注意してください。「DigiCert 証明書は2月1日以降一般ログ記録予定」を参照してください。


新しく "「証明書オーダー時に CT ログを除外する」" 機能を CertCentral に追加。この機能を有効にする ([設定] > [環境設定]) 場合、アカウントユーザーはパブリック SSL/TLS 証明書が証明書オーダーごとにパブリック CT ログにログ記録されるのを防止することがdけいます。

SSL he証明書のオーダー時、ユーザーには、SSL/TLS 証明書をパブリック CT ログにログ記録しないオプションがあります。この機能は、ユーザーが新しい証明書をオーダー、証明書を再発行および証明書を更新するときに利用できます。「CertCentral パブリック SSL/TLS 証明書 CT ログ記録ガイド」を参照してください。


新しいオプションの CT ログ記録オプトアウトフィールド (disable_ct) を SSL 証明書申請 API エンドポイントに追加。また、新しい CT Log ログ発行済証明書オプトアウトエンドポイント (ct ステータス) を追加。「CertCentral API パブリック SSL /TLS Certificate Transparency オプトアウトガイド」を参照してください。

10月 24, 2017


CAA リソースレコードチェックについての業界基準の変更8個の CNAME レコードまたはそれ以下を含む CNAME チェーンをチェックするプロセスを修正しました。なお、検索には、CNAME レコードの対象の親は含まれません。「DNS CAA リソースレコードチェック」を参照してください。

9月 8, 2017


証明書発行についての業界基準の変更DNS CAA リソースレコードチェックのための証明書発行プロセスを修正「DNS CAA リソースレコードチェック」を参照してください。

7月 28, 2017


業界基準準拠の変更: RFC 5280 違反チェックおよび執行を改善「パブリックトラスト証明書 – 業界標準に違反したデータエントリ」を参照してください。

7月 21, 2017


認証プロセスの業界基準の変更825日より以前の認証情報 (DCV または組織) は、証明書再発行、更新または発行の処理前に認証が必要です。もっと詳しく »

7月 10, 2017


業界基準準拠の変更: 追加のドメイン名の利用権確認 (DCV) 方法へのサポートを追加「ドメインの事前認証:ドメイン名の利用権確認 (DCV) 方法」を参照してください。