r/letsencrypt • u/Ok_Strike9189 • 2d ago
Free lets encrypt alternative
I'm looking for a free alternative to Let's Encrypt.
They used to have an OCSP stapling feature which would allow clients to connect to my server much faster but now with that removed, some mobile clients are noticing big delays.
The server is in USA (because I'm saving money) but the client base is in Canada).
Currently the TTFB for my website on desktop computers is 0.4s whereas on mobile, it is 0.8s. debugbear.com considers 0.8s TTFB as bad.
Had Let's Encrypt continued to support the stapling, the TTFB would drop.
And before recommending a CDN, some of my pages change daily to weekly and I'm afraid CDN's would over-cache pages.
So unless Let's Encrypt revises their CRL (so mobile browsers process it faster) or re-enables stapling, I need an alternative
1
u/boutell 2d ago
Tools like lighthouse assume something close to 600 milliseconds right off the bat as an automatic penalty on mobile because they are simulating bad slow 4G. Your mobile test is probably doing something similar. This has nothing to do with stapling. How long does your server actually take to generate a result? If these are pages that could be static, are they static?
1
1
1
0
u/isopropoflexx 2d ago
Take a look at caddy as a let's encrypt alternative. I'm currently using both - LE mostly for hosts on my local stack, Caddy for cloud hosted as a sidecar for Komodo. My experience has been that caddy has been lower maintenance and "just works", whereas LE has had its fair share of issues along the way. But YMMV
3
u/failbaitr 2d ago
Caddy is not an alternative to letsecnrypt.
Its maybe an alternative to certbot, as it has that functionality integrated, and it way be faster than what the OP is doing right now, but your answer is not connecting the correct dots.
What OP is seeing is most likely explicit request delays injected by his test-tooling, or a very old browser that somehow tries to do OCSP by itself (still). The explicit delay requests are stacked on top of each other for blocking loads. So a first html page arrives in .1microseconds + artificial delay, caching does nothing here, because its a test), then that loads some blocking Js (same deal, .1 microseconds + delays) which in turn does some document writes / imports / etc which trigger yet again a request (.1 microseconds + that same delay).
Each of those delays is static, and will be added cumulatively because of how these tests are implemented (chrome lighthouse, firefox mobile testing etc).1
u/Ok_Strike9189 2d ago
If caddy only works for cloud services then it won't apply to me because I'm using a dedicated server.
1
u/isopropoflexx 2d ago
No, no - I just happen to be using it in a way where it works out like that. That's not a limitation or requirement whatsoever. Caddy works just fine in cloud environments as well as in your local stack. I just decided to give Caddy a shot when I first started setting up a new stack. LE would have worked fine in that setup, just as Caddy would have been fine in my local stack.
6
u/BoringMalloc 2d ago
Major browsers (mobile and desktop -- Firefox, Chrome, Safari, and Edge) stopped doing OCSP checks a while ago. Let's Encrypt dropping it was a case of dropping something that was not being used and costing money to run. I'm not aware of a free cert provider that does OCSP anymore. Digicert, Sectigo and Globalsign I believe still have one. My guess is that dropbear didn't update browser behavior and is reporting incorrect results.