No, free certs are not a problem. Despite what the pay for cert vendors say, a cert is a cert.

With Let’s encrypt on the scene and making something of a mockery of the paid for secure certificate lobby it is no surprise that some of them have resorted to some rather unhandy tactics in an attempt to rubbish the competition who are massively undercutting them.

A few weeks back, Trustify did exactly this by publishing a rather bizarre infographic on everything they saw wrong with free certs including the claim that free certs are insecure. They’ve since removed the infographic likely because they were told exactly where this was wrong by many people.
However, I did want to cover what they said about free certs being insecure and show why certs themselves have nothing to do with the security of a server and little to do with the security of the connection between the client and the server.

First of all, what did trustify say?

This actually shows a totally fundamental misunderstanding of what a certificate is. In short, a certificate is just two files – a public key and a private key. Now, there are certain security elements in how those keys are generated which is why a few years back it was necessary to move from SHA-1 to SHA-256 but those elements aside, it is perfectly possible to put a “secure” cert on a server that exposes data.

There still seem to be people who think that a secure certificate somehow magically protects a server from attack, it does not. A certificate in no way absolves an admin of the responsibility and requirement of patches. If a server has a secure certificate it will still be attacked and if it is never patched, at some point that attack will succeed.

All a certificate does is ensure that the communication between client is connecting to the intended server This is an important thing to note – a server can quite easily host a cert but not secure the communication channel.

So, let us actually put this to the test. Trustify have made the claim a few weeks ago so let us see if they can back it up.

Trustify score an F on Scott Helmes site.

Over to Qualys and:

An A. Not bad but not good.

Now, let me compare this blog site which uses one of those “insecure” free certs

And again on qualys

A+ on both Scott Helmes site and Qualys. This is because I’ve got the necessary additional headers in place and I'm only using TLS 1.2

Each header is a one line change in an apache or Nginx config. It’s a registry tweak and reboot in windows. I posted a sample apache config with these headers over on github sometime back.

None of this stuff is difficult, I am always horrified when a cert issuer comes out with outrageous claims like this and yet cannot implement what I consider the basics.

To give Trustify a little bit of credit, they did delete the tweets but, like too many companies, rather than reply to criticism they just battened down the hatches and ignored the criticism. They also never fixed the myriad of security and cert issues on thier site. Their attitude to both the infosec community and security itself does not provide any confidence. I have a feeling that this is not the end of the story.

Acknowledgements:

• Scott Helme for screen grabbing the Trustify tweets before they deleted them.
• Sean Wright for a correction on the cert process itself.