Web browser based ACME clients

Client dev
1

:warning: This post is outdated. Especially, ZeroSSL is not the same product as before.

Summary:

My personal opinion is: Avoid using Websites to generate your certificate, but, if you really have to:

Let's Encrypt published a few days ago a new policy about Web browser based clients: client-options: document inclusion/update policy. by cpu · Pull Request #377 · letsencrypt/website · GitHub

Some in-browser ACME clients are available, but we do not list them here because they encourage a manual renewal workflow that results in a poor user experience and increases the risk of missed renewals.

I understand the rationale behind that decision. Of course automation must be encouraged.

But sometimes people need to generate a certificate in a hurry, and some of them are not tech savvy. These situations are common; it may be the loss of the person administering the system for example.

When their certificates are about to expires (or already did) they need to solve the problem quickly. After that they can concentrate on a better process (hire somebody, automate the renewal, etc…) and they will have three month for that.

In some case they don't have a server available to run command lines to generate a CSR or execute a client. They just needs the certificates files (private key, certificate and chain), to upload them.

It's important that people in these situations are guided and aware of the risks.

Risks using a web browser based client:

  • You need to trust them because

  • They can generate a certificate for your website up to 30 days after you used their tools

  • They can revoque the certificate because they control the ACME account used to generate them

  • They can decrypt your traffic by keeping the private key they have generated for you if they are able to intercept the encrypted traffic (avoidable by generating a csr offline)

The clients listed on ACME Client Implementations - Let's Encrypt were:

And these were asking for inclusion:

I analyzed two points about them:

  • If the person/company behind it is anonym or if their contact information are available

  • If the basic security measures are taken

Analysis of the clients:

Contact available: Yes (but not easily accessible)
HSTS: Yes with preload
Security headers: No (but probably irrelevant here)
External requests: No
Https configuration: Good

Contact available: partially
HSTS: Yes with preload
Security headers: Some (but probably irrelevant here)
External requests: No
Https configuration: Good

Contact available: Yes
HSTS: yes without preload
Security headers: Some
External requests: Few
Https configuration: Good

contact available: No
HSTS: No
Security Headers: No
External requests: yes
Https configuration: bad

Contact available: No
HSTS: Yes without preload
Security headers:No
External requests:No
Https configuration: Bad

Not loading?

http://web.archive.org/web/20180516030727/https://uglyssl.com/

https://webcache.googleusercontent.com/search?q=cache:https://uglyssl.com/legal.html

Contact available: No
HSTS: No
security headers: No
External requests: Few
Https configuration: Good

Contact available: Yes
External requests: Few
HSTS: Yes with preload pending inclusion
Security headers: Some
Https configuration: Good

(Configuration improved since Please add FreeSSL.tech in-browser ACME V2 client by speed-up-website · Pull Request #374 · letsencrypt/website · GitHub )

That analyst shows that the security of these clients can vary a lot, and even with the best security, the question of trust is unavoidable.

The only solution I see to helps people that need to generate easily a certificate in an emergency case would be a let’s encrypt hosted web based client. That idea was already posted two years ago: Certificates from letsencrypt website without a client

Such solution would:

  • Allow Let’s Encrypt to promote automation with a clear message on that page

  • Completely solve the trust problem

  • Would have no security risk, for Let’s Encrypt nor the users

  • Would have no overhead on Let’s Encrypt server as the client could be 100% javascript

The drawbacks of that solution would be

  • The maintenance of such tool, but it could be done by the community

  • The overhead due to the creation of throwaway ACME accounts, but it already happened with others web based clients

Thoughts?

3 Likes
2

Missing point:

  • Offering such a solution would be directly contrary to Let's Encrypt's dedication to an automated system. No matter how clearly they word the message on that page, the message is weakened when they themselves provide the tool to avoid it.

The fundamental problem, I think, is that those people for whom the web-based clients are a good solution for an "emergency", really shouldn't be using LE in the first place. LE works very well if you actually administer your own servers. It works well if your infrastructure is hosted, and your host supports the necessary automation (as a great many do). It does not work well when your host does not support the necessary automation, and I think the docs need to be updated to make this explicit. In those cases, your best course of action is either to use a different hosting provider, or use a different CA.

1 Like
3

I don't see how "Automation is important, but in case of emergency we give you this tools" weakens "Automation is important".

I disagree. Everybody, one day or another, could be in that situation.

Yes. Until you can't do it. A few times ago, I remember a post "My husband died". (not linking to avoid notification to that person)

Yes. Until you need to change your hosting provider (account blocked, bankruptcy, ...) and it could happen without warning.

Everything was working, you contracted a company to ensure that. Now they let you down. Of course you will find a solution (contract another company, go to a hosting provider that ensure automatic renewal) but right now, you need to renew your certificate.

Not everybody has that option. Most CA asks for money, and not every small company in all countries can afford it.

And not everybody is teck-savy. So in their situation, what will you do? Pay $$$ or just use that simple website that generate certificates, without understanding the security implications ? And, they may do both: pay a website that has no additional value to generate Let's encrypt certificates for them.

Let's remember Let's Encrypt Principles: About Let's Encrypt - Let's Encrypt :

Free, Automatic, Secure, Transparent, Open, Cooperative.

Options:

  • Let's Encrypt hosted web based client:
    Free, Secure, Transparent, Open, Cooperative and can advertise for Automatic
  • Other hosted web based client: Maybe no free, not automatic, maybe not secure, probably not transparent, not necessarily open and less cooperative.
  • Different CA: Maybe no free, possibly automatic, probably not transparent, not necessarily open and less cooperative. But probably secure.

Yes, automation is important, and we should push for it. But other principle are important too.

And every sysadmin who generated a Let's Encrypt certificate the first time did it manually. They had to run the certbot command, to install the automation.

4

Hi @tdelmas! Thanks for raising this, and sorry it’s taken a couple of days to reply. Your detailed analysis of the properties various web clients is especially cool and informative.

We’ve definitely thought about the possibility of an official Let’s Encrypt web-based client to decrease the risks involved in people trusting third parties to perform domain validation for them. But our feeling so far has been that it would be a moderate amount of work that takes away from other things we want to do, and that it doesn’t further our goals of making HTTPS easier for everyone.

I think in most “emergency” cases, the availability of a web based client doesn’t actually mitigate them very much. For instance, in the “husband died” thread (thanks for pointing that out, I’d missed it), the main stumbling block was not actually getting the certificate, but finding the SSH keys to log in to the server. Similarly, in the cases you mentioned where your hosting provider blocked your account or went bankrupt, you would have the bigger problem that your site is not hosted anywhere, making it hard to perform domain validation or upload a certificate once you did. The next step would be to pick a new hosting provider, and if HTTPS is important to you, presumably you would choose the next provider with an eye towards automated HTTPS support.

2 Likes
5

Thanks

That's a perfectly valid reason.

And thank you for that detailed answer!

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

7

Related, about the risk of using web based client to generate keys: https://www.europol.europa.eu/newsroom/news/cryptocurrency-iota-international-police-cooperation-arrests-suspect-behind-10-million-eur-theft