Should you use Let’s Encrypt for internal hostnames?

It means your employees aren’t constantly fighting browser warnings when trying to submit stuff internally, all your http traffic is encrypted

Julien Savoie has written a brilliant post explaining how you can enable https on your intranet.

This is useful for several reasons. It means your employees aren’t constantly fighting browser warnings when trying to submit stuff internally. All your http traffic is encrypted. You don’t need to install a self-generated root certificate on devices. Lovely!

But there’s a downside. Every TLS certificate created by Let’s Encrypt is recorded in a Certificate Transparency log. These CT logs are primarily to detect maliciously or mistakenly issued certificates. For example, you can look through them and see that someone unauthorised has created a cert for your domain – or its sub-domains.

But there is a downside. The CT logs are public and can be searched. Here’s all the certificates issued for Twitter’s sub-domains.

There are a few ways that this can be dangerous for use with internal services.

Firstly, it aides reconnaissance for attackers. Having a “map” of your internal infrastructure is useful. Especially if you have “obviously” named servers like exchange.example.com or customerdata.example.com. Also handy for social engineering – who else but someone internal would know that gandalf.example.com was a valid server?

Secondly, it might expose some vulnerabilities – depending on how you name things. Let’s hope you don’t have log4j.example.com!

Thirdly, there’s the potential for espionage. Do you want your competitors knowing that you’ve got olympics-campaign.staging.example.com?

I’m sure you can think of a few other ways this could be used for mischief and mayhem.

As I wrote a few years ago, “There’s no HTTPS for the Internet of Things”. Internal networks which only have IP addresses cannot use TLS certificates. OK, so you decide to have an internal DNS – now the whole world knows you have doorbell-model-xyz.myhome.example.com!

The only real answer to this is to use Wildcard Certificates. You can get a TLS certificate for *.internal.example.com

This requires setting up a DNS-01 Challenge – which can be more difficult to configure and has some non-obvious risks. And, sadly, Wildcard certificates come with their own difficulties.

Recap

I don’t think there’s a good solution to this.

Self-signed certificates require something to be installed on all clients. Not always possible with BYOD.
Named LE certificates expose details of your infrastructure which you may wish to keep private.
Wildcard certificates require a heightened level of co-ordination and management.
These problems have all been discussed before. But I can’t help but wishing that there was something obvious I’m missing.

How would you solve this knotty problem?

Performance and Innovation Are the Rewards of Digital Transformation

How does digital authentication work? And how can you implement it securely in your organisation?

How does Log4Shell works and what steps do you need to take?

Você quer acompanhar nosso conteúdo? Então siga nossa página no LinkedIn!