DigiCert ending support for vPro and KDC/SmartCardLogon EKUs in publicly trusted TLS/SSL certificates
On February 15, 2021, DigiCert will no longer issue public TLS/SSL certificates that include these EKUs
This means, as of February 15, 2021, we will no longer issue public TLS/SSL certificates that include either of these EKUs.
How does this affect me?
For most customers, this change will go unnoticed. It does not affect your TLS/SSL certificates or your TLS/SSL certificate process.
Note: By default, DigiCert does not issue public TLS/SSL certificates with the Intel vPro EKU or the KDC/SmartCardLogon EKU. To use these EKUs, we must first enable special certificate profiles for your account.
What if I use the Intel vPro EKU or the KDC/SmartCardLogon EKU in my public TLS/SSL certificates?
First, this change does not affect your existing public TLS/SSL certificates that include these EKUs. These certificates will continue to work as they always have until they expire.
However, on February 15, 2021, we will remove the Intel vPro EKU and KDC/SmartCardLogon EKU certificate profile options from all accounts. DigiCert will no longer issue new public TLS/SSL certificate orders the include these EKUs, including renewals, reissues, and duplicates.
Why is DigiCert doing this?
Industry standards specify that certificate authorities (CAs) should not include the Intel vPro and KDC/SmartCardLogon EKUS in public TLS/SSL certificates.
Therefore, to align with industry standards, we must stop including the Intel vPro and KDC/SmartCardLogon EKUS in our public TLS/SSL certificates.
More importantly, industry standards state that CAs should only include the serverAuth and, optionally, the clientAuth EKUs in public TLS certificates. See f. extKeyUsage (required) in section 7.1.2.3 Subscriber Certificate of the Baseline Requirements.
As of February 15, 2021, we will only include the serverAuth EKU and, as needed, the clientAuth EKU in our public TLS/SSL certificates.
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:
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:
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:
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.
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:
Microsoft is sunsetting support for third-party kernel-mode driver package digital signatures
The process for signing your kernel-mode driver packages is changing. Starting in 2021, Microsoft will be the sole provider of production kernel-mode code signatures. You will need to start following Microsoft’s updated instructions to sign any new kernel-mode driver packages going forward. See Partner Center for Windows Hardware.
What is DigiCert doing about this?
As a first step in this sunsetting process, DigiCert has removed the Microsoft Kernel-Mode Code platform option from Code Signing certificate request forms: new, reissue, and renew.
This means going forward, you can no longer order, reissue, or renew a code signing certificate for the kernel-mode platform.
How does this affect my existing kernel-mode Code Signing certificate?
You can continue to use your existing certificates to sign Kernel-Mode driver packages until the cross-signed root it is chained to expires. DigiCert brand cross-signed root certificates expire in 2021.
For more details, see our knowledgeable article, Microsoft sunsetting support for cross-signed root certificates with kernel-mode signing capabilities.
Apple's new compliance requirements for Private SSL certificates
Apple recently announced some new security requirements for SSL/TLS certificate that will go into effect with the release of iOS 13 and macOS 10.15. These requirements affect private certificates issued after July 1, 2019.
For your public DigiCert SSL/TLS certificates, no action is required.
DigiCert public SSL/TLS certificates already meet all these security requirements. Your public SSL/TLS certificates aren't affected by these new requirements and will be trusted in iOS 13 and macOS 10.15.
What's new?
Apple is implementing additional security requirements for all SSL/TLS certificates that by design impact private SSL/TLS certificates. See Requirements for trusted certificates in iOS 13 and macOS 10.15.
DigiCert private SSL/TLS certificates meet these requirements, if issued by account administrators according to public certificate requirements.
We've provided a list of the requirements below that may affect your private SSL/TLS certificates. These versions of Apple's OS are slated to be released during the fall of this year. This means, you need to prepare now.
New private SSL/TLS certificate requirements:
What can you do?
If Apple iOS and macOS trust are required for your private SSL/TLS certificates, verify any private SSL/TLS certificates issued after July 1, 2019 meet their new requirements. If you find certificate that don't meet these requirements, you'll want to take these actions soon:
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
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:
*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:
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.
Industry standards change
As ofJuly 31, 2019 (19:30 UTC), you must use the HTTP Practical Demonstration DCV method to demonstrate control over IP addresses on your certificate orders.
For more information about the HTTP Practical Demonstration DCV method, see these instructions:
Currently, industry standards used to allow you to use other DCV methods to demonstrate control over your IP address. However, with the passing of Ballot SC7, the regulations for IP address validation changed.
Ballot SC7: Update IP Address Validation Methods
This ballot redefines the permitted processes and procedures for validating the customer's control of an IP Address listed in a certificate. Compliance changes for Ballot SC7 go into effect on July 31, 2019 (19:30 UTC).
To remain compliant, as of July 31, 2019 (19:30 UTC), DigiCert only allows customers to use the HTTP Practical Demonstration DCV method to validate their IP addresses.
Removing Support for IPv6
As of July 31, 2019 (19:30 UTC), DigiCert has removed support for certificates for IPv6 addresses. Due to server limitations, DigiCert is unable to reach out to IPv6 address to verify the file placed on the customer's website for the HTTP Practical Demonstration DCV method.
We've updated the CertCentral SAML Federation Settings, enabling you to keep your Federation Name from appearing in the list of IdPs on the SAML Single Sign-On IdP Selection and SAML certificate requests IdP Selection pages.
Now, on the Federation Settings page, under Your IDP's Metadata, we added the Include Federation Name option. If you want to keep your Federation Name from appearing in the list of IdPs on the IdP Selection page, uncheck Add my Federation Name to the list of IdPs.
Secure Site Pro TLS/SSL certificates are available in CertCentral. With Secure Site Pro, you're charged per domain; no base certificate cost. Add one domain, get charged for one. Need nine domains, get charged for nine. Secure up to 250 domains on one certificate.
We offer two types of Secure Site Pro certificates, one for OV certificates and one for EV certificates.
Benefits included with each Secure Site Pro certificate
Each Secure Site Pro certificate includes – at no extra cost – first access to future premium feature additions to CertCentral (e.g., CT log monitoring and validation management).
Other benefits include:
To activate Secure Site Pro certificates for your CertCentral account, contact your account manager or our support team.
To learn more about our Secure Site Pro certificates, see DigiCert Secure Site Pro.
Public SSL certificates can no longer secure domain names with underscores ("_"). All previously issued certificates with underscores in domain names must expire prior to this date.
Note: The preferred underscore solution is to rename the hostnames (FQDNs) that contain underscores and replace the certificates. However, for those situations where renaming is not possible, you can use private certificates and, in some cases, you can use a wildcard certificate that secures the entire domain.
For more details, see Retiring Underscores in Domain Names.
Industry standard requirements for including the CanSignHttpExchanges extension in an ECC SSL/TLS certificate:
*Note: These requirements took effect as of May 1, 2019. The Signed HTTP Exchanges extension is under active development. There may be additional changes to the requirements as industry development continues.
The 90-day maximum certificate validity requirement doesn't affect certificates issued prior to May 1, 2019. Note that reissued certificate will be truncated to 90-days from the time of reissue. However, you can continue reissuing the certificate for the full purchased validity period.
CanSignHttpExchanges extension
Recently, we added a new certificate profile, HTTP Signed Exchanges to help address the AMP URL display issue where your brand isn’t displayed in the address bar. See, Display better AMP URLs with Signed Exchanges.
This new profile allows you to include the CanSignHttpExchanges extension in OV and EV SSL/TLS certificates. Once enabled for your account, the Include the CanSignHttpExchanges extension in the certificate option appears on your OV and EV SSL/TLS certificate order forms under Additional Certificate Options. See Get your Signed HTTP Exchanges certificate.
To enable this certificate profile for your account, please contact your account manager or contact our Support team.
CAs can no longer issue 30-day public SSL certificate containing underscores in domain names (common names and subject alternative names).
Note: The preferred underscore solution is to rename the hostnames (FQDNs) that contain underscores and replace the certificates. However, for those situations where renaming is not possible, you can use private certificates and, in some cases, you can use a wildcard certificate that secures the entire domain.
For more details, see Retiring Underscores in Domain Names.
Final day you can order 30-day public SSL certificates containing underscores in domain names (common names and subject alternative names) from any CA.
Note: The preferred underscore solution is to rename the hostnames (FQDNs) that contain underscores and replace the certificates. However, for those situations where renaming is not possible, you can use private certificates and, in some cases, you can use a wildcard certificate that secures the entire domain.
For more details, see Retiring Underscores in Domain Names.
No action is required on your part.
As of February 13, 2019, DigiCert no longer issues ECC TLS/SSL certificates (i.e., certificates with ECDSA keys) with the curve-hash pair P-384 with SHA-2 512 (SHA-512). This curve-hash pair is not compliant with Mozilla's root store policy.
Mozilla's root store policy supports these curve-hash pairs only:
Note: Do you have a certificate with a P-384 with SHA-512 curve-hash pair? Don't worry. When it’s time to renew the certificate, it will automatically be issued using a supported curve-hash pair.
Certificate Authorities (CAs) revoked all public SSL certificates containing underscores (in the common name and subject alternative names) with a maximum validity of more than 30 days by end of day (UTC time).
If you had an SSL certificate with a total validity of 31 days or more (which includes all 1-year, 2-year, and 3-year certificates) that expired after January 14, 2019, the CA who issued your certificate was required to revoke it.
For more details, see Retiring Underscores in Domain Names.
DigiCert began issuing public SSL certificates containing underscores for a limited time.
For more details, see Retiring Underscores in Domain Names.
In the top menu, we added two new contact support options (phone and chat icons) making it easier to contact support from within CertCentral (via email, chat, or phone).
The phone icon provides you with email and phone options. The chat icon provides you with a chat window where you can start a chat with one of our dedicated support team members.
We enhanced the sidebar menu, making it easier to see the menu option for the pages you are visiting. Now, when you visit a page in CertCentral, the menu option for that page will have a horizontal blue bar next to it.
We fixed a bug in the Add Organization feature on the SSL/TLS certificate request forms where the validation status (EV and OV validated) was not included for new organizations added and validated as part of the certificate order.
Now, new organizations added when ordering an SSL certificate will show a Validated status.
Note: The organization's validation status doesn't appear until we've fully validated the organization.
Industry standards compliance change. For publicly trusted certificates, underscores ( _ ) can no longer be included in subdomains. RFC 5280 now enforced for subdomains as well.
See Publicly Trusted Certificates – Data Entries that Violate Industry Standards.
Industry standards changed and removed two Domain Control Validation (DCV) methods from the Baseline Requirements (BRs).
Starting August 1, 2018, Certificate Authorities can no longer use the following domain control validation (DCV) methods:
To learn more about some of the available DCV methods, see Domain Control Validation (DCV) Methods.
DigiCert Compliance with GDPR
The General Data Protection Regulation (GDPR) is a European Union law on data protection and privacy for all individuals within the EU. The primary aim is to give citizens and residents of the EU more control over their personal data and to simplify the regulatory environment for international business by unifying the regulations within the EU. The GDPR went into effect on May 25, 2018. More Details »
DigiCert Statement
DigiCert worked to understand and comply with GDPR. We were aligned with GDPR when it went into effect on May 25, 2018. See Meeting the General Data Protection Regulation (GDPR).
GDPR Impact on WHOIS-based Email Domain Control Validation (DCV)
The European Union’s General Data Protection Regulation (GDPR) went into effect on May 25th, 2018. The GDPR requires data protection for natural persons (not corporate entities) residing within the European Union (EU).
DigiCert worked with ICANN to keep WHOIS information available. ICANN announced that it continues to require registries and registrars to submit information to WHOIS, with a few changes to address GDPR. See A Note on WHOIS, GDPR and Domain Validation.
Do you rely on WHOIS-based Email domain validation?
Check with your domain registrar to find out if they are using an anonymized email or a web form as a way for CAs to access WHOIS data as part of their GDPR compliance.
For the most efficient validation process, let your registrar know that you want them to either continue using your full published records or use an anonymized email address for your domains. Using these options will ensure minimal-to-no-impact on our validation processes.
Does your registrar use an anonymized email or a web form as a way for CAs to access WHOIS data? If so, we can send the DCV email to the addresses listed in their WHOIS record.
Does your registrar mask or remove email addresses? If so, you will need to use one of the other methods to prove control over your domains:
For more information about constructed email addresses and other alternative DCV methods, see Domain Control Validation (DCV) Methods.
Industry standards allow a Certificate Authority (CA) to issue an SSL/TLS certificate for a domain that only has CAA records containing no "issue"/"issuewild" property tags.
When a CA queries a domain's CAA RRs and finds records with no "issue" or "issuewild" property tags in them, a CA can interpret this as permission to issue the SSL/TLS certificate for that domain. See Ballot 219: Clarify handling of CAA Record Sets with no "issue"/"issuewild" property tag.
To learn more about the CAA RR check process, see our DNS CAA Resource Record Check page.
As part of the industry-wide move away from of TLS 1.0/1.1 and to maintain our PCI compliance, DigiCert disabled TLS 1.0/1.1 on April 1, 2018. DigiCert only supports TLS 1.2 and higher going forward. See Deprecating TLS 1.0 & 1.1.
DigiCert implements an improved Organization Unit (OU) verification process.
Per Baseline Requirements:
"The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with Section 11.2…"
Note: The OU field is an optional field. It is not required to include an organization unit in a certificate request.
As of March 1, 2018, 825 days is the maximum allowed length for a reissued (or duplicate issued) public 3-year SSL/TLS certificate.
For a 3-year OV certificate issued after March 1, 2017, be aware that during the first year of the 3-year certificate's lifecycle, all reissued and duplicate certificates may have a shorter lifecycle than the "original" certificate, and these reissued certificates will expire first. See
How does this affect my 3-year certificate reissues and duplicate issues?.
As of February 21, 2018, DigiCert only offers 1 and 2-year public SSL/TLS certificates due to changes in industry standards that limit the maximum length of a public SSL certificate to 825 days (approximately 27 months). See February 20, 2018, Last Day for New 3-Year Certificate Orders.
This is for informational purposes only, no action is required.
As of February 1, 2018, DigiCert publishes all newly issued public SSL/TLS certificates to public CT logs. This does not affect any OV certificates issued before February 1, 2018. Note that CT logging has been required for EV certificates since 2015. See DigiCert Certificates Will Be Publicly Logged Starting Feb. 1.
New "exclude from CT log when ordering a certificate" feature added to CertCentral. When you activate this feature (Settings > Preferences), you allow account users to keep public SSL/TLS certificates from being logged to public CT logs on a per certificate order basis.
While ordering an SSL certificate, users have an option not to log the SSL/TLS certificate to public CT logs. The feature is available when a user orders a new certificate, reissues a certificate, and renews a certificate. See CertCentral Public SSL/TLS Certificate CT Logging Guide.
New optional CT logging opt out field (disable_ct) added to the SSL certificate request API endpoints. Also, a new CT Log issued certificate opt out endpoint (ct-status) added. See CertCentral API Public SSL /TLS Certificate Transparency Opt Out Guide.
Industry standards change for CAA Resource Record checks. Modified the process to check CNAME chains containing 8 CNAME records or less, and the search doesn’t include the parent of a target of a CNAME record. See DNS CAA Resource Record Check.
Industry standards change for certificate issuance. Modified the certificate issuance process to check DNS CAA Resource Records. See DNS CAA Resource Record Check.
Industry standards compliance changes; improved RFC 5280 violations checks and enforcements. See Publicly Trusted Certificates – Data Entries that Violate Industry Standards.
Industry standards change to validation process. Validation information (DCV or organization) older than 825 days must be revalidated before processing a certificate reissue, renewal, or issue. More details »
Industry standards compliance changes; added support for additional domain control validation (DCV) methods. See Domain Pre-Validation: Domain Control Validation (DCV) Methods.
