篩選依據: compliance x 清除
compliance

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:

compliance

Apple 對 Private 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 的信任。

有什麼新消息?

由於設計對私密 SSL/TLS 憑證的影響,Apple 正在實行適用於所有 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 憑證

compliance

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.
new

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.)

enhancement

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).

compliance

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.

new

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.

fix

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.

compliance

業界標準變更

2019 年 7 月 31 日 (UTC 時間 19:30),您必須使用 HTTP Practical Demonstration DCV 方法,證明有您的憑證訂單上的 IP 位址的控制權。

如需更多有關 HTTP Practical Demonstration DCV 方法的資訊,請參閱這些指示:

目前,所使用的業界標準允許您使用其他 DCV 方法,證明有您的 IP 位址的控制權。但在通過 Ballot SC7 後,IP 位址驗證的法規已變更。

Ballot SC7:更新 IP 位址驗證方法

此次投票重新定義了驗證客戶對憑證中所列的 IP 位址的控制權的流程和程序。Ballot SC7 的遵規變更在 2019 年 7 月 31 日 (UTC 時間 19:30) 生效。

若要保持相容,在 2019 年 7 月 31 日 (UTC 時間 19:30),DigiCert 僅允許客戶使用 HTTP Practical Demonstration DCV 方法驗證他們的 IP 位址。

移除對 IPv6 的支援

2019 年 7 月 31 日 (UTC 時間 19:30),DigiCert 已移除對 IPv6 位址的憑證支援。由於伺服器的限制,DigiCert 無法連線到 IPv6 位址,以確認放置在客戶網站的檔案是否適用 HTTP Practical Demonstration DCV 方法。

enhancement

我們已更新「CertCentral SAML 聯盟設定」,讓您可以不讓您的聯盟名稱出現在 SAML 單一登入 IdP 選擇SAML 憑證要求 IdP 選擇頁面上的 IdP 清單中。

現在,在「聯盟設定」頁面的「您的 IDP 的中繼資料」下,我們新增了納入聯盟名稱選項。如果您不想要您的聯盟名稱出現在 IdP 選擇頁面的 IdP 清單上,,請取消勾選新增我的同盟名稱到 IdP 的清單中

new

在 CertCentral 中可用的 Secure Site Pro TLS/SSL 憑證。使用 Secure Site Pro 依照網域向您收費,沒有基礎憑證費用。新增一個網域就收取一個的費用。需要九個網域時,就收取九個的費用。保護一份憑證上最多 250 個網域的安全。

我們提供兩種類型的 Secure Site Pro 憑證,一種適用於 OV 憑證,另一種適用於 EV 憑證。

  • Secure Site Pro SSL
    取得符合您的需求的 OV 憑證。對網域、一個萬用字元網域和所有其子網域提供加密和驗證,或使用主體別名 (SAN) 以一份憑證保護多個網域和萬用字元網域的安全。
  • Secure Site Pro EV SSL
    取得符合您的需求的延伸驗證憑證。提供加密或驗證以保護一個網域的安全,或使用主體別名 (SAN) 以一份憑證保護多個網站的安全 (完全合格的網域名稱)。

每份 Secure Site Pro 憑證具有的優點

每份 Secure Site Pro 憑證都包括 – 無額外費用 – 先存取將來的其他進階功能到 CertCentral (例如 CT 記錄監控和驗證管理)。

其他優點包括:

  • 優先驗證
  • 優先支援
  • 兩個進階網站圖章
  • 惡意軟體檢查
  • 領先業界的保證

若要啟用用於您的 CertCentral 帳戶的 Secure Site Pro 憑證,請聯絡您的帳戶管理員或我們的支援團隊

若要瞭解更多有關我們的 Secure Site Pro 憑證的資訊,請參閱 DigiCert Secure Site Pro

compliance

Public SSL 憑證不再保護有底線 ("_") 的網域名稱的安全。網域名稱中,所有有底線的之前發行的憑證必須在此日期前到期。

註:喜好的底線解決方法是將包含底線的主機名稱 (FQDN) 重新命名,並且取代憑證。但對於無法重新命名的情況,您可以使用私密憑證,而且在有些情況中,您可以使用保護整個網域的安全的萬用字元憑證

如需更多詳細資料,請參閱去除網域名稱中的底線

compliance

納入 ECC SSL/TLS 憑證中的 CanSignHttpExchanges 延伸的業界標準規定:

  • 包括 "cansignhttpexchanges=yes" 參數*的網域的 CAA 資源記錄
  • Elliptic Curve Cryptography (ECC) 金鑰配對
  • CanSignHttpExchanges 延伸
  • 最長 90 天有效期限*
  • 僅適用於 Signed HTTP Exchange (簽署的 HTTP 交換)

*註:這些需求在 2019 年 5 月 1 日生效。在 Signed HTTP Exchanges 延伸目前在開發中。隨著業界持續開發,需求可能有其他變化。

90 天最長憑證有效期限規定不會影響在 2019 年 5 月 1 日前發行的憑證。請注意,重新發行的憑證將修改為從重新發行時算起的 90 天。.但您可以在完整的採購有效期限內持續重新發行憑證。

CanSignHttpExchanges 延伸

最近,我們新增了新的憑證設定檔 HTTP Signed Exchanges,協助解決 AMP URL 顯示問題,您的品牌未在位址列中顯示。請參閱顯示有 Signed Exchange 的更好的 AMP URL

此新的設定檔允許您在 OV 和 EV SSL/TLS 憑證中納入 CanSignHttpExchanges 延伸。一針對您的帳戶啟用後,在憑證中納入 CanSignHttpExchanges 延伸選項會出現在其他憑證選項下的您的 OV 和 EV SSL/TLS 憑證訂購表上。請參閱取得您的 Signed HTTP Exchange (簽署的 HTTP 交換) 憑證

若要啟用用於您的帳戶的此憑證設定檔,請聯絡您的帳戶管理員,或聯絡我們的支援團隊

compliance

CA 再也無法發行包含網域名稱 (一般名稱和主體別名) 中的底線的 30 天公用 SSL 憑證。

註:喜好的底線解決方法是將包含底線的主機名稱 (FQDN) 重新命名,並且取代憑證。但對於無法重新命名的情況,您可以使用私密憑證,而且在有些情況中,您可以使用保護整個網域的安全的萬用字元憑證

如需更多詳細資料,請參閱去除網域名稱中的底線

compliance

在最後一天,您可以訂購包含來自任何 CA 的網域名稱 (一般名稱和主體別名) 的 30 天公用 SSL 憑證。

註:喜好的底線解決方法是將包含底線的主機名稱 (FQDN) 重新命名,並且取代憑證。但對於無法重新命名的情況,您可以使用私密憑證,而且在有些情況中,您可以使用保護整個網域的安全的萬用字元憑證

如需更多詳細資料,請參閱去除網域名稱中的底線

compliance

您的方面不需要採取行動。

2019 年 2 月 13 日,DigiCert 不再發行曲線雜湊配對 P-384 與 SHA-2 512 (SHA-512) 的 ECC TLS/SSL 憑證 (即有 ECDSA 金鑰的憑證)。此曲線雜湊配對與 Mozilla 的根儲存政策不符。

Mozilla 的根儲存政策僅在以下情況支援這些曲線雜湊配對:

  • P‐256 with SHA-256
  • P‐384 with SHA-384

註:您是否有 P-384 與 SHA-512 曲線雜湊配對的憑證?不要擔心。在續訂憑證時,將自動使用支援的曲線雜湊配對發行。

compliance

憑證授權單位 (CA) 在當日結束 (UTC 時間) 前,撤銷最長有效期限超過 30 天,包含底線 (在一般名稱和主體別名中) 的所有公用 SSL 憑證。

如果您有有效期限共 31 天或以上的 SSL 憑證 (包括 1 年、2 年和 3 年憑證),在 2019 年 1 月 14 日到期,發行您的憑證的 CA 需要撤銷該憑證。

如需更多詳細資料,請參閱去除網域名稱中的底線

compliance

DigiCert 開始發行公用 SSL 憑證,其中包含有限時間的底線。

  • 網域名稱包含底線的公用 SSL 憑證的最長有效期是 30 天。
  • 底線不可在基礎網域中 (允許 "example_domain.com")。
  • 底線不可在最左邊的網域標籤中 (允許 "_example.domain.com" 和 "example_domain.example.com")。

如需更多詳細資料,請參閱去除網域名稱中的底線

new

在頂端功能表中,我們已新增兩個聯絡人支援選項 (電話和聊天圖示),這樣更容易聯絡來自 CertCentral 內的支援 (透過電子郵件、聊天或電話)。

電話圖示提供您電子郵件和電話選項。聊天圖示提供您聊天視窗,您可以在其中開始與我們的專屬支援團隊成員聊天。

enhancement

我們增強了資訊看板功能表,,使看到您正在瀏覽的頁面的功能表選項更加容易。現在,當您瀏覽 CertCentral 中的頁面時,用於該頁面的功能表選項將在旁邊有水平的藍色列。

fix

我們修復了 SSL/TLS 憑證申請表上的新增組織功能中的漏洞,其中的驗證狀態 (EV 和 OV 驗證) 不包括在新增和驗證作為憑證訂單的一部份的新組織中。

現在,在訂購 SSL 憑證時,新增的新組織將顯示驗證的狀態。

註:組織的驗證狀態直到我們完整驗證組織後才會出現。

compliance

業界標準法規遵循變更。關於公開受信任的憑證,子網域中再也不包括底線 ( _ )。現在 RFC 5280 也可以針對子網域執行。

請參閱公開受信任的憑證 – 違反業界標準的資料條目

八月 1, 2018

compliance

業界標準變更,並從基礎需求 (BR) 移除兩個網域控制驗證 (DCV) 方法。

從 2018 年 8 月 1 日起,憑證授權單位不再使用以下的網域控制驗證 (DCV) 方法:

  • 3.2.2.4.1 驗證申請人作為網域聯絡人
    此方法透過確認要求者是直接有網域名稱註冊機構的網域聯絡人,允許 CA 驗證憑證要求者有 SSL/TLS 憑證訂單上的網域的控制權。
  • 3.2.2.4.5 網域授權文件
    此方法使用確認要求者的授權單位,訂購網域授權文件中所包含的所謂的網域的憑證,以驗證憑證要求者有 SSL/TLS 憑證訂單上的網域的控制權。
    請參閱 Ballot 218:移除驗證方法 1 和 5

若要瞭解更多有關其中一些可用的 DCV 方法的資訊,請參閱網域控制驗證 (DCV) 方法

五月 25, 2018

compliance

DigiCert 遵守 GDPR

「一般資料保護規則」(GDPR) 是歐盟有關在歐盟內的所有個人的資料保護與隱私相關法律。主要目標在於提供歐盟的人民和居民更多對他們的個人資料的控制權,並透過統一歐盟內的法規簡化國際企業的監管環境。GDPR 在 2018 年 5 月 25 日生效。更多詳細資料 »

DigiCert 聲明

DigiCert 致力於理解與遵守 GDPR。自 2018 年 5 月 25 日生效起我們即遵守 GDPR。請參閱遵守一般資料保護規則 (GDPR)

compliance

GDPR 對基於 WHOIS 的電子郵件網域控制驗證 (DCV) 的影響

歐盟的「一般資料保護規則」(GDPR) 在 2018 年 5 月 25 日生效。GDPR 規定了居住在歐盟 (EU) 內的自然人 (非法人) 的資料保護。

DigiCert 與 ICANN 合作保持提供 WHOIS 資訊。ICANN 宣佈繼續要求登錄和註冊機構提交資訊給 WHOIS,有一些因應 GDPR 的變更。請參閱關於 WHOIS、GDPR 和網域驗證的注意事項

您是否依賴基於 WHOIS 的電子郵件網域驗證?

檢查您的網域註冊機構,瞭解他們是否使用匿名的電子郵件或網頁表格,作為存取他們遵守 GDPR 的一部份的 WHOIS 記錄的方式。

關於最有效率的驗證程序,讓您的註冊機構知道您想要他們繼續使用您完整發佈的記錄,或針對您的網域使用匿名的電子郵件地址。使用這些選項確保對我們的驗證程序有最小到將近沒有的影響。

您的註冊機構是否使用匿名電子郵件或網頁表格作為 CA 存取 WHOIS 資料的方式?如果是,您可以傳送 DCV 電子郵件到他們的 WHOIS 記錄中所列的位址。

您是否登錄遮罩或移除電子郵件地址。如果是,您需要使用其中一個其他方法證明有您的網域的控制權;

  • 構建的電子郵件
  • DNS TXT
  • DNS CNAME
  • HTTP Practical Demonstration

如需更多有關建構的電子郵件地址和其他替代 DCV 方法的資訊,請參閱網域控制驗證 (DCV) 方法

五月 10, 2018

compliance

業界標準允許憑證發行機關 (CA) 發行僅有 CAA 記錄的網域的 SSL/TLS 憑證,這些記錄不包含 "issue"/"issuewild" 屬性標籤。

當 CA 查詢網域的 CAA RR 並尋找其中沒有 "issue" 或 "issuewild" 屬性標籤的記錄時,CA 可以將此解譯為權限,以發行該網域的 SSL/TLS 憑證。請參閱 Ballot 219:說明沒有 "issue"/"issuewild" 屬性標籤的 CAA 記錄的處理

若要瞭解更多有關 CAA RR 檢查程序的資訊,請參閱我們的 DNS CAA 資源記錄檢查頁面。

四月 1, 2018

compliance

作為整個業界脫離 TLS 1.0/1.1 的一份子,以及保持遵守我們的 PCI,DigiCert 在 2018 年 4 月 1 日停用了 TLS 1.0/1.1。DigiCert 僅支援 TLS 1.2 和往後的更新版本。請參閱取代 TLS 1.0 和 1.1

三月 2, 2018

compliance

DigiCert 實施改良的組織單位 (OU) 驗證程序。

依基本需求:

"Ca「應」實行防止 OU 屬性納入名稱、DBA、商標名稱、商標、地址、位址或其與特定的自然人或法人有關的文字,除非 CA 已確認這些資訊與「11.2 節」相符…"

註:OU 欄位是選填的欄位。不需要在憑證要求中納入組織單位。

三月 1, 2018

compliance

2018 年 3 月 1 日,825 天是允許重新發行 (或發行複本) 公用 3 年 SSL/TLS 憑證的允許最長長度。

關於在 2017 年 3 月 1 日後發行的 3 年 OV 憑證,請注意在 3 年憑證的生命周期的第一年期間,所有重新發行和重複的憑證可能有比"原始的"憑證短的生命周期,而且這些重新發行的憑證將先到期。請參閱
這如何影響我的 3 年憑證重新發行和複本發行?

二月 21, 2018

compliance

2018 年 2 月 21 日,由於業界標準變更的因素,DigiCert 僅提供 1 年和 2 年公用 SSL/TLS 憑證,將公用 SSL 憑證的最長長度限制為 825 天 (約 27 個月)。請參閱 2018 年 2 月 20 日,新的 3 年憑證訂單的最後一天

compliance

這僅作為資訊用途,不需要任何動作。

2018 年 2 月 1 日,DigiCert 將所有新發行的公用 SSL/TLS 憑證發佈到公用 CT 記錄中。這不會影響在 2018 年 2 月 1 日前發行的任何 OV 憑證。請注意,自 2015 年起,EV 憑證需要 CT 記錄。請參閱從 2 月 1 日開始將公用記錄 DigiCert 憑證

enhancement

新增了新的"訂單憑證時從 CT 記錄排除"功能到 CertCentral 中。當您啟用此功能時 (設定 > 喜好設定),表示您允許帳戶使用者根據憑證訂單防止將公用 SSL/TLS 憑證記錄到公用 CT 記錄中。

訂購 SSL 憑證時,使用者可以選擇不將 SSL/TLS 憑證記錄到公用 CT 記錄中。此功能在使用者訂購新憑證、重新發行憑證和續訂憑證時可用。請參閱 CertCentral 公用 SSL/TLS 憑證 CT 記錄指南

enhancement

新的選用的 CT 記錄選擇退出欄位 (disable_ct) 新增到 SSL 憑證要求 API 端點中。此外,還新增新的 CT 記錄發行憑證選擇退出端點 (CT 狀態)。請參閱 CertCentral API 公用 SSL/TLS 憑證透明度選擇退出指南

十月 24, 2017

compliance

CAA 資源記錄的業界檢查變更檢查。修改了程序,以檢查包含 8 筆或以下的 CNAME 記錄的 CNAME 鏈,而且搜尋不包括 CNAME 記錄的目標的父項。請參閱 DNS CAA 資源記錄檢查

九月 8, 2017

compliance

憑證發行的業界標準變更。修改憑證發行程序以檢查 DNS CAA 資源記錄。請參閱 DNS CAA 資源記錄檢查

七月 28, 2017

compliance

業界標準法規遵循變更;改良的 RFC 5280 違規檢查和執行。請參閱公開受信任的憑證 – 違反業界標準的資料條目

七月 21, 2017

compliance

業界標準變更到驗證程序。在處理憑證重新發行、續訂或發行前,必須重新驗證 825 天前的驗證資訊 (DCV 或組織)。更多詳細資料 »

七月 10, 2017

compliance

業界標準遵規變更;新增的其他網域控制驗證 (DCV) 方法的支援。請參閱網域預先驗證:網域控制驗證 (DCV) 方法