Guest post by Hackrfi: Why does one buy commercial certificates, and another ends up with Let’s Encrypt?

The Let’s Encrypt DV certificates still give rise to discussions. Last month we wrote about answering the customer’s question “Can you tell us why we should use you and Entrust when we get certs free of charge e.g. from Let’s Encrypt?”. This time the subject is reviewed by one of the top professionals in IT security. Thomas Malmberg has written this article from the viewpoint of Hackrfi Ltd. but I have met him the first time in 2012 when he was working as the IT Security Manager for the Aktia bank. We have since kept contact and I have the pleasure of exchanging ideas with him about data security especially in the financial world at our annual lunch meeting. Thomas’s position as the CEO of both Mintsecurity and Hackrfi gives him a special vantage point. Let us give the stage to Thomas!

Hackrfi is a small and agile organization which could use Let’s Encrypt

We make bug bounty programs in a limited market area. Our infra structure is not complex but there is enough of it so that we can with good conscience call it our infra structure. Our operation is based on IaaS. We have chosen to use a termination solution which supports native ACME – which means that we are able to automate the Let’s Encrypt certificate management and renewal in a very simple and reliable way. Free-of-charge and without manual work.

However, we got ourselves a commercial wildcard certificate. Why so?

As a start it is good to understand that all certificates – including self-signed certificates – are similar regarding to their encrypting features. The protection given by one key-pair is cryptographically as valid as that of any other key-pair if the bit depth is the same.

Credibility and trust

In the previous chapter I emphasized the cryptographic similarity of different certificates. However, here I make a statement that the task of certificates is not just to provide cryptographic strength but to provide also managerial strength. With this I mean that the managerial and technical process for providing the certificate has more meaning to business than the cryptographic strength. If someone wants to know the main difference between DV (Domain Validated) and OV (Organization Validated) certificates, this is it.

The weakness of Let’s Encrypt is that anybody can order the domain company.com, pretend to be a representative of Company Ltd. and get also the certificate for the domain. In a commercial certificate the managerial strength is built by the fact that a reliable third party verifies the fact that company.com is Company Ltd.

Automatic certificates?

What could be more practical than a fully automized and free-of-charge solution? As a matter of fact, in a bit more complicated environment (which we don’t supposedly have …) the practicality is also something else. The challenge in the Let’s Encrypt automation is the validation itself. Each domain needs to be accessible from the internet for the automation to work. If you want a certificate for the domain internalandsecret.hackr.fi you need to publish the domain so that a) the information of the domain is found in a DNS server and b) the domain is reachable technically (http) from the validation machinery of Let’s Encrypt.

And here it is. Our “internalandsecret” is not any more internal and secret when the before said terms are met.

The certificates in the intranet

“You don’t need certificates in the intranet – or you can use the self-signed method” can be heard. Actually, this is not so. This is not valid for the simple reason that in a modern API world where CI/CD pipelines are being used the tools themselves require certificates which can be verified. If the tool cannot verify the certificate it vomits to the error log a mystical message which then needs to be studied. Then one spends hours and days in Google to find out how one can get the system to work with self-signed certificates. And when this has been solved, the next step on this path gives the next error message. And so, this goes on. Not very sensible for the business.

With a commercial certificate “it just works”.

Complexity and straightforwardness

In addition to the mentioned API world there is also the container world. There the services and endpoints are popping up – because it is easy and automized. When endpoints emerge also domain names are created. And when everything is easy various test and staging environments also appear. Each needs to be equipped with a certificate. The only sensible option is to use a wildcard certificate. Does Let’s Encrypt support wildcards? Yes, it does. But – to get the wildcard working – you need to do the validation with DNS records. In our infra there is not the needed automation available. It is not yet such mainstream that we would make the effort. So, in order to get the Let’s Encrypt wildcards to work, we would need to do manual DNS modifications and in addition to that we would need to install certificates manually. Constantly and regularly. Not very sensible for the business. Personally – not very attractive.

The result

The result is that a commercial wildcard certificate fulfills all business needs including reliability, trust, secrecy of the intranet and requirements of modern tools. Time is not lost studying strange error messages. The technical solutions are tested and reliable – and not home-made gadgets, which require maintenance and care. The result is also that if there is a need to add a new web site companycampaign.com in parallel to company.com this can be done quickly with Let’s Encrypt when the idea for the campaign has emerged. So, Let’s Encrypt has its place and it has done a lot of good to make encryption a norm and not exclusivity. The danger from the viewpoint of the organization and IT is that when you have the hammer in your hand the business and infra start to look like mere nails.

More information from Thomas: thomas(at)hackr.fi or https://hackr.fi/