TLS証明書インフォメーションセンター

Yes, all Entrust certificates issued up to and including November 11, 2024, will remain valid in Chrome until their expiration dates, and the Mozilla browser will continue to trust Entrust public TLS certificates issued on or before November 30, 2024, until they expire.

• Akamai will no longer trust certificates issued by Entrust root certificates for origin connections after November 30, 2025. 
• Customers can continue to issue certificates from Entrust with SSL.com as the CA for certificates expiring on or after December 1, 2025.
  • To support customer origin servers using certificates procured from Entrust and issued by SSL.com, below SSL.com root certificates have been added to the Akamai Certificate store: 
    • C=US, ST=Texas, L=Houston, O=SSL Corporation, CN=SSL.com EV Root Certification Authority ECC
    • C=US, ST=Texas, L=Houston, O=SSL Corporation, CN=SSL.com EV Root Certification Authority RSA R2
    • C=US, ST=Texas, L=Houston, O=SSL Corporation, CN=SSL.com Root Certification Authority ECC
    • C=US, ST=Texas, L=Houston, O=SSL Corporation, CN=SSL.com Root Certification Authority RSA
    • C=US, O=SSL Corporation, CN=SSL.com TLS ECC Root CA 2022
    • C=US, O=SSL Corporation, CN=SSL.com TLS RSA Root CA 2022

Entrust is committed to returning to the browser root stores. We continue to execute our improvement plans and are working closely with the browser community in discussions on our path forward.

As we complete our improvement plans, we look forward to reapplying to the browser root stores.

There is not a specific timeline. We will continue to provide further updates on our improvement plans and timelines over the coming months.

いいえ。 This issue is limited to publicly trusted TLS certificates, issued from specific Entrust roots, and we are putting in place a solution to ensure uninterrupted service. No other Entrust products are affected.

We are fully committed to returning to the browser root stores. We are executing our improvement plans and working closely with the browser community in discussions on our path forward.

We will continue to work with you, business as usual. Google’s decision relates to public TLS certificates issued from certain Entrust roots. No other Entrust products are affected.

• Entrust TLS server certificates issued on or before November 11, 2024 will continue to be trusted until they expire. Certificates issued after that date will be rejected.
• Customers can continue to issue certificates from Entrust with SSL.com as the CA for certificates expiring on or after November 12, 2024.
• Oracle will have support for the 2022 SSL roots in their October 2024 release.
• See Oracle's JDK and JRE cryptographic algorithms page for more information here.

• Public SSL certificates will continue to be created from the Entrust Certificate Services (ECS) portal or ECS REST API.
• Certificates will be delivered to the requester by Entrust.
• Full certificate lifecycle management (new, reissue, revoke, renew) will be managed by ECS.
• ECS licenses will remain valid and automatically carry over with this new process, with no action needed by the subscriber.
• No delay in certificate issuance is expected.
• SSL.com will be the default issuing CA for Public SSL certificates.
  • Default issuance path will be SSL.com; however, issuing SSL CA can be overridden by Entrust for non-traditional TLS use cases (where browser-trust is NOT required).

• We are providing the ID of the root that will sign certificates from ECS.
  • Customers can check that the root is in their browsers or other certificate stores.
• We are targeting a release for the week of September 30th, 2024 that will enable customers to test the new certificates and issuance path:
  • Start re-verifying domains with Entrust and SSL.com.
  • Issue SSL.com certificates from the ECS UI and API, while still being able to issue certificates from Entrust.
  • Issued certificates will be signed by the new CA Hierarchy.
  • These certificates will be fully valid production certificates.

SSL.com is now an Entrust CA partner. SSL.com is a global CA founded in 2002 with full browser ubiquity. They are used by businesses and governments in over 180 countries to protect internal networks, customer communications, e-commerce platforms, and web services, and we are pleased to partner with them to meet your needs.

In addition, we have partnered with Sectigo to offer additional options to issue public TLS certificates with Sectigo as the issuing CA. We will provide more information on when the integration with Sectigo once we have an updated integration roadmap defined.

• Organization Validation:
  • Organizations will continue to be managed via the Entrust Certificate Services (ECS) Portal - SSL.com will perform additional checks for "organization validation" prior to issuance being enabled.
  • Organization validation will continue through the ECS console, with SSL.com validating organization validations as collected by Entrust.
  • Existing verified organizations/clients will remain valid - no changes to current flow.
• Domain Validation:
  • Domains will continue to be managed via the Entrust Certificate Services (ECS) Portal, using the available automated methods in the ECS portal.
  • Domains must be re-verified through our new flow (in October 2024) to continue issuing TLS certificates - bulk domain verification tools are available in ECS.
  • Domains will continue to be re-verified every 398 days.
• We will verify domains for both Entrust & SSL.com CAs:
  • This allows customers to create any type of certificate once the domain is validated.
  • This will not impact user experience.

1. The Super-Admin on behalf of the ECS account holder needs to accept the legal updates. 
2. Each client, as the subscriber, needs to accept the Subscriber Agreement. 
3. Select the Issuing CA for this client: 
   1. On or before November 11, 2024: Customer may select Entrust until Nov 11 (default), or Entrust, or SSL.com and toggle between for testing SSL.com. 
   2. On or after November 12, 2024: Customer may select SSL.com (Default) or Entrust and toggle between if they wish to issue untrusted Entrust certificates. 

4. Re-validate all domains with Entrust after the first 3 steps are completed.

   After these updates, ECS is ready to issue certificates from the SSL.com CA.

This arrangement is outlined in the CA/Browser Forum Baseline Requirements, which empowers a CA to delegate RA functions to a delegated third-party. We have reviewed this arrangement with Google and their security blog now directs Entrust customers to discuss continuity plans with us. (If needed, see the CA/Browser Forum Baseline Requirements, Sec. 1.3.2).

Entrust is working toward a Delegated RA (Registration Authority).

いいえ。 You will continue to work with Entrust as you always have for issuance, renewal, verification, support, and professional services. You may be contacted by SSL.com as part of the domain validation process.

To ensure continuity, we recommend you assess your current public TLS certificates and business requirements. Renew all expiring public TLS certs with 398-day validity.

SSL.com certificates have 99.9% acceptance across browsers, tablets and mobile devices, including Chrome, Safari, Mozilla, Microsoft, and Opera browsers. You can find full details at https://www.ssl.com/browser_compatibility/.

Acceptance of SSL.com certificates in different countries would be the same as the acceptance of Entrust certificates. Any region or country that currently accepts Entrust certificates would also accept SSL.COM certificates, and vice versa. SSL publishes specific accepted and restricted country codes at https://www.ssl.com/country-codes/.

Venafi TPP is platform-agnostic. You will be able to use Venafi Trust Protection Platform (TPP) after Nov 11st to request either Entrust or SSL.com certificates dependant on your client setup. However, those Clients need to be manually configured in the ECS console.

• There are no configuration changes for customers (will use existing Entrust API and ACMEv2 server).
  • New display column in EAB (External Account Binding)

• Certificate Authority Authorization (CAA) is an optional security feature that allows domain owners to specify which Certificate Authorities (CAs) are authorized to issue certificates for their domains.
• The “entrust.net” CA ID for CAA will work for both certificates issued by Entrust and those issued by SSL.com – no action is required.
• Entrust Knowledge Base for CAA:
  • Add CAA record to your DNS Zone
  • Add CAA record to hosted DNS

Yes, we will continue to enable our partners to complete pre-verification data collection.

The end-entity SSL certificates will be issued by a new Entrust-branded intermediate CA. This intermediate certificate will be chained to the SSL.COM root CA.

SSL.com currently offers Domain Validation (DV), Organization Validation (OV), and Extended Validation (EV) certificates, which align with the certificate types supported by Entrust. 

Entrust-issued QWAC PSD2 certificates are not affected as they do not rely on browser trust. Entrust-issued QWAC eIDAS certificates are affected by the browsers' decision. 

For QWAC eIDAS certificates to be issued on or after Nov 12, 2024, we will be happy to supply/resell certificates from D-Trust. To view additional FAQs related to D-Trust QWAC eIDAS, click here.

The end-entity SSL certificates will be issued by new Entrust-branded intermediate CA’s hosted and operated by SSL.com, and chained to SSL.COM root CA’s. This approach ensures full compliance with CA/Browser Forum requirements and provides the necessary transparency and trust.

Entrust-issued QWAC PSD2 certificates are not affected as they do not rely on browser trust. Entrust-issued QWAC eIDAS certificates are affected by the browsers' decision, so browsers will not trust Entrust QWAC eIDAS certificates issued after the dates indicated as follows: 

Prior to becoming a QTSP, Entrust issued QWAC certificates via a reseller agreement with D-Trust. After Nov 11, 2024 we will resume reselling QWACs through this partnership. 

We recommend consuming all Entrust QWAC eIDAS inventory in your account on or before Nov 11, 2024 if possible, as switching your inventory to DTrust certificates will require you to go through validation again, and these certificates will not appear in your ECS portal by default. For tracking purposes, you will be provided a free Foreign Certificate Management license to import each D-Trust certificate into ECS as a foreign certificate. 

We also recommend that you purchase and consume any QWAC eIDAS licenses from Entrust that you may need in the next few months on or before Nov 11, 2024, so they may be easily issued with existing validations and tracked in your ECS portal. 

For QWAC eIDAS certificates to be issued on or after Nov 12, 2024, we will be happy to supply/resell certificates from D-Trust.

To view additional FAQs related to D-Trust QWAC eIDAS, click here.

Yes, we expect the integration with Sectigo to be similar to SSL.com but we will have more information as we get closer to release date.

We expect the technical integration to be complete in the next 60 days and will provide updates in the coming weeks. We are working with Sectigo on building the integration roadmap and will provide updates over the next few weeks.

The extensive root key portfolio of Sectigo is trusted by more than 99.9% of all web browsers and mobile devices. More information can be found here - https://www.sectigo.com/resource-library/sectigo-certificate-authority-root-keys.

Sectigo will be a CA partner in addition to SSL.com. We expect the technical integration to be complete in the next 60 days and will provide updates in the coming weeks. With changes in the Google Chrome browser coming Nov 12th and Mozilla on November 30th, customers who have public TLS certificates that are expiring in the next few months should accept the new subscriber agreements and issue certificates with SSL.com as the issuing CA.

Yes, once our integration with Sectigo is available, customers will be able to choose between SSL.com and Sectigo to issue public TLS certificates for their needs.

Yes, the integration is expected to behave similarly to the SSL.com integration where customers can issue certificates through either the UI using the Entrust certificate services portal or via API.

The CA/Browser Forum, one of the primary bodies that establishes industry standards for publicly trusted TLS certificates, requires that there is a Subscriber Agreement in place between a Certification Authority (CA) and any person who applies for a certificate. To review the applicable requirements, visit https://cabforum.org/. 

Your existing legal agreement only covers Entrust acting as the CA for all certificate types, but does not cover the possibility of certificates issued by SSL.com acting as the CA. The current agreement also mixes vendor (commercial) terms with CA (compliance) terms: As a result, this agreement will be neither fully accurate nor sufficient to comply with industry standards once the integration with SSL.com goes live. 

Customers will need to accept updates to their existing agreements, whether on standard or negotiated terms, to maintain compliance with industry standards and to accurately reflect the changes in our offering that enable them to take advantage of our solution with SSL.com.

Entrust’s Certificate Services offering covers all certificate types. Because the updates reflect changes at the operational, infrastructure, and application levels to enable compliance across all certificate types, they apply to all customers, even customers who are not currently buying TLS certificates or who are choosing not to use SSL.com as the root CA.

はい。All previously signed or accepted agreements, including custom negotiated agreements, must be updated to maintain compliance with industry standards and accurately reflect the changes in Entrust’s solution. However, since the legal updates have been narrowly targeted to merely what is required to meet compliance and accuracy objectives, most negotiated provisions in custom agreements are unaffected by the updates.

The legal updates and new Subscriber Agreement were developed following consultation and collaboration with our CA partner, auditors, and other external stakeholders to ensure compliance with industry requirements. As a result, the updates and Subscriber Agreement are not negotiable.

A letter detailing the changes is available directly within the ECS console. This document can be viewed and downloaded by an authorized administrator with the status of “superadmin” at any time, and can be shared with other stakeholders such as your legal and procurement teams for review. 

At a high level, the changes cover:

• Definitions & provisions relating to who performs registration and issuance, e.g. “CA” and “RA” to cover different entities doing verification and issuance, “Policy and Practices Documentation” to cover SSL.com’s CPS.
• Increased transparency/emphasis on industry compliance
• Separation of commercial (vendor/customer) terms and compliance (CA/Subscriber) terms. Certificate-type specific compliance terms are all removed from the existing agreement and moved to separate standalone Subscriber Agreements for each different certificate type.

There are two steps:

• 手順1： An authorized administrator with the status of “superadmin” will see a pop-up window upon logging into the ECS console, which has a link to a letter detailing all the changes, and an option to either “accept” or defer to “later”. If the superadmin chooses the “later” option, it is always possible to re-open the window and accept the changes by clicking the “Accept Legal Updates” link in the banner.
• 手順2： For each “client” or Subscriber organization in the ECS account, an authorized representative will receive an email prompting them to press an “accept” button to confirm acceptance of the Subscriber Agreements and the authorization of the ECS administrators to manage certificates on their behalf.

An authorized administrator with the status of “superadmin” will see a pop-up window upon logging into the ECS console, which has a link to a letter detailing all the changes. The letter found at this link can be downloaded and saved for your records, or shared with appropriate stakeholders if needed (e.g. a legal or procurement department). 

If the superadmin chooses the “later” option to dismiss, it is always possible to re-open the window and access the letter by clicking the “Accept Legal Updates” link in the banner.

The new standalone Subscriber Agreements are posted in Entrust’s Certificate Services Repository, under the “Agreements” heading.

Entrust has provided notice of changes in several ways: blog posts, creation of TLS Certificate Information Center, responses to questions directed to account and support teams, and most recently, by flagging the need for updates in a pop-up window in the Entrust Certificate Services portal, with a link to a document detailing the changes. 

We have also provided an “accept” button for indicating acceptance of the legal updates in the console, which will be deemed to meet any formalities that would be required in normal circumstances. 

Finally, an authorized representative of each Subscriber will be prompted to indicate acceptance of the new applicable Subscriber Agreements as part of the validation process.

Up to and including November 11, if the legal updates and Subscriber Agreements are not accepted using methods provided, most Certificate Services functions in the ECS portal will continue to be available, but it will not be possible to test or use the integration with SSL.com, or request or receive certificates issued by the SSL.com roots. 

From November 12 onward, if the legal updates and Subscriber Agreements are not accepted using methods provided, some Certificate Services functions in the ECS portal will continue to be available (viewing, generating reports), but it will not be possible to request issuance of any new public trust certificates from any CA.

Please direct your additional questions to [email protected]. Please include the name of the ECS account holder (and, if different, your organization name) in the subject line. If you have an Entrust account representative, you may wish to copy them on your email.