Category: SSL

SSL certificates reduction to 2 years maximum

SSL certificates reduction to 2 years maximum

The CAB forum, organization which defines the SSL certificates issuing and management rules approved the SSL certificates reduction to a duration of 2 years against 3 previously. Initiated by the browsers Chrome and Mozilla heading, this decision moves in the direction of an always more secured Internet by forcing the actors to renew more often their security keys and to stay on the last standards of the market.

This decision will be applicable to all Certification Authorities from March 1st 2018. In order to ensure a smooth transition, from February 1st 2018, Nameshield will not propose certificates with a 3 years duration anymore.

What impact for your certificates?

The new certificates will thus have a maximum duration of 825 days (2 years and 3 months to cover the possibility of 90 days early renewal). EV certificates were already under this scenario, so are concerned the DV and OV certificates in all their forms (standard, multi-sites or wildcard). Nothing in particular for these certificates.

For existing certificates, this new duration will have a consequence, since it will apply to all the certificates from March 1st. A 3 years certificate issued recently and which would need to be replaced beyond the 825 days deadline, will then have to be authenticated again. It is then important to know it to prevent urgent reissue, including for the simple SAN adding. You have to check beforehand if the certificate to replace may be impacted, this is the case of DV and OV certificates, the EV are also not concerned here.

Nameshield’s SSL team will inform you regarding the concerned certificates.

The CAA becomes mandatory in the small SSL’s world

Or how to benefit from it to implement a certification strategy specific to your company?

The CAA becomes mandatory in the small SSL’s world

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.

The CAA becomes mandatory in the small SSL’s world

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.

Some movement in the SSL’s world: Digicert acquires Symantec’s certificates activity

Digicert acquires Symantec’s certificates activity

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 acquires Symantec’s certificates activity
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.

Towards a 100% encrypted web, the new challenges of HTTPS

Between Mars, 2016 and Mars, 2017, Let’s Encrypt has issued 15 270 SSL certificates containing “PayPal” term, 14 766 of these certificates were issued for domains leading to phishing websites. It’s the result of the recent analysis led by Vincent Lynch, SSL expert.

 

Paypal fake or real

 

Lynch was closely interested in this case, after an interesting article published by Eric Lawrence (Google Chrome Security Team) in January 2017, the image above is from this article named “Certified Malice “which exposes deceitful SSL certificates and counts “only” 709 cases for PayPal and much more for big American brands: BankOfAmerica, Apple, Amazon, American Express, Chase Bank, Microsoft, Google…

What’s the impact on web users?

In January 2017, Google and Mozilla have updated their browser with Chrome 56 and Firefox 51, and a major change has appeared for web users: “Secure” and “Not secure” have appeared in the address bar.

In 2015, the initiative Let’s Encrypt, supported by big names of Internet (EFF, Mozilla, Cisco, Akamaï…) was created with the purpose of massively and freely spreading SSL certificates to the whole world. One year and a half later, Let’s Encrypt issued millions of certificates and other initiatives have followed.

Who says free, says few or no verification for delivering certificates, and an army of cybercriminals who rush towards these certificates to secure their illicit contents: phishing, malware… and show the term “secure” on their address bar. How can the random web user easily differentiate between real and fake?

For reminder, there are three verification levels for certificates allowing to show HTTPS: Domain Validation (DV) considered as low authentication, Organization Validation (OV) with high authentication and Extended Validation (EV) with strengthened authentication.

Free certificates are DV, and represent almost 90% of certificates, most of the time on “small” websites. OV certificates (9%) and EV certificates (1%) are fewer but protect almost all websites with high traffic. GAFA (Google, Apple, Facebook, Amazon), are all in OV or EV for example.

SSL Certificates - DV OV EV

The problem for web user is the lack of distinction in browsers between DV and OV certificates. These two types are shown the same way, as being “secure”, but EV certificates display the name of the certificate’s owner in the address bar.

By looking at the image at the beginning of this article, we understand easily the concern on EV for PayPal: to easily differentiate real from fake. This is the reason why Nameshield will systematically advise the use of EV for display website, in particular for their clients exposed to cybersquatting, phishing or counterfeit.

 

Two forces opposed for the future of HTTPS

Sadly, things aren’t so simple, and where logic would like to differentiate clearly between the three types of certificates, or at least two types (DV/OV), Google disagrees and wishes, on the contrary, to suppress the EV display altogether. Chris Palmer (Senior Software Engineer for Chrome) subtly confirms this point in his article published here.

Today we are in a situation where Historical Certification Authorities, Microsoft and to a smaller extent, Apple, are facing Google, Mozilla and Let’s Encrypt in a perspective resumed here:

 

Google/Mozilla/Let’s Encrypt perspective:

 

HTTP = not secure

 

HTTPS = secure

 Historical Certification Authorities/ Microsoft/Apple perspective:

HTTP = not secure

HTTPS DV = no sign in the address bar

HTTPS OV = secure

HTTPS EV = company’s name in the address bar

 

Inside the higher authority of SSL, the CAB/Forum, the discussion is still opened at this moment. We can easily understand that Certification Authorities look unfavorably at the end of the visual distinction between DV/OV/EV in browsers, it’s their purpose to deliver certificates with high authentication, but is it wrong? It’s to reassure the web users by securing the identity of the website they visit.

In the opposite, Google and Let’s Encrypt don’t hesitate to say that phishing and guarantee of website content, don’t depend on Certification Authorities, and that there are other systems responsible for that (for example, Google Safe Browsing). Therefore we have to have a binary perspective: exchanges are encrypted and inviolable (= HTTPS = secure) or they aren’t (= HTTP = not secure). We can simply wonder by this perspective, which defends itself, if it’s not a semantic problem of the used term “secure” instead.

What does “secure” mean for web users? By seeing “secure” in their address bar, do they enter their login/password or credit card numbers? We can think that yes, they do, and in this case, actual risk does exist. Kirk Hall (Director Policy and Compliance – SSL, Entrust) has done a noticed intervention at the last RSA conference on this subject (if you have time, the record is here).

You can’t neglect financial industry weight and big companies which look unfavorably at the growth of fraud online risk, Google can’t ignore that.

 

How to reassure web users?

For the time being, we can only encourage you to choose Extended Validation certificates for your display websites and/or your e-shop in order to facilitate web users’ tasks and to stay informed of what’s going on on the web. To reassure and educate web users by mentioning on your website the choice you have made in security and authentication.

As you probably monitor domain name registrations on your brands, today you can also monitor certificates registrations so you can react quickly.

And as web user, when the term “secure” is mentioned in the address bar, systematically control the certificate’s details to see who the owner is.

HTTPS and SSL: Google continues its offensive

https-chromeChrome 53 launched on 31 August 2016 and with it Google is continuing its offensive for a safer internet.

With its Chrome navigator, Google signals even more clearly when as site does not use httpS on its landing page. And the version to come will continue in this vein barring purely and simply HTTP with a Red cross. This  ‘ugly defacement’ will be difficult to accept on corporate websites, in particular well-known brands.

Http Cdiscount
Website http
Https Amazon
Default httpS website
Https Nameshield
Website httpS EV (Extended Validation)

Firefox has already announced a similar measure. Add to that the httpS as an additional factor in SEO and the inclusion of httpS for personal data entry pages in the results for Google shopping, if you have not yet considered it, it’s time to prepare to migrate your web site to a more secure environment.

Why adopt HTTPS now?

  • It is becoming essential.
  • It is good for your online image, especially with Extended Validation (Green Address bar).
  • The transition from HTTP to HTTPS is becoming more pressing and it is better to prepare for it now rather than as a matter of urgency.

What will the navigation bar look like in January 2017?

On the pages of websites offering HTTP password entry or accepting credit card details there will be a small warning graphic and will feature the text  “Not Secure”.

Going forward, What Chrome proposes to display

For all websites, Google’s ultimate goal is to display the not secure wording for all HTTP pages.

Note secure

Source : https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html

The Nameshield team can assist you in selecting the most appropriate SSL certificates for HTTPS, contact your account manager to discuss.