Important: information relating to the situation in Russia, Belarus and Ukraine.
In response to the evolving geopolitical situation in Ukraine, many SSL certification authorities are suspending the issuance and reissuance of all types of certificates affiliated with Russia and Belarus.
This includes suspending issuance and reissuance of certificates to TLDs related to Russia and Belarus, including .ru, .su, .by, .рф, as well as to organizations with addresses in Russia or Belarus. We will keep you informed as soon as the situation returns to normal.
Also, we observe a significant increase in phishing attacks. We advise you to be extra vigilant, especially when it comes to new domain name registrations using your trademarks.
Nameshield remains of course at your disposal to accompany and advise you in this complex context.
SSL certificates ensure the encryption and integrity of data exchanged between a browser and a web server. There are different levels of certificates, Extended Validation (EV), Organizational Validation (OV) and Domain Validation (DV), which vary depending on the degree of authentication. The Extended Validation type SSL certificate provides the highest level of SSL authentication. It is obtained through a comprehensive and globally standardized identity verification process established by the CA / Browser Forum.
Regardless of the selected SSL level, encryption and data integrity can be guaranteed by Extended Validation (EV), Organizational Validation (OV) and Domain Validation (DV), but they do vary depending on the degree of authentication. The Extended Validation type SSL certificate provides the highest level of SSL security. It is obtained through a comprehensive, globally standardized identity verification process ratified by the CA / Browser Forum.
The EV SSL certificate enables HTTPS security and the now gray padlock in the browser’s address bar, just like DV and OV certificates. The additional cost and time spent on verification makes it more difficult to obtain EV level certificates for phishing sites. Therefore internet users can use this certificate as a mark of trust and feel more secure when communicating and making purchases.
On June 12, 2007, the CA/Browser Forum officially ratified the first version of the Extended Validation SSL Guidelines, which took effect immediately. The formal approval successfully brought to a close more than two years of effort and provided the infrastructure for trusted website identity on the Internet.
Most major browsers created visual indicators for pages loaded over HTTPS and secured by an EV certificate soon after the standard was created: they displayed the validated identity, which is a combination of organization name and legal status, in the URL bar. Safari for iOS, Windows Phone, Firefox for Android, Chrome for Android and iOS, also added these indicators.
In May 2018, Google announced plans to redesign Google Chrome user interfaces and remove emphasis on EV certificates. Chrome 77, released in 2019, removed the EV certificate indication from omnibox. Firefox 70 followed and removed the distinction in the omnibox or URL bar : EV and DV certificates are displayed similarly with just a padlock icon, but the information on the EV certificate status is still accessible in the more detailed view that opens after clicking on the padlock icon.
An EV certificate displayed in Firefox
The increasing use of mobile devices and the removal of the visual indicator EV by browsers has significantly reduced the interest of some entities in using this level of security, but the EV is still very important in our daily lives.
Today, phishing websites are unfortunately still a major threat to legitimate websites and online services. These cybercriminals use DV certificates, usually obtained from a free SSL service that does not conduct adequate phishing checks, to make their sites appear more trustworthy. They are able to easily deceive unsuspecting victims and trick them into disclosing financial or personal information.
A very strong increase in phishing has been observed since March 2020, with the beginning of lockdown and remote working for many people: the volume of phishing sites increased by 47% for the first quarter of 2020, and 82.7% of attacks phishers used DV SSL certificates. This problem is only growing and increases the need to verify identities online.
An SSL (Secure Socket Layer) or TLS (Transport Layer Security) certificateis a digital certificate that authenticates a server (most often a web server) and encrypts the data exchanged with it. The data is thus exchanged in confidence between two actors whose identity is known. The data exchanged cannot be spied on or altered by a third party: confidentiality and integrity.
Download this document “5 minutes to understand: SSL / TLS certificates” on Nameshield’s website.
Every day, new cyberattacks are threatening companies’ defense systems, and further weaken relations with web users, particularly on e-commerce websites. Identity theft and data theft have become common.
The risks of a malicious person intercepting the data transmitted by the web user on your website and more generally all the information transmitted between the browser and the server of your website ,are increasing significantly.
Find in this “5 minutes to understand” document, available for download on the Nameshield’s website, the solution to implement against these risks.
On November 17, Mozilla released the version 83 of the Firefox browser, promising improved performance in terms of page loading and browsing responsiveness, as well as a significant reduction in the memory used.
But above all, Mozilla introduces a brand-new security feature to the small world of browsers, an “HTTPS-Only Mode” option to limit browsing to secure HTTPS* connections only.
Image source: Mozilla Security Blog
Mozilla is pushing it further regarding the desire of major browsers to pass HTTPS as the default browsing protocol instead of the unencrypted and therefore fully visible HTTP.
Which display during browsing?
When the option is activated, any web page that does not have an SSL/TLS certificate (allowing the HTTPS and the security padlock icon to be displayed in the browser address bar) will be preceded by the warning message below, which is restrictive for web users.
Image source: Mozilla Security Blog
What to expect in the coming years?
If the option is not yet activated by default, Mozilla’s management indicates that it expects HTTPS to become the standard for browsing the Web. Driven by the successive evolutions of browsers and their increasingly obvious displays of a lack of security, more and more websites are migrating to HTTPS by default. It is likely that browsers makers will decide to completely depreciate HTTP connections in the near future, making HTTPS the default protocol for Web browsing.
How can companies be prepared?
Most companies have already begun the migration of their website(s) to the HTTPS by default. It is important to maintain an exhaustive inventory of the company’s websites and pages and to control the associated SSL-TLS certificates, of which the main risks are renewal errors and poor implementation. It is essential to set up clear procedures and to associate to them a good communication towards the interlocutors in charge of the websites. Actors such as Nameshield are there to accompany you in this process. They have the expertise and tools necessary to simplify these tasks and reduce the risk of error.
TLS/SSL certificates are used to authenticate servers (mostly Web) and encrypt traffic between websites and users. Thus, they ensure the integrity of the data exchanged and prevent data spying. The digitalization of the company and the world in general, as well as the browsers’ desire to impose HTTPS:// by default, have multiplied exponentially the need for certificates.
To meet these growing needs, the wildcard certificate (*.domainname.com) is increasingly being considered by companies. While it has some advantages, particularly in terms of costs reduction and flexibility, it is important to be aware of the disadvantages in order to choose the right certificate wisely. A brief overview of the wildcard certificate.
What is a wildcard certificate?
A standard TLS certificate secures an explicit host name (CN for Common Name or FQDN for Fully Qualified Domain Name) defined in its metadata. For example, Google holds a certificate for mail.google.com.
This certificate is only valid for: https://mail.google.com/
It cannot be used for: https://google.com/ – https://images.google.com/ – https://my.mail.google.com/
In other words, the host name must be an exact match. If you try to use this certificate on https://my.mail.google.com/ you will get a certificate error from your browser.
A TLS wildcard certificate is different. As its name implies, it uses a generic match rather than an exact match. This generic match is represented by “*” in the CN and covers all subdomains of the same level. Example with the *.google.com certificate.
This certificate is valid for: https://mail.google.com/ AND https://images.google.com/ as well as all possible subdomains of google.com.
It cannot be used for: https://google.com/ (without subdomain) or https://my.mail.google.com/ (the subdomain level is not the same).
The practical side of the wildcard certificate?
In some situations, the wildcard certificate is very useful. A host that proposes websites for different clients, hosted on a shared server, and accessible through different subdomains… client1.mysite.com, client2.mysite.com, client3… It is less practical, technically more complicated and de facto more expensive to ask for a new certificate for each client that registers; the simplest option is a wildcard certificate for *.mysite.com, a unique certificate that will cover all clients. The case is identical for a company that wishes to access its websites through FQDN derived from the same domain and hosted on the same web server, *.mycompany.com. So far, everything is okay.
But then, what is the risk?
In the cases above, all sites are hosted on a single server. In large companies, or for major websites, hosting is often more complex and on different servers. Let’s take again our example of Google with images.google.com and mail.google.com, these two applications are linked to different services of the company, hosted on different servers and managed by different technical teams. This kind of organization is extremely frequent in the company. And this is where the security of wildcard certificates stops.
The problem with wildcard certificates, and to a lesser extent with certificates containing multiple entries (the famous SAN, Subject Alternative Names), comes from the fact that they are deployed on several servers. Indeed, to ensure the security of a TLS/SSL certificate, it is absolutely necessary to protect the private key associated with the certificate. Ideally, it should be stored in a vault or in a HSM. When a certificate is installed on several servers, the associated private keys circulate, increasing the exposure to the risk of compromise.
Case of a compromised certificate
In case of a compromised certificate, or an error on the certificate (renewal problem), it is recommended to intervene quickly to limit the damage caused. Application for a new certificate (or renewal), installation of the new certificate and, if necessary, revocation of the compromised certificate.
In our example of creating websites on a single server, this is not a problem. We have only one server, it has been compromised, the stolen/expired/compromised certificate only works for this one server; we have limited the damage as much as possible.
In a “several servers” scenario, if the certificate of only one of the servers is affected, it becomes compromised on all of the servers, which will have consequences on all of them and require a much wider intervention to repair the damage, most often in an emergency, and assuming that all of the affected servers are identified. Indeed, it is not uncommon for the certificate to circulate within several teams and to be installed without being listed on a certain number of servers. The impact can be important.
Taking our example of Google. Let’s imagine that only the images.google.com server has been hacked and that mail.google.com has not been affected. The certificate for images.google.com being a wildcard certificate for *.google.com which is common to mail.google.com, the cyber-attacker having compromised the images service has by rebound usurped the identity of the mail.google.com server and can intercept the traffic of the mail service while this server has never been hacked!
Good practice: one TLS/SSL certificate per server…
In our last example, if we were to have two certificates instead of one, with each server having only access to its own certificate, we would have limited the risk. In an ideal world, each certificate should only be used for one server (or a homogeneous cluster of servers). Different services on different servers should have their own certificates, generally not wildcard certificates.
A wildcard can be used if you have a lot of host names, of subdomain type, pointing to the same service on the same server. Be careful however that this generic certificate does not also cover host names pointing to other servers, in which case each service should have its own certificates.
Lastly, if you have a few host names pointing to single servers and everything else on a single service, then it is better to disassociate the host names. For example, you may have a certificate for login.mysite.com and a (wildcard) certificate for *.clients.mysite.com. On this last example, if the number of clients is fixed or clearly defined, it is better to go for a certificate with a precise SAN list, to better control secure host names and not allow the httpS:// on uncontrolled host names.
Conclusion
The option of a wildcard certificate exists and it is a good thing for some very specific needs. But in practice, there should never be a need to install a wildcard certificate, nor should the same certificate be installed on different servers not built in cluster.
Let’s Encrypt was recently the subject of discussions in the small world of TLS certificates, by suddenly revoking 3 048 289 certificates which should not have been issued. A bug in its validation software prevented CAA registrations controls, and the certificates in question should not have been initially issued. These significant disruptions resulted from this mass revocation, but it is difficult to complain about a free service.
I am often asked what I think of Let’s Encrypt, and I always have this same answer: Let’s Encrypt has done a lot to encrypt the web, but is undermining the security of the web. Encryption allows to ensure confidentiality (no one can spy on) and integrity (no one can modify) of exchanges. But encryption alone is not enough if I do not have any guarantee of the identity of the one I am exchanging with (legitimate or fraudulent?)… And that is the whole problem.
In 2015, the Let’s Encrypt initiative supported by leading players of the Internet (EFF, Mozilla, Cisco, Akamaï…) was created with the purpose of massively and freely spreading SSL certificates to the whole world. More than five years later, the organization secures 190 million websites and has just announced that it has issued a billion certificates. The milestone was reached on February 27, 2020. This is undoubtedly a great performance.
96% of the web encrypted in January 2020
In 2015, less than half of the web traffic was encrypted, to reach 96% in January 2020. Of course, Let’s Encrypt is not the only player responsible for this rise. Edward Snowden launched the first alert, Google has largely stepped into the breach, between referencing policy and changes in web security indicators. But by providing to all, free certificates based on a largely automated system, Let’s Encrypt has democratized encryption… and put the concept of identity into oblivion.
No identity, no security
Let’s Encrypt’s credo is simplicity, to “simplify to the extreme HTTPS deployment and put an end to its horribly complex bureaucracy” (says EFF in the launch campaign). The horribly complex bureaucracy has however a meaning: high authentication, which guarantees the identity of the certificate’s holder. Maybe not the absolute guarantee of legitimacy, not a guarantee of content either, but the guarantee of a registered company, legitimately owner of the concerned domain name and with a certificate validated according to a drastic procedure.
Let’s encrypt merely verifies the domain name’s control (DV, Domain Validation). One only has to click on a link in an email or to fill in a TXT record on the domain name’s DNS zone. Yet domain names registration in most TLDs is purely declarative. It is quite easy to register a domain name, to request a certificate from Let’s Encrypt and to publish a website in HTTPS://.
The results?
In five years, all phishing and fraudulent websites have switched to HTTPS://. Since 2016, Vincent Lynch alerted on this problem, 15 270 certificates with the term “Paypal” had been issued by Let’s Encrypt, 14 766 of these certificates were fraudulent.
The market has been brought down in terms of authentication level. Let’s Encrypt is far from being the only one responsible, Google and Mozilla, with their 70% of market shares, have largely supported the initiative, the big Cloud hosting providers followed, as well as the Certification Authorities, challenged on the prices. Today we have a secure web with 77% (November 2019) of certificates whose proprietary’s legitimacy is not verified.
High authentication changes the game
The web has become encrypted by default. Does that make it more secure? Nothing is certain. The web user educated for twenty years to check the presence of the padlock in the address bar, trusts a web where all the fraudulent websites display the security padlock. Today, Internet is confidential but that does not make it safe.
It is urgent to return to high authentication. High authentication ensures a set of compulsory, drastic and controlled steps in order to obtain certificates. The procedures are enacted by CA/B Forum, regularly strengthened, and followed by audit from Certification Authorities.
23% of the certificates are still issued on the basis of high authentication, mostly in the corporate world, where CISO are pushing to preserve it. We all have to rely on them and support initiatives supporting OV (Organization Validation) and EV (Extended Validation) certificates, especially EV to guarantee the identity of the websites visited by web users. While identity on the Internet seems to have been somewhat forgotten for some time in favor of confidentiality, it is likely to come back to the spotlight again soon, driven in particular by web users and the need of personal data protection.
Apple announced this week that the maximum
lifetime of SSL / TLS certificates on its devices and Safari browser would
be limited to 398 days (1 year, and 1 month to cover the renewal period). The
change, announced by Apple at the CA / Browser Forum meeting in Bratislava,
Slovakia, will take effect for certificates
issued after August 31, 2020.
Apple’s announcement follows a failure of the CA / B Forum’s vote on one-year certificates (Bulletin SC22), which was held in August 2019, and reflects a continuing trend to shorten lifespan certificates. Following this vote, Google had also expressed its intention to reduce certificate lifetime outside the framework of the CA / B forum if they do not position themselves quickly. This announcement is a bit of a surprise, we would rather have thought that Google or Mozilla would take the first step.
What are the consequences for companies and their SSL / TLS certificates?
Is shorter validity a good thing?
The shorter the validity period of a
certificate, the more secure the certificate. By requiring replacement of
certificates over a shorter period of time, security updates are made to
certificates, they deploy faster. The shorter private key lifetime of a
certificate is also a strong recommendation from online security players to
limit the potential duration of fraud following a compromise.
From a security perspective, everyone agrees
that reducing the life of certificates is a good thing. The problem lies on the
operational side with the consequences of this reduction being: more frequent
intervention on certificates, therefore greater complexity in keeping an up to
date inventory and the need for optimal organization with partners for
certificate issuance.
Should Apple’s announcement be taken into account?
Safari is one of the two main web browsers, with 17.7% in January 2020, behind Google Chrome (58.2%) and ahead of Microsoft Internet Explorer and Edge (7.1%). It is difficult to ignore the announcement as it will affect 1/5 of Internet users, what is more is that if Google does follow, it is better to anticipate and prepare. Nameshield’s has already adopted this stance.
Things to keep in mind
Certificates issued
before September 1, 2020 are not affected by this change. They will remain valid for the entire
two-year period. All certificates issued
on or after September 1 must be renewed each year to be considered reliable
by Safari.
We must therefore prepare to move towards
having certificates with a maximum duration of one year compared to the current
two years. Being able to rely on a partner and effective tools is more
essential than ever.
Towards the end of the correlation between authentication and technical
certificate management
What seems to be taking shape within the CA / B
Forum is the idea of allowing an authentication duration identical to that
which we know today (two years) while forcing the certificates to be replaced
several times during this same period.
The main Certification Authorities, the bodies
that issue certificates, anticipate these changes and are working on several
automation systems to manage certificate life cycle. They would thus limit the
need to go through a potentially cumbersome re-authentication procedure with
each replacement. Companies could replace their certificates as many times as
they want during this period. This would make it possible to anticipate possible
further reductions in the maximum lifetime of certificates.
The trend is also towards the installation of
automation tools for the maintenance of a precise inventory of certificates on
the one hand and technical reinstallation on the other. Nameshield is closely
monitoring these various developments and will allow you to continue working
with confidence.
Our team is also at your disposal to anticipate these changes and answer any questions you may have.
Following the launch of .APP, .PAGE, and .DEV
among others, Google (Charleston Road Registry), launches the new extension .NEW
in Sunrise period as of October 15, 2019.
Conditions for registration of a .NEW
In order to use a .NEW domain name, you will need to acquire an SSL certificate and deploy HTTPS. For reminder, the .NEW extension is included on the HSTS pre-upload list, requiring HTTPS protocol on all .NEW domain names (more details in the article “Google makes HTTPS encryption mandatory for its 45 new TLDs : .dev / .app / .how…”).
All
domains on .NEW must resolve to action generation or online creation
flows. Once resolved, the web user should be able to ‘create’ something without
any further navigation. For example, docs.new proposes a dedicated page proposing
the direct use of Google online word-processing software allowing a new
document creation page.
Any
.NEW
domain will need to be live within 100 days of registration.
If these conditions are not respected, the
registry will consider the registration as non-compliant with the registration
policy. In this case, the name will be placed on hold. The registrant will then
be notified to correct and apply these conditions, if no action is taken, the
domain will be blocked then deleted.
Launch calendar
Sunrise period: from October 15, 2019 to January 14,2020
LRP (Limited Registration Period): from January 14
to July 14, 2020
General availability:
from July 21, 2020
For more information on the conditions for registration of your .NEW, don’t hesitate to contact us.
The industry actors plan to reduce the lifetime of SSL/TLS certificates, allowing the HTTPS display in browsers, to 13 months, i.e. almost half of the present lifetime of 27 months, in order to improve security.
Google through the CA/Browser Forum has indeed
proposed this modification, approved by Apple and a Certification Authority, making
it eligible to vote. During the next CA/B Forum meetings, if the vote is
accepted, the modification of the requirements will come into effect in March 2020. Any certificate issued
after the entry into force date will have to respect the requirements of the
shortened validity period.
The aim for this reduction is to complicate
things for cyber attackers by reducing the duration of the use of the potentially
stolen certificates. It could also force companies to use the most recent and
the most secured available encrypting algorithms.
If the vote fails, it’s not to be excluded that
browsers supporting this requirement, unilaterally implement it in their root
program, thus forcing the change to the Certification Authorities. It’s likely
that this could be the case, this change follows Google’s precedent initiative that
aimed to reduce the lifespan from three years to two years in 2018, period during
which Google already wished to reduce it to 13 months or even less.
Who is impacted?
The changes proposed by Google would have an impact on all the users of TLS certificates of public trust, regardless of the Certification Authority that issued the certificate. If the vote passes, all certificates issued or reissued after March 2020 will have a maximum validity of 13 months. The companies using certificates with a validity period superior to 13 months will be encouraged to reconsider their systems and evaluate the impact of the proposed modifications on their implementation and their use.
The TLS certificates issued before March 2020 with a validity period superior to 13 months will stay operational. The public non-TLS certificate, for the code signing, the TLS private code and clients’ certificates, etc. are not concerned. It will not be necessary to revoke an existing certificate following the implementation of the new standard. The reduction will have to be applied during the renewal.
What do the market players think about this?
It would be a global change for the industry with
impacts on all the Certification Authorities. They view this proposition in a negative light. We
can see an economic interest above all, but not solely…
The main argument is that the market is not
ready in terms of automation system of orders and certificates implementations.
Indeed, there would be more human interventions with the risks associated with poor
handling, or simply a higher risk of forgetting a certificate renewal.
For Certification Authorities, reducing the
certificates’ lifespan to such a short term mainly presents an increase of the
human costs related to the certificate portfolio management. If they are not
fundamentally against this decision, they would particularly like more time to
study what users and companies think.
The position of browsers makers
Be it Google or Mozilla, the spearheads of the
native HTTPS massive adoption for all websites and the supporters of the
Let’sEncrypt initiative, what is important is the encrypting of all web
traffic. A reduction of the certificates lifespan reduces the risk of
certificates theft on a long period and encourages the massive adoption of
automated management systems. For these two actors, an ideal world would have
certificate of maximum 3 months. If they are attentive to the market as to not
impose their views too quickly, it is more than likely that in the long term
the certificates’ lifespan will continue to decrease.
Nameshield’s opinion
The market continues its evolution towards shorter
and shorter certificates’ validity, as a continual decrease of the
authentication levels and consequently a need for management automated
solutions that will increase. We will align on these requirements and advise
our customers to prepare themselves for this reduction which will, without a
doubt, arrive. Our Certification Authorities partners will also follow this
evolution and will allow to provide all systems of required permanent inventory
and automation.
To be heard
The CA/Browser Forum accepts comments of external participants and all discussions are public. You can directly enter your comments to the Forum distribution list: https://cabforum.org/working-groups/ (at the bottom of the page). Nameshield is in contact with CA/Browser Forum participants and will inform you of the future decisions.
Nameshield uses cookies
Nameshield wishes to use cookies to ensure the proper functioning of the site and, with our partners, to measure its audience🍪.
Nameshield wishes to use cookies to ensure the proper performance of the website and, with our partners, to monitor its audience. More information in our Cookie Policy 🍪.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-advertisement
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
CookieLawInfoConsent
1 year
Records the default button state of the corresponding category & the status of CCPA. It works only in coordination with the primary cookie.
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
_ga
2 years
The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.
_gat_gtag_UA_25904574_14
1 minute
Set by Google to distinguish users.
_gid
1 day
Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
NID
6 months
NID cookie, set by Google, is used for advertising purposes; to limit the number of times the user sees an ad, to mute unwanted ads, and to measure the effectiveness of ads.
![[New gTLD] Launch of .NEW by Google](https://blog.nameshield.com/wp-content/uploads/2019/12/Sortie-du-.new-Google-1200x743.jpg)
![[New gTLD] Launch of .NEW by Google](https://blog.nameshield.com/wp-content/uploads/2019/12/Sortie-du-.new-Google.jpg)
