Send a request

and we will call back to you soon

*fields are required



Chrome 59: Security-related updates in the new release

Chrome 59 release includes number of changes related to security and SSL. One of the hottest topics through the recent discussions is referring to issuance of incorrect SSL certificates by Symantec certification authority. Large browsers have yet to decide on how to reasonably penalize Symantec for their oversight, and therefore SSL certificates from this certification authority will remain trusted in Chrome 59.

Proposals received from Symantec, were perceived by the developers of Chrome in a positive way. In particular, it was suggested that Symantec will be temporarily issuing SSL certificates via third-party partner until their own release process is debugged to the smallest detail. It was decided that this will help to avoid problems with the erroneous issuance of certificates in the future.

In addition to above mentioned updates, in release of Chrome 59 all bugs related to the substitution of URLs were fixed as well. There are no additional details about these bugs announced yet. It was decided to postpone the announcements in order to avoid their mass exploitation until users update the browser to the latest version.

Other noteworthy changes of the latest release:

  • Added a transparency log Venafi Gen2. Previously, it was trusted in Chrome, but was removed due to stability issues.
  • Headless Chrome. It is a special environment without a graphical interface, based on the console. With its help, you can develop, test and perform automated tasks that do not require interaction with the user through a graphical interface.
  • Added support for the Worker-src directive. It allows you to restrict valid URLs for Workers, SharedWorker, and ServiceWorker in Chrome.
  • Downloading additional resources via FTP is now forbidden. Pages (both HTTP and HTTPS) that try to download FTP resources will be blocked. In the future, Chrome plans to abandon the built-in support for FTP in general.
  • Blocking resources by URL or file type. In the Chrome Dev Tools, it is now possible to block certain resources in order to test the workability of the site. 


Symantec representatives are continuing public dialogue and announced their proposals regarding the issuance of SSL certificates

On March 23, Google Chrome developers in their blog announced the planned consequences for Symantec regarding the incorrect issuance of SSL certificates. Symantec thoroughly analyzed Google’s accusations and prepared a list of actions aimed at enhancing security in the area of issuing SSL certificates.

First of all, Symantec has appealed to its customers to assess the potential impact of the sanctions described by Google for the erroneous issuance of SSL certificates. Among the company's clients are numerous financial services providers, medical organizations, government agencies, etc. If the planned changes by Google will take in effect, it will jeopardize all infrastructure of these organizations as they will seriously suffer due to complex dependencies from Symantec root certificates.

The process of moving to a new certification authority can take several months, and in some cases up to several years, due to uncertain or undocumented dependencies that may arise. In addition, only a few companies managed to implement the automation of the new certificate life cycle, which is required for the secure and beneficial implementation of certificates with a shorter validity period. As Symantec representatives stated, compatibility issues that may arise as a result of full-scale certificate replacement will be very serious and unpredictable.

Symantec suggestions addressed to the community

Symantec admits that it is necessary to ensure full transparency of all actions of the certifying authority, and therefore it has made its proposals aimed at enhancing trust and achieving an unsurpassed level of security.

  1. Symantec offered to conduct a retrospective audit of all active EV SSL certificates issued by them in order to prove their reliability and responsibility. They’re planned to attract a third-party company as auditor. This proposal was made in response to the planned refusal to trust the EV certificates (both past and future) from Symantec in the Chrome browser. The company plans to complete a third-party audit by the end of August 2017.
  2. Historically, Symantec issued certificates either directly or through affiliate registration authorities (RAs). As a second step, Symantec wants to audit all certificates issued by their RA partners, including CrossCert, Certisign, Certsuperior and Certisur. This verification is also planned to be completed before the end of August 2017.
  3. Symantec will conduct a six-month WebTrust audit between December 1, 2016 and May 31, 2017. After that, the audit will be conducted quarterly, starting from June 1, 2017 to August 31, 2017. The purpose of this action is to ensure maximum transparency in all transactions and new certificates, issued by Symantec.
  4. A quarterly report will be published from which the community will be able to learn about the progress of external audits and the progress of the company's comprehensive improvement program.
  5. Symantec will make proposals to the CA / B Forum to improve guidelines related to exceptional customer requests. According to Symantec, the guidelines should be supplemented by items related to the risk assessment, which carries such customer requests. It will also be necessary to prescribe the conditions under which CA / B Forum will be able to effectively approve such exceptional requests (beyond the established rules).
  6. Symantec plan to revise the procedure of responding to requests from the browser community, making responses more detailed and quick.
  7. Symantec fully supports the transition to certificates with a shorter validity period. By August 31, 2017 the company plans to offer SSL / TLS-certificates with a three-month validity period, which will be in demand among customers who have already implemented SSL automation. Symantec in the short term will be investing in upgrading certificate issuance systems and creating tools that will allow customers to quickly and securely deploy their certificates and configure their systems.
  8. Symantec will recheck all issued certificates that are more than 9 months old. Auxiliary verification will increase trust in the original certificate, which is an extension of the basic trust model of the CA.
  9. The company will increase amount of investments in security and risk assessment. The first step: the involvement of a third-party company to analyze and assess the risks of all operations of the Symantec CA. These actions are planned to be completed by the end of October 2017.
  10. Symantec will update their Root Program to clearly distinguish between different uses of certificates. For example, specialized roots and / or certification sub-authority will be created to segment customers that use public hierarchies for closed ecosystems, mixed ecosystems, customers that require certificates with a longer lifespan, clients that work with voluminous web traffic etc.
  11. Symantec plans to deploy its Global Intelligence Network technology infrastructure to identify encrypted websites that are at high risk of threats. These sites will use risk mitigation measures for Symantec certificates.

Which steps have already been taken by Symantec 

Symantec has already implemented a number of actions, presented in the proposal above. First, the company decided to cease issuance of certificates through the registration authorities (RA). Also, experts conducted an audit of all certificates issued by their previous RA partners. The certificate report is published in the Symantec blog.

Moreover, Symantec has achieved an unprecedented level of security, by adding all of issued certificates (not only EV, but DV and OV) to the transparency logs. The industry is only planning to move towards this direction.

Symantec is one of the key players in the web-based trust ecosystem. The Company makes every effort to minimize the consequences caused by the erroneous issue of SSL certificates.


As of Chrome 58 release, self-signed certificates without SubjectAltName will no longer be trusted

In the Chrome 58 release, certificates that do not specify host names in the SubjectAltName field will lead to a "Your connection is not private" error. A similar change was implemented in Firefox 48, but users did not report any problems prior to that. 

Details of the error page are indicating type of error - [missing_subjectAltName]. This was done in order to ease user's understanding of the problem, because the error code NET :: ERR_CERT_COMMON_NAME_INVALID is generic and can be displayed in different context. Warning “Subject Alternative Name Missing” is also present in the Security panel of developer tools.

Chrome 58 allows to temporarily restore the old browser behavior. This could be done by using the EnableCommonNameFallbackForLocalAnchors policy. Doing so allows to avoid the re-generation of certificates. However, this solution is temporary and will be removed in future versions of the browser (no later than Chrome 65). We strongly advise that you re-generate self-signed SSL certificates with the Subject Alternative Name extension enabled.

It is also important to remember that the utility Makecert.exe, supplied with Windows, is not able to set the SubjectAltName field in the certificates, and therefore you should not use it to generate self-signed certificates. Instead, it's best to refer to the modern SelfSignedCertificate command in PowerShell.

Self-signed SSL certificates provide very weak (almost zero) protection against intruders. We strongly suggest switching to commercial SSL certificates from trusted certification authorities, such as Comodo, Symantec, Thawte, etc. You can always order them in our store at affordable prices.


CA / B Forum clarified rules for issuing SSL certificates for .onion domains

It was recently announced that CA / B Forum, the regulator of the SSL industry has adopted a new provision: it became mandatory to include the Tor Service Descriptor Hash extension in TBSCertificate. Now the certifying authority can issue an EV certificate for the .onion domain name only after complying with two of the following rules:

  • The certification authority must include the CA/B Forum extension in TBSCertificate to pass the hashes of the keys associated with .onion addresses.
  • The certification authority must include the Tor Service Descriptor Hash extension in the following format:

cabf-TorServiceDescriptorHash OBJECT IDENTIFIER ::= { }

TorServiceDescriptorHash:: = SEQUENCE {

algorithm                        AlgorithmIdentifier

subjectPublicKeyHash   BIT STRING              }

Here AlgorithmIdentifier is the hashing algorithm defined in RFC 6234. This algorithm is performed on an unprocessed public key in the .onion service.

SubjectPublicKeyHash is the hash value of the unprocessed public key.

The proposed changes have added the extended validation rules adopted by the CA / B Forum. For this change, 9 certification authorities are voted with 4 abstentions, and 4 browser manufacturers.

About .onion domains

Domains .onion are used in Tor to hide personal data, location and behavior on the web. Tor is designed to protect confidential information online. A deep web with restrictions for indexing and searching, has about 500 times more sites in comparison to an open web. Very often .onion sites are used to store databases, as well as for the activities of government agencies, educational institutions and private companies.

Since the deep web is mostly isolated, it is difficult for users to determine whether they are on the genuine .onion website. A public SSL certificate makes it easier for users to ensure that they are on the genuine site.

You can always order SSL certificates for .onion domains in our store. 


Chrome 68 will flag all pages with HTTP as unsecure in incognito mode

Google continued efforts for implementing encryption on all sites of the World Wide Web. Beginning from October, company will display new security warnings for all HTTP based pages in Chrome browser. Earlier this year, Chrome developers have already implemented "not secure" notification for HTTP sites that request credit card information or passwords.

Since October 2017, "not secure" warning will appear in the browser's address bar for all HTTP pages that contain any data entry forms. In addition, this warning will be displayed in the incognito mode of the browser for all HTTP pages.

As Google experts report, users are expecting a high level of confidentiality for the incognito mode. Notification of the warning message will prompt site owners to migrate to HTTPS more rapidly, which will allow maximum protection of valuable information.

According to Google experts’ statements, they plan to make "not secure" warnings for all HTTP pages by default. The exact timeframe for the adoption of this decision is still undetermined; however, due to active transition to HTTPS, most likely that this feature will take in effect in a near future. 

Prerequisites for migrating to HTTPS

The main threat of HTTP pages is that they are transmitting unencrypted data, which makes them vulnerable for attackers. Data interception, tracking of Wi-Fi networks or implementation of man-in-the-middle attacks - all this jeopardizes legitimate web services. Moreover, this refers not only to passwords and to credit cards. Any information provided by users on the websites must be protected.

All major websites, such as Google, Twitter, Facebook, etc., have already switched to HTTPS a long time ago. According to Google analytics, HTTP pages with passwords or credit card entry forms, which were flagged «not secure», have experienced a 23% drop in traffic to them. Based on that statistics, we can be confident that users have less confidence in the pages on which this warning is displayed.

If you are behind with transition to HTTPS, it is time to fill up the gap and purchase SSL certificates from trusted certifying authorities in our store.  

Start a 14-day Free Trial

Try SSL certificate with a 14-day free trial and feel our great service It’s very easy to start - you don’t risk anything. If you will not like it, just dont pay after end of trial. No credit card required.

Are you ready to try?

Have any questions? Call us now +31 20 7640722

Give us advice!

We are looking which good or services could we also supply.

Hosting services:

Other goods and services:

Leave your contact details to get the FAQ by email

A link to download the PDF version of the FAQ has been successfully sent to your email

Error sending mail. Please try again later.

*fields are required