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.
According to a joint report by iYouPort, the University of Maryland, and the Great Firewall Report, TLS connections using the preliminary encrypted SNI extension (ESNI) are being blocked in China. A new step towards censorship and a desire to be able to track Internet users.
What is SNI (Server Name Indication)?
When an Internet user consults a website in HTTPS://, it means that the site is secured by an SSL/TLS certificate. The consultation of the website begins with the establishment of the secure connection, the “handshake”. This handshake consists of several steps and aims to check the certificate and establish the encryption level of the connection. The first message of a TLS handshake is called “client hello”. With this message, the client asks to see the TLS certificate of the web server. The server must attach the certificate to its response.
Presenting the right certificate poses no problem in the case of dedicated hosting: one IP address, one certificate, possibly containing several SAN (Subject Alternative Name) belonging to the same organization. The problem occurs with shared hosting where the host has the same IP address but wants to install several different certificates, otherwise he will have to be the owner of the certificate by adding SAN for all his customers. Not a recommended practice.
The SNI responds to this specific request from hosting providers and their shared hosting. With the SNI protocol, the client indicates the hostname with which it tries to start a TLS negotiation. This allows the server to present several certificates for the same IP address (but different host names). The SNI could be compared to the apartment number of a postal address: a building has several apartments, so each apartment must be identified by a different number. Similarly, if the server is indicated by the IP address, client devices must include the SNI in their first message to the server to indicate which website (which apartment) they are trying to reach.
What is ESNI (Encrypted Server Name Indication)?
The establishment of an encrypted TLS connection begins at the end of the handshake. Problem, the SNI is not encrypted because the “client hello” message is sent at the beginning of the TLS handshake. A hacker can reconstruct the path of an Internet user by reading the SNI part of the handshake, even if he is not able to decrypt subsequent communications. The main interest for the pirate is to be able to trick the Internet user by creating a phishing site. On the other hand, the major web players like confidentiality, and wish to preserve the confidentiality of users’ browsing data. The ESNI was therefore born.
The ESNI (Encrypted server name indication) encrypts the Server Name Indication (SNI) part in the TLS handshake. The ESNI extension is accessible through the latest version of the TLS protocol, 1.3, which is being increasingly adopted today. The principle is to retrieve an encryption key through DNS (which can be secured through DNS via HTTPS). Still at the draft stage, some large hosting providers are already implementing it.
And China in all this?
In their report, iYouPort, the University of Maryland and the Great Firewall Report, detail how China views handshake encryption in a very negative light. This effectively prevents the Chinese government’s Great Firewall monitoring tool from seeing what Internet users are doing online. China has therefore decided to simply block HTTPS connections established through the latest version of the TLS protocol (1.3) associated with ESNI. In addition, the IP addresses involved in the connection are temporarily blocked for two to three minutes.
Some circumventing methods exist… but until when?
All three organizations appear to have found circumventing methods to apply on either the client side (in applications and software) or the server side to evade the current blocking implemented by the Great Firewall. ” Unfortunately, these specific strategies may not be a long-term solution: as the cat and mouse game progresses, the Great Firewall will likely continue to improve its censorship capabilities“, write the three organizations in their report.
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.
Browsers and Certification Authorities, the battle continues.
Image source : TheDigitalArtist via Pixabay
2019 was a busy year, with growing differences of opinion between browsers makers and Certification Authorities, an explosion in the number of phishing sites encrypted in HTTPS and significant progress on the depreciation of TLS v1.0.
Discussions on extended validation, more generally the visual display of certificates in browsers, and the reduction of the duration of certificates have taken a prominent place. None of these discussions are over, no consensus seems to be emerging, 2020 is looking like a busy year. Time to look ahead…
Will the fate of Extended Validation be determined?
2019 saw the main browsers stop displaying the famous green address bar with the padlock and the name of the company, in favor of a classic and unique display, no longer taking into account the authentication level of the certificates:
However, discussions are still ongoing at the CA/B forum level, as well as within the CA Security Council. Both of these certificates regulatory bodies will be looking in 2020 for an intuitive way to display identity information of websites.
Historically approved by everyone, including the financial industry and websites with transactions, EV (the acronym for Extended Validation) was Google’s target in 2019. Other browsers, under the influence of Google, between Mozilla financed by Google and Microsoft and Opera based on Chromium open source, have followed in this direction. Only Apple continues to display EV.
For browsers, the question is whether or not TLS is the best way to present the authentication information of websites. It seems that it is not. Google assumes that it is not up to Certification Authorities to decide the legitimate content of a website and wants the use of certificates for encryption purposes only.
Of course, the Certification Authorities see things differently. One can certainly see a purely mercantile reaction, EV certificates are much more expensive. One can also wonder about the purpose of authentication beyond encryption. The answer seems to lie in the staggering statistics of phishing websites encrypted with HTTPS. Browsers have for the moment imposed an encrypted web indeed… but no longer authenticated!
2020 will therefore be the year of proposals from Certification Authorities: providing better authentication, including identification of legal entities, following the path of PSD2 in Europe… One thing is certain, identity has never been so important on the Internet and it is up to all interested parties to find a solution, including browsers to find a way to display strong authentication of websites. To be continued…
Certificates with a shorter duration: towards one-year certificates
825 days, or 27 months, or 2 years, the maximum duration currently allowed for SSL Certificates. However, since 2017 and a first attempt within the CA/B forum, the industry is moving towards a reduction of this duration to 13 months (1 additional month to cover the renewal period).
Google and browsers came back in 2019 with another vote submitted to the CA/B forum, again rejected but by a smaller majority. The market is on the move. Players like Let’sEncrypt propose certificates with a duration of 3 months, others want to keep long durations to avoid overloads of intervention on servers. One thing is certain, the market does not have the automation systems in place yet to make the management and installation of certificates easier, a delay of one or two more years would otherwise be preferable, or at least judicious.
But all this is without counting on Google threatening to act unilaterally if the regulator does not follow… certainly in 2020.
From TLS 1.0 to TLS 1.3: forced advance
Expected in January 2020, Microsoft, Apple, Mozilla, Google and Cloudflare have announced their intention to depreciate support for TLS 1.0 (a protocol created in 1999 to succeed SSL 3.0, which has become highly exposed) and TLS 1.1 (2006), both of which are currently suffering from too much exposure to security flaws.
While TLS 1.2 (2008) is still considered secure today, the market seems to be pushing for TLS 1.3, the most recent version of the standard, finally released in the summer of 2018. TLS 1.3 abandons support for weak algorithms (MD4, RC4, DSA or SHA-224), allows negotiation in fewer steps (faster), and reduces vulnerability to fallback attacks. Simply put, it is the most secure protocol.
A small problem, however, is that many websites are taking action. At the beginning of 2019, only 17% of the Alexa Top 100,000 websites supported TLS 1.3, while just under 23% (22,285) did not even support TLS 1.2 yet. If the decision to depreciate older versions of the protocol is a good one, the form adopted by the major web players can be criticized, in particular by its unilateral nature. In the meantime, get ready, we are heading there.
The threat of quantum computing
Companies are talking more and more about quantum computing, including Google. But the reality is, while quantum will impact our industry, it certainly won’t be in 2020, or for at least a decade. There are still many questions that need to be answered, such as: What is the best algorithm for quantum resistance? No one has that answer, and until there is a consensus in the industry, you are not going to see any quantum solutions in place.
IoT is growing, but the lack of security remains a problem
IoT is a success, but a number of deployments are being delayed due to a lack of security. In 2020, cloud service providers will provide or partner with security companies to provide a secure provisioning and management of devices, as well as an overall secure IoT ecosystem, for their customers.
The regulatory frameworks for IoT manufacturing and deployments will most certainly be led by the EU, although we will also see an increase in the US. Attacks, compromises and IoT hacking will, unfortunately, continue. In addition, security standards will not be met and we will not even come close to a higher percentage of secure devices. Why is that? Original Equipment Manufacturers (OEMs) are still not willing to pay the costs involved or pass them on to consumers for fear of losing sales.
China’s encryption laws will create a lot of uncertainty
In recent years, part of the digital transformation of the world has led to the codification of rights and restrictions on data in national laws and regional organizations. PSD2, GDPR, CCPA, PIPEDA… a real headache for international companies faced with regulatory standards and compliance.
On January 1, 2020, China’s encryption law was due to come into force. An additional data and… still unclear to those doing business in China. Clarification is still needed on several fronts. For example, commercial encryption for international companies must be approved and certified before it can be used in China – but this certification system has not yet been created. Similarly, there is uncertainty about the key escrow and the data that must be made available to the Chinese government. This has led to a wave of speculation, misinformation and, ultimately, overreaction. Given the opacity of parts of the new Regulation, many companies are opting for a wait-and-see approach. This is a wise tactic, assuming your organization does not have an experienced Chinese legal expert.
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.
More user-friendly, more comprehensive, more
attractive… our brand new and improved
Nameshield SSL interface is being launched on Thursday, June 13th allowing
you to manage all of your certificates.
You will now have access to key metrics on your
certificate portfolio, to different certificate lookup views (such as complete
portfolio, detailed overview, certificates nearing expiry, pending orders,
expired or revoked certificates), to an Organization and Contact management
tool and a redesigned ordering system.
Lastly, a decision support tool has been
included in the interface to help you choose the certificate that’s right for
your needs.
The certificate range has been updated to cover
all types of certificates, SSL, RGS, Code Signing, Individual certificates and
with all levels of authentication.
The SSL team remains at your disposal for a
demonstration and a complete user guide is available covering all possible
operations and actions.
Or how to benefit from it to implement a certification strategy specific to your company?
In January 2013, a new type of DNS Resource Record has appeared to improve the control chain in the SSL certificates issuing. This record, called CAA for Certificate Authority Authorization, allows to specify for a given domain name which Certification Authorities are authorized to issue certificates.
It’s an extremely interesting creation, in particular for big companies and groups, which technical teams are scattered in the World and for which it’s often difficult to require a global certification strategy. It’s not unusual for companies to accidentally discover the existence of certificates requested by teams not knowing the processes, by external consultants, issued by Certification Authorities with a bad image, or for certificates of low level of authentication (DV). The implementation of CAA record on your domain names is a good solution to control what the teams are doing and the news on SSL’s world will help you do that.
Indeed, if the CAA has been detailed in the RFC-6844 from 2013, it was not mandatory until today, for a Certification Authority to check if it was authorized or not to issue a certificate on a given domain name, hence a certain uselessness of this and a very low adoption.
September 8th, 2017 – The CAA checking becomes mandatory
We had to wait until March 2017, and a positive vote of the CAB/forum (ballot 187) to make this verification mandatory. Since the 8 September, the Certification Authorities have the duty to do this verification at the risk of sanctions from CAB/forum and browsers, the recent news regarding Google and Symantec has shown us how it’s not in their interests.
Three scenarios occur during this verification on a given domain name:
A CAA record is set and indicates the Certification Authority name, this one can issue the certificate.
A CAA record is set and indicates a Certification Authority’s name different, this one CANNOT issue the certificate.
No CAA record is set, any Certification Authority can issue a SSL certificate.
It’s important to note that for a given domain name, many CAA records can be declared. A simple tool (among many others) to test your domain name, is available online: https://caatest.co.uk/
How to benefit from CAA for my company?
If it’s not already done, the establishment of the CAA checking is the opportunity for your company to define a certification strategy and to be able to ensure that it is complied with.
Define one (or multiple) Certification Authority corresponding to your values and to your expectations in term of service quality is a first step.
It will require to put around the table the marketing stakeholders to validate the impact on websites display and the technical services to ensure of the chosen provider’s quality. It will then be necessary to declare these CAA records in the different zones of your domain names.
It’s then important to communicate with all the operational staff so they become aware of the rules imposed within the company, in order not to block them in obtaining a certificate.
Indeed, Nameshield’s experience shows that SSL certificates are often requested in a hurry; moreover the browser’s last versions are not kind towards certificates’ errors by ostensibly displaying “not secure”. In consequence, blocking the issuing of a certificate because the communication didn’t get through can be damaging.
Such strategy presents real advantages in the control of certificates, in marketing, technical, risks control and costs associated to certificates. It’s necessary to conduct it with full knowledge and in order to do it, our SSL experts’ team can assist you.
On Wednesday, August 2nd, Digicert announced the acquisition of Symantec’s Website Security Business branch (including SSL business, and some other services). It’s the direct consequence of the conflict opposing Symantec to Google for a few months.
DigiCert’s Twitter account
You have certainly already heard about this disagreement opposing two companies on a certain number of certificates issued by Symantec and the possible loss of trust towards these certificates in the next versions of Chrome. Many information and dates have been flowing on this subject, sometimes contradictory, it can be sensitive to evaluate the impact on your own certificates.
Nameshield as a Symantec’s Platinum partner, has followed very closely the development of this case to ensure that its customers and partners don’t risk to be impacted and suffer from a loss of trust within their browsers. The very latest developments of this case lead us to communicate the following important information:
What happened?
Google and Symantec had a dispute in 2015, Symantec’s teams taking for example certificates often based on the CN google.com, by really issuing them to delete them afterwards. It was objectively a mistake and Google has sanctioned Symantec by making compulsory the subscription of all certificates within the Certificate Transparency base, which since became the market standard and a mandatory for all Certification Authorities. This decision was effective on June 1st, 2016.
At the beginning of 2017, Google and Mozilla announced the discovery of 127 Symantec certificates with irregularities, leading to a thorough investigation from Google, which would have found nearly 30 000 impacted certificates. Google decided to severely sanction Symantec by reducing the certificates’ duration to 9 months and by deleting the EV status for Symantec certificates in a very short period. Symantec has immediately reacted by sanctioning 4 partners who were at the roots of the errors. Many discussions between the two groups, and with many important actors of the industry, took place since March 2017. A part of these publications, proposals and counter-proposals has created confusion.
These different discussions have led Google and Symantec to an agreement on a method and a transition calendar towards a new PKI infrastructure for Symantec. Google officially communicated on this subject on Friday, July 28th. This communication can be consulted here.
Symantec is committed to create a new PKI infrastructure in collaboration with a third party to prove its good faith, answer to the transparency requirements of Google and maintain the high degree of trust which has always benefited the group from the web users. This infrastructure change will take place on December 1st, 2017 and will require the replacement (or if any, the renewal) of all the existing certificates for Symantec brands, Thawte, Geotrust and RapidSSL. This extended deadline will allow a smooth transition, without impact on web users.
Since August 2nd, we know that this trusted third party will thus be Digicert.
What Calendar?
Google distinguishes Symantec certificates issued before June 1st, 2016 from those issued after this date (Mandatory subscription in Certificate Transparency). The loss of trust in these two categories of certificates will arrive through two different versions of Chrome, hence the following calendar:
– Category 1: Certificates issued before June 1st, 2016, will have to be replaced (or renewed*) between December 1st, 2017 and March 15th, 2018 (arrival of the beta Chrome 66)
– Category 2: Certificates issued between June 1st, 2016 and November 30th, 2017, will have to be replaced (or renewed*) between December 1st, 2017 and September 13th, 2018 (beta Chrome 70 arrival).
The eventual emergency communicated by the different market actors is therefore not relevant.
*anticipated renewal: a renewal can be done until 90 days before the expiration date of a certificate, without penalizing the duration of the new issued certificate.
Are you impacted?
Yes you are, if you dispose of certificates issued with one of Symantec brands (Symantec, Thawte, Geotrust, RapidSSL) through Nameshield or other providers with whom you would be working. All that remains is to distribute them in the two mentioned categories. We could help you identify the eventual impacted certificates and their distribution in the right categories, in order to plan the actions to carry out from December 1st, 2017.
And Digicert in all this?
Digicert is an American company, of which the actual market share represents 2.2% of the world market, based on the last report of W3tech. It’s a company renowned for the work quality of its authentication team and its conformity with the CAB forum’s Baseline Requirements. Digicert is regularly growing for several years on serious values and manages certificates portfolios of very important companies and websites around the World.
Digicert will become a major actor of the certificates market, by taking the 14% of the global market shares of Symantec. More interesting, the 40% of market shares on EV certificates and 30% on OV certificates which represents Symantec.
On paper, this acquisition is good news for all the Symantec customers. It’s a guarantee of continuity in the quality of provided services. It’s the guarantee of a successful transition towards a new PKI infrastructure requested by Google. It remains to monitor Digicert capacity to respect the calendar imposed by Google, we will closely monitor this.
What does Nameshield think of this?
Nameshield trusts Symantec and its teams for several years. On one hand, for its quality of service, which allows us to provide you a service of first level and on the other hand for the brand image and the trust created by this group to the web users. The management of this Google/Symantec crisis doesn’t question the trust we have in this partner, and whose support remains irreproachable.
Furthermore, we were for a few months, in relation with Digicert to extend our solutions portfolio, we welcome this acquisition announcement like a positive news for our customers and partners, by being confident on the continuity of the services we could offer you. It means that the trust you place in us is primordial and if you want to move in a different direction, Nameshield remains at your service to propose alternatives to you.
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.
