篩選依據: compliance x 清除

DigiCert to stop issuing SHA-1 code signing certificates

On Tuesday, December 1, 2020 MST, DigiCert will stop issuing SHA-1 code signing and SHA-1 EV code signing certificates.

Note: All existing SHA-1 code signing/EV code signing certificates will remain active until they expire.

Why is DigiCert making these changes?

To comply with the new industry standards, certificate authorities (CAs) must make the following changes by January 1, 2021:

  • Stop issuing SHA-1 code signing certificates
  • Stop using SHA-1 intermediate CA and SHA-1 root certificates to issue SHA-256 algorithm code signing and timestamping certificates

See Appendix A in the Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates.

How do the SHA-1 code signing certificate changes affect me?

If you rely on SHA-1 code signing certificates, take these actions as needed before December 1, 2020:

  • Get your new SHA-1 certificates
  • Renew your SHA-1 certificates
  • Reissue and get needed SHA-1 certificates

For more information about the December 1, 2020 changes, see our knowledgebase article DigiCert to Stop Issuing SHA-1 Code Signing Certificates.

If you have additional questions, please contact your account manager or our support team.


DigiCert will stop issuing 2-year public SSL/TLS certificates

On August 27, 2020 5:59 pm MDT (23:59 UTC), DigiCert will stop issuing 2-year public SSL/TLS certificates to prepare for the industry changes to the maximum allowed validity for public SSL/TLS certificates.

After the August 27 deadline, you can only purchase 1-year public SSL/TLS certificates.

What do I need to do?

To ensure you get needed 2-year public SSL/TLS certificates before the August 27 deadline:

  • Take inventory of needed 2-year certificates—new and renewals.
  • Order any 2-year certificates that you need before August 13.
  • Respond to any domain and organization validation requests in a timely manner.

To learn how this change will affect pending certificate orders, reissues, and duplicates, see End of 2-Year DV, OV, and EV public SSL/TLS certificates.

DigiCert Services API

For those using the DigiCert Services API, you'll need to update your API workflows to account for the new maximum certificate validity of 397 days for requests placed after the August 27 deadline. See Services API.

After August 27, 2020

After August 27, you can only purchase 1-year public SSL/TLS certificates. However, to maximize your SSL/TLS coverage, purchase your new certificates with a DigiCert® Multi-year Plan. See Multi-year Plans.

Why is DigiCert making this change?

On September 1, 2020, the industry says good-bye to 2-year certificates. Going forward Certificate Authorities (CA) can only issue public DV, OV, and EV SSL/TLS certificates with a maximum validity of 398 days (approximately 13 months).

DigiCert will implement a 397-day maximum validity for all public SSL/TLS certificates as a safeguard to account for time zone differences and to avoid issuing a public SSL/TLS certificate that exceeds the new 398-day maximum validity requirement.

Check out our blog to learn more about the transition to 1-year public SSL/TLS certificates: One-Year Public-Trust SSL Certificates: DigiCert’s Here to Help.


Multi-year Plans now available

We are happy to announce that Multi-year Plans are now available in CertCentral and CertCentral Partners.

DigiCert® Multi-year Plans allow you to pay a single discounted price for up to six years of SSL/TLS certificate coverage. With Multi-year Plans, you pick the SSL/TLS certificate, the duration of coverage you want (up to six years), and the certificate validity. Until the plan expires, you reissue your certificate at no cost each time it reaches the end of its validity period.

The maximum validity of an SSL/TLS certificate will go from 825 days to 397 days on September 1, 2020. When the active certificate for a Multi-year Plan is about to expire, you reissue the certificate to maintain your SSL/TLS coverage.


Browser support for TLS 1.0 and 1.1 has ended

The four major browsers no longer support Transport Layer Security (TLS) 1.0 and 1.1.

What you need to know

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

This change affects browser-dependent services and applications relying on TLS 1.0 or 1.1. Now that browser support for TLS 1.0 and 1.1 has ended, any out-of-date systems will be unable to make HTTPS connections.

What you need to do

If you are affected by this change and your system supports more recent versions of the TLS protocol, upgrade your server configuration as soon as you can to TLS 1.2 or TLS 1.3.

If you do not upgrade to TLS 1.2 or 1.3, your webserver, system, or agent will not be able to use HTTPS to securely communicate with the certificate.

Browser TLS 1.0/1.1 deprecation information

Firefox 78, released June 30, 2020

Safari 13.1, released March 24, 2020

Chrome 84, released July 21, 2020

Edge v84, released 7/16/2020

Helpful resources

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


CertCentral Services API: Updated error message documentation

In the Services API documentation, we've updated the Errors page to include descriptions for error messages related to:

  • Immediate DV certificate issuance
  • Domain control validation (DCV)
  • Certificate Authority Authorization (CAA) resource record checks

Earlier this year, we improved the APIs for DV certificate orders and DCV requests to provide more detailed error messages when DCV, file authorization, DNS lookups, or CAA resource record checks fail. Now, when you receive one of these error messages, check the Errors page for additional troubleshooting information.

For more information:


瀏覽器結束支援 TLS 1.0 和 1.1

在 2020 年,四款主流瀏覽器結束支援 Transport Layer Security (運輸層安全性,TLS) 1.0 和 1.1。

此變更不會影響您 DigiCert 憑證。您的憑證將一如以往持續運作。


此變更影響依賴瀏覽器的服務和依賴 TLS 1.0 或 1.1 的應用程式。瀏覽器的 TLS 1.0 或 1.1 支援一結束時,這些過期的系統將無法進行 HTTPS 連線。


如果您受到此變更影響,計畫立刻啟用或升級到 TLS 1.2 或 TLS 1.3。給您自己處理任何問題的前置時間。在您開始前,請確定找出所有可能使用 TLS 1.0 或 1.1 的系統。

記得檢查 Apache 或 Microsoft IIS 等網頁伺服器、.NET Framework、伺服器監控代理程式、以及其他可能使用的商業應用程式。


由於有如此多不同類型的系統依賴 TLS,因此我們無法涵蓋所有可用的升級路徑,但在此有些可能有幫助的參考:


Microsoft 將終止支援第三方核心模式驅動程式套件數位簽章

簽署您的核心模式驅動程式套件的程序正在改變。從 2021 年起,Microsoft 將是生產核心模式代碼簽章的唯一提供者。往後,您將需要開始依照 Microsoft 的更新指示簽署任何新的核心模式驅動模式套件。請參閱 Windows 硬體合作夥伴中心

DigiCert 正在做什什麼與此有關的事項?

DigiCert 在此終止程序的第一步是從 Code Signing 憑證申請表中,移除 Microsoft Kernel-Mode Code 平台選項:新的、重新發行和續訂。


這如何影響我現有的核准模式 Code Signing 憑證?

您可以繼續使用您現有的憑證簽署 Kernel-Mode 驅動程式套件,直到其鏈結的跨簽署根到期為止。DigiCert 品牌跨簽署根憑證在 2021 年到期。

如需更多詳細資料,請參閱我們的知識文章 Microsoft sunsetting support for cross-signed root certificates with kernel-mode signing capabilities (Microsoft 終止支援有核心模式簽章功能的跨簽署根憑證)。


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 預定在今年的秋天發佈。這表示您需要立刻準備。

新的私密 SSL/TLS 憑證需求:

  • 必須使用來自簽章演算法的 SHA-2 糸列的演算法。SHA-1 簽署的 SSL/TLS 憑證不再受到信任。
  • 必須有 825 天或更少天數的有效期限。不再信任有超過 825 天的有效期限的 SSL/TLS 憑證。


如果您旳私密 SSL/TLS 憑證需要 Apple iOS 和 macOS 信任,請確認在 2019 年 7 月 1 日後發行的任何私密 SSL/TLS 憑證符合它們的新規定。如果您找到不符合這些規定的憑證,您要盡快採取這些行動:


Firefox 結尾金鑰產生支援

Firefox 69 推出後,Firefox 最終放棄 Keygen 的支援。在他們的瀏覽器中產生 Code Signing、Client 和 SMIME 憑證時,Firefox 使用他們的 Keygen 促進產生用於提交公用金鑰的金鑰材料。

註:Chrome 已放棄對產生金鑰的支援,而 Edge 和 Opera 從未支援。


在 DigiCert 發行您的 Code Signing、Client 和 SMIME 憑證後,我們傳送內有建立和安裝您的憑證的連結的電郵給您。

一發行 Firefox 69 時,您僅能使用兩款瀏覽器產生這些憑證:Internet Explorer 和 Safari。如果公司政策要求使用 Firefox,您可以使用 Firefox ESR 或可攜式 Firefox。

如需更多資訊,請參閱使用放棄對 Firefox 69 的 Keygen 支援


  • 您仍可以使用 Firefox 69 進行用戶端驗證。首先,在 IE 11 或 Safari 中,產生 SMIME 憑證。然後,將 SMIME 憑證匯入 Firefox 中。
  • 若要略過在您的瀏覽器中產生 Code Signing、Client 和 SMIME 憑證,請連同您的訂單產生和訂交 CSR。DigiCert 將改為傳送附有憑證的電郵給您來取代連結。


此新狀態表示 DigiCert 已驗證訂單,而且憑證正等待使用者/電郵收件人在其中一款支援的瀏覽器中產生:IE 11、Safari、Firefox 68 和可攜式 Firefox

(在資訊看板功能表中,按一下憑證 > 訂單。然後,在「訂單」頁面上,按一下 Code Signing 或 Client 憑證訂單的訂單編號。)


我們更新了我們的 Extended Validation (延伸驗證,EV) Code Signing (代碼簽章,CS)Document Signing (文件簽章,DS) 憑證重新發行程序,讓您可以重新發行這些憑證,毋須自動撤銷目前的憑證 (原始或之前重新發行的憑證)。

註:如果您不需要目前的憑證 (原始或之前重新發行的憑證),您需要聯絡支援團隊,這樣他們才能為您撤銷。

現在,下次您重新發行 EV CS 或 DS 憑證時,您可以保持啟用之前發行的憑證到其目前的有效期間為止 (或只要您需要)。



關於公用和私密憑證,憑證授權機關 (CA) 不接受您的憑證訂單或組織預先驗證要求中的部份地址的縮寫:

  • 州或省*
  • 城市或地區*



我們讓在提交您的網域進行驗證時 (預先驗證或透過憑證訂單),定義您帳戶的網域驗證範圍變得更加容易。


  • 提供準確的網域名稱供驗證
    使用此選項,提交新網域的要求進行驗證是否完全符合命名 (即提交用於 sub.example.com 的要求進行驗證是否完全符合 sub.example.com)。“更高層”網域 (例如 example.com) 的驗證也適用。這是 CertCentral 的預設行為。
  • 將驗證限制在基本網域
    此選項允許您將網域驗證限制在基本網域 (例如 example.com)。關於納入新子網域的要求 (例如 sub.example.com),我們僅接受基本網域 (例如 example.com) 的網域驗證。子網域 (例如 sub.example.com) 的驗證不適用。

若要設定您帳戶的網域驗證範圍,請在資訊看板功能表中,按一下設定 > 喜好設定。在「分區喜好設定」頁面上,展開進階設定。在「網域控制驗證 (DCV)」 區段的網域驗證範圍下,,您會看到新的設定。


我們修復了漏洞,其中我們將 Wildcard SSL 憑證重新發行和新憑證訂單上,允許的最多 SAN 數目限制在 10 個。

現在,當重新發行或訂購新的 Wildcard SSL 憑證時,您可以新增最多 250 個 SAN。



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 方法。


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

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


在 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


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

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



納入 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 交換) 憑證



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

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



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

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




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 曲線雜湊配對的憑證?不要擔心。在續訂憑證時,將自動使用支援的曲線雜湊配對發行。


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

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



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

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



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



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


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

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



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

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

八月 1, 2018


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

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

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

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

五月 25, 2018


DigiCert 遵守 GDPR

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

DigiCert 聲明

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


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

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

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

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

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


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


  • 構建的電郵
  • HTTP Practical Demonstration (HTTP 現實論證)

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

五月 10, 2018


業界標準允許憑證發行機關 (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


作為整個業界脫離 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


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


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

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

三月 1, 2018


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

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

二月 21, 2018


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



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


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

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


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

十月 24, 2017


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

九月 8, 2017


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

七月 28, 2017


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

七月 21, 2017


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

七月 10, 2017


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