Advice Archives - Enom BlogEnom Blog |

Advice
Category

What Domain Resellers Should Know About ICANN’s Temporary Specification

September 18, 2018

Advice, Featured, GDPR, Industry Insight

Like

Views: 3338

On May 17, 2018, ICANN issued a “Temporary Specification for gTLD Registration Data,” the purpose of which is to provide ICANN’s contracted parties (registrars and registries) a path towards compliance with both ICANN contractual requirements and the GDPR. This involved the introduction of numerous registrar requirements, aimed at resolving points of conflict between ICANN’s Registrar Accreditation Agreement (RAA) and the GDPR. Here, we’ll highlight those requirements that are most relevant to our resellers, provide our stance on the Temporary Specification, and discuss some related upcoming features being added to the Enom platform.

What is a “Temporary Specification”?

To understand what makes the Temporary Specification unique, it’s important to understand how ICANN policy is typically developed. Normally, any policy that is binding on contracted parties (registrars and registries) is developed by a bottom-up, participatory process, taking input from all stakeholders and interested contributors, along a defined path called a “policy development process” (or “PDP”).

The output of a PDP is presented for public comment, refined, and then presented to ICANN’s Generic Names Supporting Organization (GNSO) Council for a vote. After a policy is approved by the GNSO Council, it is presented to the ICANN Board for final review and approval. Only after the ICANN Board approves the policy does it become binding on registrars and registries through a contractual provision in the above RAA.

The Temporary Specification was issued as an “emergency policy,” meaning it was adopted by a super-majority of the ICANN Board and bypassed the normal policy development process. Emergency policies must be re-approved by the ICANN Board every ninety (90) days and can exist for no more than one year. The idea is that one year provides sufficient time for the ICANN community to develop a permanent policy along the normal, bottom-up development path. The Temporary Specification was adopted on May 17, 2018 and will expire on May 16, 2019.

What does the Temporary Specification require of registrars?

The Temporary Specification includes a long list of items that registrars “must” or “shall” implement in order to be in compliance with their Registrar Accreditation Agreement, many of which are pulled directly from, or are heavily based on, the GDPR itself.

Here are some of the highlights, specifically those most relevant to resellers and registrants, with a note about any related changes we’re making within the Enom platform.

Registrars “must” or “shall”:

1. Redact personally identifying information from the public Whois output when (a) the registry or registrar is located in the EU; or (b) the registrant is located in the EU; or (c) the registry or registrar uses a data processor located in the EU for the registrant’s personal data. The redacted fields must say something like “REDACTED FOR PRIVACY.” (Temp. Spec. Appendix A Section 2)

Enom’s approach: As of May 25, 2018, Whois lookups results for all domains on our platform have returned “Data Protected” in place of any personally identifying information. However, we haven’t just limited this practice to the specific cases listed above; the redaction of personal data in the public Whois is our default for all domains on our platform.

2. Provide a method for third parties to contact the registrant through an anonymized email or web form. (Temp. Spec. Appendix A Section 2.5)

Enom’s approach: We plan to launch a Whois Contactability service that will allow the registrant to be contacted through a hosted web form. We’ll provide more details in the next few weeks.

3. Provide a means for the registrant to consent to have their contact details displayed in the public Whois, instead of the “Data Protected” notice mentioned above. (Temp. Spec. Section 7.2.1)

Enom’s approach: We’ll soon be launching a Whois Publicity service that allows registrants to opt into the display of their personal data in the public Whois, details of which will be released in the coming next weeks.

4. Implement Tiered Access to full Whois data, so that third-parties with a legitimate interest in access to a registrant’s personal data (such as law enforcement agencies) can review that data when necessary and appropriate. (Temp. Spec. Appendix A Section 4)

Enom’s approach: We’ve built a Tiered Access Directory — or “gated Whois” — that accomplishes this.

5. Provide mandatory disclosures to registrants detailing who has the registrant’s personal data, how it is processed, when and why a data transfer crosses international boundaries (if applicable), and the specific reasons that data is collected and transferred, among other subjects. (Temp. Spec. Section 7.1.)

Enom’s approach: This information is easily located on our Data Use Information Page

6. Comply with a new transfer policy, described in Appendix G to the Temporary Specification.

Enom’s approach: The domain transfer process changes we announced on April 30, 2018, anticipated the new transfer policy outlined in ICANN’s Temporary Specification. No further changes are needed.

7. Implement and observe Service Level Agreement (SLA) standards for Registration Data Access Protocol (RDAP), otherwise known as the successor to the WHOIS protocol. (Temp. Spec. Section 5.2)

Enom’s approach: These Service Level Agreement standards are not yet finalized, but Enom has played an active role in the RDAP pilot project. We’re in a position to easily implement any minor changes to our current system that the final agreement may call for, and to help shape the SLA to ensure it’s something that all registrars can meet in order to provide a reliable and fast RDAP service to users.

How and when are registrars expected to comply with the Temporary Specification?

ICANN has stated that it is “enforcing the requirements of the Temporary Specification as of 25 May 2018, as it does any other ICANN agreement or policy requirement.” However, aware that the requirements of the Temporary Specification came late, ICANN has provided registrars some leeway. While ICANN has already sent notices of non-compliance to many registrars, they appear to be withholding further action so long as the registrar demonstrates that they are working toward compliance. So we can expect that the various GDPR compliance processes in place now — which vary from registrar to registrar — may look quite different down the road. Virtually every registrar, including Tucows, is changing its implementation in important ways to comply with the Temporary Specification.

What changes is Enom implementing?

We have already implemented the majority of the mandatory requirements. As mentioned above, you can expect two new features in the coming months: Whois Contactability, which provides a means to contact the registrant through public Whois lookup results, and Whois Publicity, which allows registrants to opt into the public display of their contact data.

What is Enom’s stance on the Temporary Specification?

We believe industry-standard processes are important — they provide a level of consistency very much needed in this highly-connected registrant/registrar/registry network. Many of the Temporary Specification requirements will help move the industry forward towards a unified approach.

However, we view other aspects of the Temp. Spec. as problematic. The Temporary Specification aims to provide registries and registrars with a path to comply with both ICANN contractual requirements and the GDPR, but in a way that maintains “the existing Whois system to the greatest extent possible” and requires “robust collection of Registration Data.”

At Tucows, we believe that “maintaining the existing Whois system” and requiring “robust collection” of data violates the basic principles of GDPR. Put another way, we do not believe that the Temporary Specification is fully compliant with the GDPR. We have an ongoing disagreement with ICANN as to what the GDPR requires in three discrete areas, which is the subject of the ongoing ICANN v. EPAG litigation in Bonn, Germany.

Right now, we’re focused on implementing those Temporary Specification requirements that do not conflict with the GDPR (which is, of course, the vast majority). The GNSO has initiated an Expedited Policy Development Process (“EPDP”), which we are watching with great interest, as we work within the registrar community to advocate for the best outcome for registrars, resellers, and registrants. We’re advocating for policy which fully complies with the GDPR, keeps domain registration and management simple, and protects the interests of our resellers. As we’ve said before, in any instance where ICANN policy conflicts with the law, our priority is compliance with the latter.

Read More
Why Choose an EV SSL Certificate?

June 13, 2018

Advice, Featured, SSL

Like

Views: 2544

Identity theft and browser warnings are growing concerns among consumers. And while you may think enabling SSL on your website will allay these fears, failure to select the right TLS/SSL certificate can erode customer trust. To regain trust, site owners need an easy, reliable way to show customers that transactions are secure and that the site operator is who it says it is. But with the variety of TLS/SSL certs available – DV, OV, or EV – figuring out the best certificate for your business can be confusing. There are major differences in how domains are validated, and the following outline provides some key insights as to which certificate to select for your specific needs.

Domain Validation (DV) SSL Certificates

DV certificates prove ownership of the actual domain through a simple email validation process. DV certificates can be issued in minutes, show trust indicators in browsers (like the padlock icon), and enable HTTPS.

However, DV certificates do not vet the legitimacy of an organization and should not be used for e-commerce sites. Accordingly, DV certificates are best for internal sites, test servers, test domains, and for small to medium-sized businesses seeking cost-effective security.

Organization Validation (OV) SSL Certificates

OV certificates provide the same level of protection as DV certificates but go one step further. With an OV certificate, the Certificate Authority (CA) confirms the business is registered and legitimate, checking details such as business name, location, address, and incorporation or registration information, making these certificates more suitable for public-facing websites.

An OV certificate will also enhance a website’s reputation, providing customers greater assurance in conducting e-commerce transactions.

Extended Validation (EV) SSL Certificates

EV SSL certificates provide the highest level of trust, giving customers greater confidence that they are conducting business through trusted websites. EV SSL certificates are the industry standard for e-commerce websites. An EV SSL certificate triggers high-security web browsers to display an organization’s name in a green address bar and show the name of the Certificate Authority that issued it:

EV SSL certificates confirm site identity and validate the organization according to rigorous industry guidelines established by the CA/Browser Forum, including a strict vetting process using techniques that have been proven reliable in protecting the internet’s most valuable online businesses for more than ten years.

EV SSL certificates are a good choice for businesses, as these certificates can enhance credibility by showing suspecting consumers that sites are legitimately what they purport to be and that a business is serious about protecting the data of its customers.

Summed up, for the greatest level of website security, EV SSL certificates are the best choice.

Find Out More

This post was sponsored by Comodo CA, one of our trusted SSL providers. For more information about SSL, and a complete list of their products, visit www.ComodoCA.com.

Read More
A Guide to Choosing the Right SSL Certificate

May 24, 2018

Advice, Featured, SSL

Like

Views: 2757
A parent preparing a toddler for her first beach vacation and a seasoned kayaker preparing for Zambia’s Ghostrider rapid will not reach for the same life jacket. In the world of digital security, the purposes and specs of the various products are also highly relevant to the consumer, although the differences between them may not be so immediately clear. But in both cases, it’s important that the customer find the right fit. Whether you’re a business owner looking for the right SSL certificate for your own website or a domain provider looking to curate a solid SSL offering for your own customers, here’s what you should know about TLS/SSL certificates and what to look for when selecting a certificate provider.

What are TLS/SSL Certificates?

SSL is short for “Secure Sockets Layer,” and SSL certificates are used to secure communications between a website, host, or server and the end users that are connecting to it (or between two machines in a client-server relationship). An SSL certificate confirms the identity of the domain name (for example, ComodoCA.com) that is operating the website and enables encryption of all information between the server and the visitor to ensure the integrity of all the transmitted information.

Why are TLS/SSL Certificates So Important?

Identity theft and browser warnings are growing concerns among consumers. Failure to select the right TLS/SSL certificate for your website can erode customer trust and lower your rate of completed transactions, negatively impacting your bottom line.

How SSL Encryption Works

Encryption makes use of keys to lock and unlock your information, meaning you need the right key to “open,” or decode, the secured information.

Each SSL certificate comes with two keys:
- A public key, which is used to encrypt (scramble) the information.
- A private key, which is used to decrypt (unscramble) the information and restore it to its original format to make it readable.
Where Are SSL Certificates Used?

SSL certificates should be used in any instance where information needs to be transmitted securely. This includes:
- Communications between your website and your customers’ internet browsers.
- Internal communications on your corporate intranet.
- Email communications sent to and from your network (or private email address).
- Information between internal and external servers.
- Information sent and received from IoT and mobile devices.
Determining If a Site Has a Valid SSL Certificate

A website without an SSL certificate displays “http:// ” before the website address in the browser address bar. This moniker stands for “Hypertext Transfer Protocol,” the conventional way to transmit information over the Internet. Most internet users are aware that this indicates a website is not secure and historically have looked for https:// and a closed padlock symbol in their browser window to confirm that they are on the site of an authenticated organization:

However, it’s no longer sufficient for business websites to simply enable HTTPS and display the standard padlock symbol to their visitors. Online consumers are demanding assurance that the identity of the website they are visiting has been verified by authentication procedures that are proven to be highly trustworthy. And this assurance is provided in the form of an Extended Validation (EV) SSL certificate. EV certificates display a hard-to-miss green identifier in the URL bar and indicate to the visitor that the website was subjected to extensive scrutiny by the issuing Certificate Authority. The consumer can be confident that they are at a legitimate website, not a phishing website.

That’s not to say an EV certificate is necessary in every situation. But they can generate a higher level of consumer trust than other options, such Organization Validation (OV) certificates, or Domain Validation (DV) certificates, which undergo far less scrutiny.

Choosing between EV, OV, and DV Certificates

Domain Validation (DV) SSL Certificates

DVs are best for small- to medium-sized businesses seeking cost-effective security with no need to establish site visitor trust. Issuance of a DV certificate simply requires proof of ownership of the associated domain name, which is provided through a simple email validation process. These certificates can be issued in minutes, enable HTTPS, and display a clear indicator, such as the padlock symbol, in internet browsers.

However, DV certificates do not vet the legitimacy of the organization the website represents and should therefore not be used for e-commerce sites or sites that deal in sensitive information. They are, however, a great option for many internal sites, test servers, and test domains.

Organization Validation (OV) SSL Certificates

OV certificates provide the same level of protection as DV certificates but go one step further than simply requiring proof of domain ownership. With an OV certificate, the issuing Certificate Authority confirms the business associated with the domain name is registered and legitimate by checking details such as the business name, location, address, and incorporation or registration information. This makes the OV certificate a more suitable option for public-facing websites that represent companies or organizations.

Extended Validation (EV) SSL Certificates

EV certificates provide the highest level of trust by assuring consumers that they are conducting business through a trusted website. For this reason, these certificates have become the industry standard for e-commerce websites. EV SSL certificates trigger high-security web browsers to display a green address bar that includes the name of the company or organization that owns the domain. They also show the name of the issuing Certificate Authority:

Confirmation of the website’s identity and validation of the organization is carried out according to the rigorous industry guidelines established by the CA/Browser Forum and involves a strict vetting process that is shown to be effective over the course of more than ten years of real-world use.

EV SSL certificates are essential for large businesses or e-commerce sites as they can enhance credibility by showing discerning consumers that a prospective transaction is with a legitimate recipient and that the site is serious about protecting the data of its customers.

What to Look for When Choosing a Certificate Authority (CA)

As the world’s largest commercial Certificate Authority, Comodo CA is proactively monitoring for potential threats and attacks, working hand-in-hand with government agencies, browser providers, and our customers, to ensure it is keeping up with the ever-changing market.

When evaluating a CA, be sure that it:

1. Follows CA/B Forum Baseline Requirements.

This industry group consisting of Certificate Authorities and browser manufacturers developed standards that each CA must meet for its roots to remain trusted in browsers. These include:
- All information contained within the certificate must be validated to be true through a strict, clearly defined authentication process.
- Certificates must meet specific minimum levels of cryptographic strength to protect the integrity of the certificate and private key from evolving threats.
- Certificates must not exceed maximum specified durations.
- CAs must follow guidelines for CA security, certificate revocation mechanisms, audit requirements, liability, privacy and confidentiality, and delegation of authority.
2. Conducts Annual Audits – Both WebTrust and SOC 3

Annual audits are crucial to CA security, yet not every CA makes them a priority. At a minimum, your CA should meet these auditing standards.
- Maintain membership in the WebTrust program for CAs
  The WebTrust for Certification Authorities program was developed to increase consumer confidence in the Internet as a vehicle for conducting e-commerce and to increase consumer confidence in the application of PKI technology. Comodo CA, for example, undergoes an annual audit from Ernst & Young, which validates that:
- The Certification Authority (CA) discloses its SSL certificate practices and procedures and its commitment to provide SSL certificates in conformity with the applicable CA/Browser Forum Requirements.
- Subscriber information was properly collected, authenticated and verified.
- The integrity of keys and certificates is established and protected throughout their life cycles.
- Logical and physical access to CA systems and data is restricted to authorized individuals.
- The continuity of key and certificate management operations is maintained.
- CA systems development, maintenance and operations are properly authorized and performed to maintain CA systems integrity.
- The Certification Authority maintains effective controls to provide reasonable assurance that it meets the Network and Certificate System Security Requirements as set forth by the CA/Browser Forum.
- Submit to publish an annual Service Organization Control 3
  The SOC3 report is published to confirm that the security controls for this cloud service have been examined by an independent accountant. Again, as an example, Comodo CA undergoes an annual audit from Ernst and Young, to validate that Comodo CA has maintained effective controls over its system as it relates to four core principles: security availability, processing integrity and confidentiality.
To sum it up…

Trust is everything in the world of online business. Investment in technology to protect customers and earn their trust is a critical success factor for any company that does business online or hosts an e-commerce website. The effective implementation of TLS/SSL certificates is a proven tool to help establish customer trust. Check out Enom’s lineup of Comodo Certificates, or browse our full inventory of SSL products.

Looking to learn more?

This post was sponsored by Comodo CA, one of our trusted SSL providers. For more information about SSL, and a complete list of their products, visit www.ComodoCA.com.
Read More
GDPR Checklist for Enom Resellers

May 17, 2018

Advice, Announcement, Featured, GDPR, Uncategorized

Like

Views: 4471
Any time there’s a dramatic shift in our industry, we focus on minimizing the impact on our resellers and providing you as much information and assistance as possible. Admittedly, our GDPR communications work has proven fairly challenging, in part because we’ve simply never seen a shift quite as dramatic as that prompted by the GDPR. While we wanted to equip our resellers with specifics about our implementation plan and a concrete list of action-items right from the get-go, developing long-term solutions that both achieved GDPR compliance and established processes in which registries, registrars, and resellers can play their specific, essential roles required considerable collaborative efforts from players across our industry.

There’s still much work to be done, but today we’re happy to be able to offer a concrete list of GDPR action-items for Enom Resellers and helpful resources in the form of flowcharts, example landing pages, and FAQs. We’re even happier to say that the to-do list is a short one which will likely require minimal work on your end.

Having said that, we must remind you that legal counsel is an essential part of any comprehensive GDPR compliance strategy. This checklist is not legal advice, and ensuring its completion by no means guarantees your compliance with the GDPR. Speak with a lawyer who is familiar with your business and equipped to judge whether your internal practices achieve compliance.

Reseller Action-Items

Most of these items will necessitate adjustments on your end. You may determine that some do not require action on your part, but all are significant and important for our clients to understand.

1. Make Sure You’re Familiar with Our Newly Introduced Consent Management Process

Moving forward, Enom will reach out to end-users to request their consent to process certain pieces of personal information. This “Consent Management” flow involves the sending of a request email which contains a link to the registrant’s unique Data use consent settings page. This Data Use Consent Settings page serves as the registrant’s means to view their settings, manage their settings, and withdraw consent, should they choose to do so. It also contains a link to the Data use information page, which provides more information about how personal data is processed.

To the registrant, it’s a straightforward experience that makes clear Enom’s relationship with their Registration Service Provider (Reseller). We recommend you take a look at these samples, so you’re aware of what this process will involve for your customers:

Consent management sample flow – new registration
Consent management sample flow – consent choice change

Resellers will be able to view the GDPR consent status for each domain they have under management from the Domain Control Panel, within their Enom reseller account. If you’d like more information on why we require the end-user’s consent to process certain personal data, please check out our Consent blog post.

2. Understand How to Provide Your Customers Access to Their Data Consent Settings Page

According to the GDPR, “It shall be as easy to withdraw as to give consent.” With this in mind, we’ve provided our resellers two straightforward options to email a registrant the URL for the registrant’s Data Use Consent Settings page upon request:
- Option 1: Via the API using the SendConsentEmail command
  Resellers can use this command to integrate into their own end-user portal an option for users to request that the Data Use Consent Settings page URL be sent to the registrant email.
- Option 2: Via the soon-to-be-available “Send Consent Email” option in your Enom reseller account.
  Resellers can use this new button in the “Domain Control Panel” section of your Enom reseller account to send out the Data Use Consent Settings page URL to the registrant email listed for any domain in their account.
Please note: both of these options will be available as of Monday, May 28, 2018.

3. Ensure You’re Prepared for Our Updated Domain Transfer Process

Once the public Whois “goes dark” in the days leading up to May 25, 2018, Enom will begin using a new process for domain transfers. The end result will be a process that creates a more streamlined experience for domain owners, while continuing to be secure against domain theft. Moving forward, when an inbound registrar transfer is ordered, we will submit the transfer directly to the registry instead of waiting for the Form of Authorization to be completed.

You can check out our blog for the full details, but here’s a snapshot of the updated process:

4. Enom Is Moving to a Gated Whois System

For the full scoop, refer back to our Whois Changes blog post; for today, just keep in mind that after that go-live date, most public whois servers will cease the publication of personal data, and providers will start offering a “gated” or “tiered access” Whois system. Enom resellers don’t need to make any changes — your own clients’ data will continue to appear in your Enom reseller account, and we’ll take care of making sure the public Whois output is fully compliant with privacy regulations, so you’re good to go.

These changes are also summarized in this quick PDF.

5. Our Updated Reseller Agreement Now Requires That Resellers Process Data in a GDPR-Compliant Manner

Hopefully, you’re well on your way to compliance with the GDPR. Enom has updated our Reseller Agreement to include information about the consent management process and the addition of a Data Processing Addendum (DPA), with EU standard contractual clauses to allow data transfer from the EU to non-EU jurisdictions. We encourage you to familiarize yourself with all the recent GDPR-related changes we’ve made to our Reseller Agreement by taking a look the updated version.

6. We’ve Updated Our Agreement with Registrants

Our Domain Registration Agreement serves as the service contract between Enom and the domain owner (registrant). We don’t expect the GDPR-related updates to this agreement to be reseller-impacting, these changes primarily relate to the registrant’s consent management flow and the data retention and erasure policy. Keep in mind that all resellers need to display this updated agreement to customers as part of the domain registration process.

Reseller Resources

All important Enom resources relating to the GDPR can be found in our central GDPR knowledge base article, but for convenience, we’ve also listed them below. We hope the following resources help our reseller partners assist your clients with GDPR-related changes:

Overview

Our GDPR Webinar
Central GDPR knowledge base article and FAQ

Specific Platform & Process Changes

Consent Management

Consent management sample flow – consent choice change
Consent management sample flow – new registration
Consent management FAQ

End-user consent request emails – The means by which we send the Data Use Consent Settings page URL (see below) to the registrant.
Data use consent settings pages – The location from which a registrant can set, view, and update their consent preferences or revoke consent.

Domain Transfers

Transfer process changes infographic – a before and after GDPR comparison

Whois Changes

Whois Changes Overview PDF
Whois Changes FAQ

API Changes

A new SendConsentEmail command has been introduced.

Contract Changes

Updated Reseller Agreement
Updated Domain Registration Agreement
Data Processing Addendum

And there you have it. We appreciate that for those resellers affected by the GDPR, achieving compliance has involved a great deal of internal work, in addition to that required to accommodate the changes Enom is making to our platform. And while we’ve made every effort to keep this Reseller Checklist short and easy-to-implement, we know, as members of that same complex registry-registrar-reseller channel in which you operate, that small changes made by one player can have a big impact on others. We view our GDPR implementation work as essential to ensuring that the Enom platform evolves to meet the long-term needs of our resellers and the demands of a highly interconnected internet ecosystem. Greater control over one’s personal data is a good thing, and we’re happy to be able to extend to all users on our platform the rights and protections outlined in the GDPR.
Read More
Google and Symantec resolve Chrome browser trust issues

September 21, 2017

Advice, Announcement, SSL, Uncategorized

Like

Views: 3156
Update: February 8, 2018

This blog post is a follow-up to the information we published a few months ago regarding the Google-Symantec conundrum.

Symantec and Google have agreed on a plan that requires Symantec to migrate certificate validation to a third party. In exchange, Google would ensure that the Chrome browser continues to trust Symantec certificates validated by this third party. Shortly thereafter, DigiCert announced its plan to acquire Symantec’s Website Security Business by the end of 2017. With this acquisition, Digicert would effectively take over the validation for all of Symantec’s certificate brands by December 1st, 2017, which would satisfy the asks of the browser community.

In light of these changes, Google has announced an updated plan as to how Chrome would deal with certificates issued by DigiCert’s validation infrastructure. This plan has received some coverage in the media, stating that Google would no longer trust any Symantec certificate brand by 2018. This information is incomplete, incorrect and it has created some confusion and uncertainty. Here’s what you need to know:
- From December 1, 2017, all Symantec certificate brands (Symantec, GeoTrust, Thawte and RapidSSL) will be issued from DigiCert’s validation platform and Chrome will trust those certificates. For clarity: the Symantec certificate brands will continue to exist after December 2017, they will only be issued from a different, upgraded validation platform. Google will continue to trust all Symantec certificates that have been issued from this new platform after December 1st, 2017.
What does this mean if you have a certificate from any of the Symantec brands?

Certificates issued prior to June 1, 2016

If you have a certificate that has been issued prior to June 1, 2016, the Chrome browser will no longer trust this certificate after March 15, 2018. In order to retain trust by the Chrome browser, you need to replace this certificate. Some important dates to keep in mind:
- If the certificate expires prior to March 15, 2018, you need to do nothing. The certificate will continue to be trusted by Chrome until it expires.
- If the certificate expires after March 15, 2018, but before September 13, 2018, you can re-issue this certificate any time before March 15, 2018.
- If the certificate expires after September 13, 2018, you will need to re-issue the certificate before March 15, 2018.
Certificates issued after June 1, 2016

If you have an existing certificate that has been issued after June 1, 2016, the Chrome browser will no longer trust this certificate after September 13, 2018. Some important dates to keep in mind:
- If the certificate expires prior to September 13, 2018, you need to do nothing. The certificate will continue to be trusted by Chrome until it expires.
- If the certificate expires after September 13, 2018, you will need to re-issue the certificate before September 13, 2018.
- If you have purchased a certificate after December 1, 2017, the Chrome browser will trust this certificate. You will not be required to re-issue.
It is safe to continue to use Symantec certificates, but you will need to keep some of these key dates in mind to avoid any disruption. If your certificate has been purchased at any time with a 1-year validity period, it is very likely that no action is required on your part.

We would like to remind you that re-issues for the Symantec family of certificates (Symantec, Thawte, GeoTrust, RapidSSL) can be done free of charge.
Read More

Support

Report Abuse
Help Center
Contact Us

Resources

WHOIS Lookup
Maintenance Alerts
Developers

Products & Services

Domain Name Search
Premium Domains
Web Hosting
SSL Certificates
Website Builder
Basic Email
Bulk Tools

© 2019 Enom Blog |