6 ms·

Since the advent of LetsEncrypt, ACME, and Caddy I haven't thought about SSL/TLS for more than about an hour per year, and that's only because I forget the step

Since the advent of LetsEncrypt, ACME, and Caddy I haven't thought about SSL/TLS for more than about an hour per year, and that's only because I forget the steps required to setup auto-renewal. I pay nothing, I spend a tiny amount of time dealing with it, and it works brilliantly. I'm not sure why many people are still dealing with legacy manual certificate renewal. Maybe some regulatory requirements? I even have a wildcard cert that covers my entire local network which is generated and deployed automatically by a cron job I wrote about 5 years ago. It's working perfectly and it would probably take me longer to track down exactly what it's doing than to re-write it from scratch. For 99.something% of use cases, this is a solved problem.

pelagicAustral 1y ago
I work for government and I can tell you the guys working infrastructure are still paying for shitty SSL certificates every year, in most cases for infrastructure that doesn't even see the light of day (internal), and the reason for that is none other that not knowing any better, and being unable to get their head out of their asses for enough time to learn something novel and implement it in their workflow. So yeah, there are those types out there in thew wild still.
- stego-tech 1y ago
  In our defense, it’s because we’re expected to give everything a cert but often have no say on the security and cryptography capabilities of what’s brought onto the network in the first place, nevermind the manpower and time to build such an automated solution internally. Execs bringing in MFPs that don’t support TLS, PLCs that require SHA-1, routers with a packet buffer measured in single-digit integers but with a Java web GUI, all of these horrors and more are why it’s such a shitshow even today. Just because someone’s homelab is fully cert’d through Caddy and LE that they slapped together over a weekend two years ago, doesn’t mean the process is trivial or easy for the masses. Believe me, I’ve been fighting this battle internally my entire career and I hate it. I hate the shitty state of PKI today, and how the sole focus seems to be public-facing web services instead of, y’know, the other 90% of a network’s devices and resources. PKI isn’t a solved problem.
  - stackskipton 1y ago
    It is solved but devices you are talking about refuse to get on board with the fix so here we are. Also, I used to do IT, I get it but what do you think the fix here is? You could also run your own CA that you push to all the devices and then you can cut certificates as long as you want.
    - Muromec 1y ago
      Where I am right now, if devices cant do what regulator and internal security asks, we find a new vendor.
  - znpy 1y ago
    Don't take this as a snarky comment, but that sounds quite literally as "skill issue". Not in you personally, but in the environment you work in. > PKI isn’t a solved problem. PKI is largely a solved issue nowadays. Software like Vault from hashicorp (it's FIPS compliant, too: https://developer.hashicorp.com/vault/docs/enterprise/fips https://developer.hashicorp.com/vault/docs/enterprise/fips) let you create a cryptographically-strong CA and build the automation you need. It's been out for years now, integrating the root CA shouldn't be much of an issue via group policies (in windows, there are equivalents for mac os and gnu/linux i guess). > Just because someone’s homelab is fully cert’d through Caddy and LE that they slapped together over a weekend two years ago, doesn’t mean the process is trivial or easy for the masses. Quite the contrary: it means that the process is technically so trivial the masses can do it in an afternoon and live off it for years with little to no maintenance. Hence, if a large organization is not able to implement that, the issue is in the organization, not in the technology.
    - ecb_penguin 1y ago
      > but that sounds quite literally as "skill issue". Not in you personally, but in the environment you work in. You have no idea the environment they work in. The "skill issue" here is you thinking your basic knowledge of Vault matters. > Software like Vault from hashicorp (it's FIPS compliant, too: https://developer.hashicorp.com/vault/docs/enterprise/fips https://developer.hashicorp.com/vault/docs/enterprise/fips) let you create a cryptographically-strong CA and build the automation you need. They didn't tell you their needs, but you're convinced this vendor product solves it. Are you a non-technical CTO by chance? > there are equivalents for mac os and gnu/linux i guess You guess? I'm sensing a skill issue. Why would you say it's solved for their environment, "I guess??" > Quite the contrary: it means that the process is technically so trivial the masses can do it in an afternoon and live off it for years with little to no maintenance. I'm sensing you work in a low skill environment if you think "home lab trivial" translates to enterprise and defense. > Hence, if a large organization is not able to implement that, the issue is in the organization, not in the technology. Absolutely meaningless statement.
- luma 1y ago
  Alternatively, those people are dealing with legacy systems that are pathologically resistant to cert automation (looking SQUARELY AT YOU vmware) and elect for the longest lasting certs they can get their hands on to minimize the disruption. It’s generally best to assume experts in other fields are doing things for good reasons, and if you don’t understand the reason it might be something other than them being dumb.
  - pelagicAustral 1y ago
    Yeah OK, touché, I was over the top... I just need my cup of coffee...
  - ruszki 1y ago
    Generally agree, that we shouldn’t jump on conclusions, but experts in my own field are doing bad things mainly because of lack of knowledge. With the lack of will as a very close contender for the top position. “The lack of possibility” is the exception. When I argued here that Linux is still pain to maintain on my laptops, it wasn’t because it’s not possible. I just didn’t have enough willpower. People who jumped on me because of this were still idiots, because they thought that their even less knowledge (what were the error messages, my exact setup, etc) can be helpful for me, but still it would be wrong to state that I was unsuccessful because it’s not possible, or I had full knowledge back then. Especially now, that I’m running Linux full time. For example, I’m quite sure that you can solve this problem with a proxy, no matter what’s behind it. Maybe it’s infeasible, because you would need a custom proxy implementation, but it’s definitely possible.
  - nickf 1y ago
    If there are systems that are that resistant to automation, the question should be 'does this system need a publicly-trusted server certificate, the same as a blog about cats or a Shopify shop?'. The answer is no. If it can't practically be automated, it near-certainly doesn't need to have a public cert on it.
o_m 1y ago
The older I get the more skeptical I get to free services that run on others servers. They have a bunch of expenses and you are getting it for free. You are not the customer. I rather pay for a service than gamble on some free service that might be shut down at any time, or that might have malicious intents.
- jraph 1y ago
  With you in general, but in this specific case, the whole thing seems healthy: - Many companies (including competitors) are sponsoring LE, so the funding should be quite robust - These companies are probably winning from the web being more secure, so the incentives are aligned with you (contrary to say, a company that offers something free but want to sink you under ads) - the vendor lock-in is very weak. The day LE goes awry, you can move to another CA pretty painlessly There are CAs supporting ACME that provide paid services as well.
- trenchpilgrim 1y ago
  There are paid ACME services - basically LE with paid support.
  - znpy 1y ago
    Yeah, one of those is https://zerossl.com/ https://zerossl.com/
- aitchnyu 1y ago
  Whats a LetsEncrypt competitor which has convenient automated renewal?
  - trenchpilgrim 1y ago
    Any that support ACME. Most of the big SSL companies do nowadays.
  - patrakov 1y ago
    ZeroSSL - they provide Sectigo certificates under the hood. Works well with Dehydrated.
stego-tech 1y ago
As someone on the other side of the fence who lives primarily in IT land, this is far from a solved problem. Not every device supports SSH for copying certs across the network, some devices have arbitrary requirements for the certs themselves (like timelines, lack of SANs, specific cryptography requirements, etc), and signing things internally (so that they’re only valid within the intranet, not on the internet) doesn’t work with LE at present. So unless you’re part of the folks fine heavily curating (or jailbreaking) devices to make the above possible, PKI is hardly a solved problem. If anything it remains a nightmare for orgs of all sizes. Even in BigCo at a major SV company, we had a dedicated team to manage PKI for internal certificates - complete with review board, justification documents, etc - and that still only bought us a manual process with a lead time of 72 hours for a cert. That said, it is measurably improved and I do think ACME/certbot/LE is on the right track here. Instead of constant bureaucratic revisioning of rules and standards documents, I believe the solution here is a sort of modern Wireguard-esque implementation of PKI and an associated certification program for vendors and devices. “Here’s the cert standard you have to accept, here’s the tool to automatically request and pin a certificate, here’s how that tool is configured for internal vs external PKI, and here’s the internal tooling standards projects that want to sign internal certs have to follow.” Basically an AD CA-alike for SMB and Enterprise both. Saves me time having to get into the nitty gritty of why some new printer/IoT/PLC doesn’t support a cert, and improves the posture of the wider industry.
- Shank 1y ago
  I feel like a lot of these requirements need to be really solved from first principles. What do you need these certificates for -- specifically, TLS certificates? If the biggest issue is "we want to encrypt traffic" then the answer really should be something more automated. To put it another way, TLS certificates used to convey a lot of things. We had basic certs that said "you are communicating with the rightful owner of domain example.com" and we had EV certs that said "you are communicating with the rightful legal entity Example Org, who happens to own example.com" and so-on and so-forth. But the thing is, we've killed off a lot of these certificate types. We don't have EV certs anymore. Let's Encrypt effectively democratized it to the point where you don't need to do any manual work for a normal "we want to encrypt data" certificate. I just don't understand what your specific requirements are, if they aren't directly "encrypt this traffic" focused, where you actually need valid certificates that work across the internet. Put differently, if you're running an internal CA, you can push out your own certificates via MDM tools and then not worry about this. If you aren't running your own CA but you're implementing all of this pomp and circumstances, what are you trying to solve? Do you really need all of this ceremony for all of your devices and applications?
deleted 1y ago
[deleted]
CamouflagedKiwi 1y ago
I've worked with a major financial institution (let's just say that you'd definitely recognise the name) in a past job, and while I couldn't really see exactly what was going on with the certs they issued, I'm sure it was a pretty manual process given our observations of things changing then reverting again later. I don't think regulation was really the issue though, just bad old processes. I wonder what they will do with the shorter validity periods. They aren't required to comply in the same way; it's not a great look not to but I can't believe the processes will scale (for them or their customers) to renewing an order of magnitude more frequently.
echelon 1y ago
I really hate the HTTPS requirement that Google unilaterally mandated for everyone. Just wait until SSL is used to prevent us from publishing anything. Your ID will have to be on file and be compliant. We've gone from really simple tools to tools that could easily be used to ensnare us and rid us of our rights. Encryption doesn't necessarily mean privacy. It can also mean control.
- kangs 1y ago
  it mainly means control these days. ive made SSL then later TLS requirements for web browsers and we had fights on this sort of stuff. yeah encryption is needed. but then you need authentication. and then, if authentication is controlled by corporations you're f'd. instead youd want identities to be distributed and owned by everyone. many trust models have been developed and other than raw UI problems (hi gpg/pgp) its really not a terrible UX.
- icedchai 1y ago
  Certs are free. All you need is a domain name and letsencrypt.
  - echelon 1y ago
    Slippery slope. Who controls the domain name system? Who controls how certs are handled by browsers and which ones are trusted? All of these things we take for granted can change. You're watching it happen right now.
    - ameliaquining 1y ago
      Isn't this problem already inherent to domain names, even without encryption? There's always a central authority that can take away your stuff, and always has been. (In theory you can solve this with a blockchain, but, well, gestures)
    - icedchai 1y ago
      The domain system needs at least some central control at the top, or it literally won't work. Do you remember the various "alternate root" projects in the 90's? I've stopped following them. The cert situation has vastly improved over the past 30 years. I remember paying $100's of dollars for certificates in the 90's, faxing in forms, etc.
evilduck 1y ago
For all but one of my personal use cases, Tailscale + Caddy have even automated away the setup steps and autorenewal of SSL with LetsEncrypt. Just toggle on the SSL features with `tailscale cert`, maybe point Caddy at the Tailscale socket file depending on your user setup, then point an upstream at the correct hostname and you're done.
holoduke 1y ago
Older Android 7 devices are not supported with letsencrypt. For us still 20% of our userbase. We went for a paid subscription with zerossl.
- Symbiote 1y ago
  That's six years obsolete, without security patches. What sector has 20% of users with that hardware?
  - ronsor 1y ago
    Half of all Android manufacturers suck, and many users are lazy to update, so if you target the platform, you always have to support a bunch of random old versions.
  - holoduke 1y ago
    Mainly people in southern America and a few Asian places.
- nickf 1y ago
  It's likely to get worse as CAs rotate roots more frequently. Cross-signing will work for a time (provided you correctly install) but at some point, older devices will drop out of support and that'll be it.
GuB-42 1y ago
And yet, I am a bit worried that now, most of the web depends on LetsEncrypt. That's a single point of failure. Sure, they are "good guys", really, but remember that Google used to be "good guys" too. And this is a US-based organization, dependent on US rules, which is not so bad, but alternatives would be nice. And yes, there are alternatives, but everything is made so that LetsEncrypt is the only reasonable choice. First, if you are not using https, you get shunned by every major web browser, you don't get the latest features, even those that has nothing to do with encryption (ex: brotli compression), downloads get blocked, etc... So you need https, good thing LetsEncrypt make it so easy, so you use LetsEncrypt. Because of the way LetsEncrypt verification works, you get short-term certificates, ok, fine. Other CAs do things differently, making it short-term certificates impractical, so your certificates last longer. But now, browsers are changing their requirements to only short-term certificate, but it is not a problem, just switch to LetsEncrypt, and it is free too. Also, X.509 certificates, which is the basis of https (incl. TLS, HTTP/3, ...) only supports a single signature, so I guess it is LetsEncrypt and nothing else.
- ameliaquining 1y ago
  How would you propose things should work instead?
  - GuB-42 1y ago
    The idea would be the ability for a certificate to accept multiple signatures, making it more of a "web-of-trust" system. So you still have your LetsEncrypt certificate, but maybe augmented by another signature from an similar authority located in another country, or some other reputable organization that has your best interests in mind. Maybe there are problems with that, but I never really understood the limit of a single signature for certificates. Is it because of bandwidth and performance requirements? Is it really a problem nowadays? especially with ECDSA making public keys much smaller.
    - ameliaquining 1y ago
      Does this solve any problem that isn't solved equally well by just acquiring multiple separate certificates? I guess it would make your service highly available in case of revocation, but unexpected revocations are rare enough that almost everyone is willing to run the risk of a brief outage in case one occurs.
electroly 1y ago
Lazy vendors. I know how to set up Let's Encrypt for web servers that I directly control, but some of the web servers are embedded in commercial vendor products. If this were just about people's directly-controlled nginx/caddy webservers this would be easy. We're not talking about homelabs here.
allan_s 1y ago
For regulatory requirements: yes ! I currently for EIDAS certificates, I can only choose a vouched certificate provider, and it's mostly somes that requires me to in person with my ID card with someone verifying the guy who made the CSR is actually me. The certificate is used for double SSL to authentify the server doing the request , i.e that the server doing an API call to the bank server is one I own. (I find it a pretty neat solution and much better than requiring to make a theater dance to get a token to renew every 3600 seconds )
- Muromec 1y ago
  Well, its eidas, ofc you need to show the id
  - allan_s 1y ago
    I know, it was to give example of why not every certificate can be "let's encrypt" and why some people still pay for certificate in 2025.
basscomm 1y ago
> Since the advent of LetsEncrypt, ACME, and Caddy I haven't thought about SSL/TLS for more than about an hour per year I run a couple of low-stakes websites just for fun and manually updating certificates takes me about 10 minutes a year, and most of that is remembering how to generate the csr. Setting up an automated process gains me nothing except additional points of failure. Ratcheting the expiration down to 47 days is an effort to force everyone to use automation, which makes no sense for small hobby sites. > I'm not sure why many people are still dealing with legacy manual certificate renewal Not everyone is a professional sysadmin. Adding automation is another layer of complexity on top of what it already takes to run a website. It's fine for large orgs and professionals who do this for a living at their day jobs, but for someone just getting their feet wet it's a ridiculous ask.
- roblabla 1y ago
  What's frankly ridiculous is that the big softwares like Nginx and Apache don't deal with this on their own. I've been letting Caddy (my http host of choice) deal with TLS for me for _ages_ now. I don't have to think about anything, I don't have to setup automation. I just... configure my caddy to host my website on https://my.domain.com https://my.domain.com and it just fetches the TLS for me, renews it when necessary, and uses it as necessary. You don't need to be a professional sysadmin to deal with this - so long as the software you use isn't ass. Nginx will _finally_ get this ability in the next release (and it'll still be more configuration than caddy, that just defaults to the sane thing)...
  - alanfranz 1y ago
    Nginx just added support for acme iirc.
  - fanf2 1y ago
    Apache has had mod_md since 2018 https://httpd.apache.org/docs/2.4/mod/mod_md.html https://httpd.apache.org/docs/2.4/mod/mod_md.html
    - znpy 1y ago
unethical_ban 1y ago
Having worked in IT, I assure you this is not a 99% implemented solution. Weird internal setups, dozens of proprietary or in-house sites, different verification needs for internal vs. external. And I'm speaking of the easier scenario of an internal CA.
TrueDuality 1y ago
Speaking as someone who has worked in tightly regulated environment, certificates are kind of a nasty problem and there are a couple of requirements that are in conflict for going to full automation of certificates. - Rotation of all certificates and authentication material must be renewed at regular intervals (no conflict here, this is the goal) - All infrastructure changes need to have the commands executed and contents of files inspected and approved in writing by the change control board before being applied to the environment That explicit approval of any changes being made within the environment go against these being automated in any way shape or form. These boards usually meet monthly or ad-hoc for time-sensitive security updates and usually have very long lists of changes to review causing the agenda to constantly overflow to the next meeting. You could probably still make it work as a priority standing agenda idea but its going to still involve manual process and review every month. I wouldn't want to manually rotate and approve certificates every month and many of these requirements have been signed into law (at least in the US). Starting to see another round of modernization initiatives so maybe in the next few years something could be done...
- ericpauley 1y ago
  It seems like the core problem here is that certificates are considered part of infrastructure, and further that they're part of infrastructure that requires approval! Clearly not all automated infrastructure requires approval: autoscaling groups spin up and tear down compute instances all the time. Further, changes to data can't universally require approval, otherwise every CRUD operation would require a committee meeting. Are certificates truly explicitly defined to be infrastructure that requires change approval? If not, perhaps more careful interpretation of the regulations could allow for improved automation and security outcomes.
  - syncsynchalt 1y ago
    > Clearly not all automated infrastructure requires approval: autoscaling groups spin up and tear down compute instances all the time. In these sort of environments, they do not. We're talking about environments where it is forbidden to make _any_ change of any kind without a CCB ticket. Short cert lifetimes are fundamentally at odds with this. Luckily these systems often aren't public and don't need public certs, but there's a slice of them that do.
gchamonlive 1y ago
I think part of this can be explained by the fact that in many corporations, code and everything supporting it, like development time, developer quality, infrastructure maintenance and software architecture aren't seen as investiment but sunk cost that needs to be reduced ad infinitum to appease shareholders, so they throw human suffering and business risk at it to make it look good in the next quarterly report.
jtbayly 1y ago
One example is FreePBX, which supposedly supports automated SSL renewal via LetsEncrypt, but constantly overwrites the config, thus breaking the “auto.” So I have to manually renew the cert, or I have to upgrade (ie rebuild the whole system from scratch, including installing the OS) to the next major version of FreePBX and hope they fixed the issue. So I’m really not excited about the time limit dropping from 90 days to 47 days.

pelagicAustral 1y ago

I work for government and I can tell you the guys working infrastructure are still paying for shitty SSL certificates every year, in most cases for infrastructure that doesn't even see the light of day (internal), and the reason for that is none other that not knowing any better, and being unable to get their head out of their asses for enough time to learn something novel and implement it in their workflow. So yeah, there are those types out there in thew wild still.

stego-tech 1y ago
In our defense, it’s because we’re expected to give everything a cert but often have no say on the security and cryptography capabilities of what’s brought onto the network in the first place, nevermind the manpower and time to build such an automated solution internally. Execs bringing in MFPs that don’t support TLS, PLCs that require SHA-1, routers with a packet buffer measured in single-digit integers but with a Java web GUI, all of these horrors and more are why it’s such a shitshow even today. Just because someone’s homelab is fully cert’d through Caddy and LE that they slapped together over a weekend two years ago, doesn’t mean the process is trivial or easy for the masses. Believe me, I’ve been fighting this battle internally my entire career and I hate it. I hate the shitty state of PKI today, and how the sole focus seems to be public-facing web services instead of, y’know, the other 90% of a network’s devices and resources. PKI isn’t a solved problem.
- stackskipton 1y ago
  It is solved but devices you are talking about refuse to get on board with the fix so here we are. Also, I used to do IT, I get it but what do you think the fix here is? You could also run your own CA that you push to all the devices and then you can cut certificates as long as you want.
  - Muromec 1y ago
    Where I am right now, if devices cant do what regulator and internal security asks, we find a new vendor.
- znpy 1y ago
  Don't take this as a snarky comment, but that sounds quite literally as "skill issue". Not in you personally, but in the environment you work in. > PKI isn’t a solved problem. PKI is largely a solved issue nowadays. Software like Vault from hashicorp (it's FIPS compliant, too: https://developer.hashicorp.com/vault/docs/enterprise/fips https://developer.hashicorp.com/vault/docs/enterprise/fips) let you create a cryptographically-strong CA and build the automation you need. It's been out for years now, integrating the root CA shouldn't be much of an issue via group policies (in windows, there are equivalents for mac os and gnu/linux i guess). > Just because someone’s homelab is fully cert’d through Caddy and LE that they slapped together over a weekend two years ago, doesn’t mean the process is trivial or easy for the masses. Quite the contrary: it means that the process is technically so trivial the masses can do it in an afternoon and live off it for years with little to no maintenance. Hence, if a large organization is not able to implement that, the issue is in the organization, not in the technology.
  - ecb_penguin 1y ago
    > but that sounds quite literally as "skill issue". Not in you personally, but in the environment you work in. You have no idea the environment they work in. The "skill issue" here is you thinking your basic knowledge of Vault matters. > Software like Vault from hashicorp (it's FIPS compliant, too: https://developer.hashicorp.com/vault/docs/enterprise/fips https://developer.hashicorp.com/vault/docs/enterprise/fips) let you create a cryptographically-strong CA and build the automation you need. They didn't tell you their needs, but you're convinced this vendor product solves it. Are you a non-technical CTO by chance? > there are equivalents for mac os and gnu/linux i guess You guess? I'm sensing a skill issue. Why would you say it's solved for their environment, "I guess??" > Quite the contrary: it means that the process is technically so trivial the masses can do it in an afternoon and live off it for years with little to no maintenance. I'm sensing you work in a low skill environment if you think "home lab trivial" translates to enterprise and defense. > Hence, if a large organization is not able to implement that, the issue is in the organization, not in the technology. Absolutely meaningless statement.
luma 1y ago
Alternatively, those people are dealing with legacy systems that are pathologically resistant to cert automation (looking SQUARELY AT YOU vmware) and elect for the longest lasting certs they can get their hands on to minimize the disruption. It’s generally best to assume experts in other fields are doing things for good reasons, and if you don’t understand the reason it might be something other than them being dumb.
- pelagicAustral 1y ago
  Yeah OK, touché, I was over the top... I just need my cup of coffee...
- ruszki 1y ago
  Generally agree, that we shouldn’t jump on conclusions, but experts in my own field are doing bad things mainly because of lack of knowledge. With the lack of will as a very close contender for the top position. “The lack of possibility” is the exception. When I argued here that Linux is still pain to maintain on my laptops, it wasn’t because it’s not possible. I just didn’t have enough willpower. People who jumped on me because of this were still idiots, because they thought that their even less knowledge (what were the error messages, my exact setup, etc) can be helpful for me, but still it would be wrong to state that I was unsuccessful because it’s not possible, or I had full knowledge back then. Especially now, that I’m running Linux full time. For example, I’m quite sure that you can solve this problem with a proxy, no matter what’s behind it. Maybe it’s infeasible, because you would need a custom proxy implementation, but it’s definitely possible.
- nickf 1y ago
  If there are systems that are that resistant to automation, the question should be 'does this system need a publicly-trusted server certificate, the same as a blog about cats or a Shopify shop?'. The answer is no. If it can't practically be automated, it near-certainly doesn't need to have a public cert on it.

o_m 1y ago

The older I get the more skeptical I get to free services that run on others servers. They have a bunch of expenses and you are getting it for free. You are not the customer. I rather pay for a service than gamble on some free service that might be shut down at any time, or that might have malicious intents.

jraph 1y ago
With you in general, but in this specific case, the whole thing seems healthy: - Many companies (including competitors) are sponsoring LE, so the funding should be quite robust - These companies are probably winning from the web being more secure, so the incentives are aligned with you (contrary to say, a company that offers something free but want to sink you under ads) - the vendor lock-in is very weak. The day LE goes awry, you can move to another CA pretty painlessly There are CAs supporting ACME that provide paid services as well.
trenchpilgrim 1y ago
There are paid ACME services - basically LE with paid support.
- znpy 1y ago
  Yeah, one of those is https://zerossl.com/ https://zerossl.com/
aitchnyu 1y ago
Whats a LetsEncrypt competitor which has convenient automated renewal?
- trenchpilgrim 1y ago
  Any that support ACME. Most of the big SSL companies do nowadays.
- patrakov 1y ago
  ZeroSSL - they provide Sectigo certificates under the hood. Works well with Dehydrated.

stego-tech 1y ago

As someone on the other side of the fence who lives primarily in IT land, this is far from a solved problem. Not every device supports SSH for copying certs across the network, some devices have arbitrary requirements for the certs themselves (like timelines, lack of SANs, specific cryptography requirements, etc), and signing things internally (so that they’re only valid within the intranet, not on the internet) doesn’t work with LE at present. So unless you’re part of the folks fine heavily curating (or jailbreaking) devices to make the above possible, PKI is hardly a solved problem. If anything it remains a nightmare for orgs of all sizes. Even in BigCo at a major SV company, we had a dedicated team to manage PKI for internal certificates - complete with review board, justification documents, etc - and that still only bought us a manual process with a lead time of 72 hours for a cert. That said, it is measurably improved and I do think ACME/certbot/LE is on the right track here. Instead of constant bureaucratic revisioning of rules and standards documents, I believe the solution here is a sort of modern Wireguard-esque implementation of PKI and an associated certification program for vendors and devices. “Here’s the cert standard you have to accept, here’s the tool to automatically request and pin a certificate, here’s how that tool is configured for internal vs external PKI, and here’s the internal tooling standards projects that want to sign internal certs have to follow.” Basically an AD CA-alike for SMB and Enterprise both. Saves me time having to get into the nitty gritty of why some new printer/IoT/PLC doesn’t support a cert, and improves the posture of the wider industry.

Shank 1y ago
I feel like a lot of these requirements need to be really solved from first principles. What do you need these certificates for -- specifically, TLS certificates? If the biggest issue is "we want to encrypt traffic" then the answer really should be something more automated. To put it another way, TLS certificates used to convey a lot of things. We had basic certs that said "you are communicating with the rightful owner of domain example.com" and we had EV certs that said "you are communicating with the rightful legal entity Example Org, who happens to own example.com" and so-on and so-forth. But the thing is, we've killed off a lot of these certificate types. We don't have EV certs anymore. Let's Encrypt effectively democratized it to the point where you don't need to do any manual work for a normal "we want to encrypt data" certificate. I just don't understand what your specific requirements are, if they aren't directly "encrypt this traffic" focused, where you actually need valid certificates that work across the internet. Put differently, if you're running an internal CA, you can push out your own certificates via MDM tools and then not worry about this. If you aren't running your own CA but you're implementing all of this pomp and circumstances, what are you trying to solve? Do you really need all of this ceremony for all of your devices and applications?

deleted 1y ago

[deleted]

CamouflagedKiwi 1y ago

I've worked with a major financial institution (let's just say that you'd definitely recognise the name) in a past job, and while I couldn't really see exactly what was going on with the certs they issued, I'm sure it was a pretty manual process given our observations of things changing then reverting again later. I don't think regulation was really the issue though, just bad old processes. I wonder what they will do with the shorter validity periods. They aren't required to comply in the same way; it's not a great look not to but I can't believe the processes will scale (for them or their customers) to renewing an order of magnitude more frequently.

echelon 1y ago

I really hate the HTTPS requirement that Google unilaterally mandated for everyone. Just wait until SSL is used to prevent us from publishing anything. Your ID will have to be on file and be compliant. We've gone from really simple tools to tools that could easily be used to ensnare us and rid us of our rights. Encryption doesn't necessarily mean privacy. It can also mean control.

kangs 1y ago
it mainly means control these days. ive made SSL then later TLS requirements for web browsers and we had fights on this sort of stuff. yeah encryption is needed. but then you need authentication. and then, if authentication is controlled by corporations you're f'd. instead youd want identities to be distributed and owned by everyone. many trust models have been developed and other than raw UI problems (hi gpg/pgp) its really not a terrible UX.
icedchai 1y ago
Certs are free. All you need is a domain name and letsencrypt.
- echelon 1y ago
  Slippery slope. Who controls the domain name system? Who controls how certs are handled by browsers and which ones are trusted? All of these things we take for granted can change. You're watching it happen right now.
  - ameliaquining 1y ago
    Isn't this problem already inherent to domain names, even without encryption? There's always a central authority that can take away your stuff, and always has been. (In theory you can solve this with a blockchain, but, well, gestures)
  - icedchai 1y ago
    The domain system needs at least some central control at the top, or it literally won't work. Do you remember the various "alternate root" projects in the 90's? I've stopped following them. The cert situation has vastly improved over the past 30 years. I remember paying $100's of dollars for certificates in the 90's, faxing in forms, etc.

evilduck 1y ago

For all but one of my personal use cases, Tailscale + Caddy have even automated away the setup steps and autorenewal of SSL with LetsEncrypt. Just toggle on the SSL features with `tailscale cert`, maybe point Caddy at the Tailscale socket file depending on your user setup, then point an upstream at the correct hostname and you're done.

holoduke 1y ago

Older Android 7 devices are not supported with letsencrypt. For us still 20% of our userbase. We went for a paid subscription with zerossl.

Symbiote 1y ago
That's six years obsolete, without security patches. What sector has 20% of users with that hardware?
- ronsor 1y ago
  Half of all Android manufacturers suck, and many users are lazy to update, so if you target the platform, you always have to support a bunch of random old versions.
- holoduke 1y ago
  Mainly people in southern America and a few Asian places.
nickf 1y ago
It's likely to get worse as CAs rotate roots more frequently. Cross-signing will work for a time (provided you correctly install) but at some point, older devices will drop out of support and that'll be it.

GuB-42 1y ago

And yet, I am a bit worried that now, most of the web depends on LetsEncrypt. That's a single point of failure. Sure, they are "good guys", really, but remember that Google used to be "good guys" too. And this is a US-based organization, dependent on US rules, which is not so bad, but alternatives would be nice. And yes, there are alternatives, but everything is made so that LetsEncrypt is the only reasonable choice. First, if you are not using https, you get shunned by every major web browser, you don't get the latest features, even those that has nothing to do with encryption (ex: brotli compression), downloads get blocked, etc... So you need https, good thing LetsEncrypt make it so easy, so you use LetsEncrypt. Because of the way LetsEncrypt verification works, you get short-term certificates, ok, fine. Other CAs do things differently, making it short-term certificates impractical, so your certificates last longer. But now, browsers are changing their requirements to only short-term certificate, but it is not a problem, just switch to LetsEncrypt, and it is free too. Also, X.509 certificates, which is the basis of https (incl. TLS, HTTP/3, ...) only supports a single signature, so I guess it is LetsEncrypt and nothing else.

ameliaquining 1y ago
How would you propose things should work instead?
- GuB-42 1y ago
  The idea would be the ability for a certificate to accept multiple signatures, making it more of a "web-of-trust" system. So you still have your LetsEncrypt certificate, but maybe augmented by another signature from an similar authority located in another country, or some other reputable organization that has your best interests in mind. Maybe there are problems with that, but I never really understood the limit of a single signature for certificates. Is it because of bandwidth and performance requirements? Is it really a problem nowadays? especially with ECDSA making public keys much smaller.
  - ameliaquining 1y ago
    Does this solve any problem that isn't solved equally well by just acquiring multiple separate certificates? I guess it would make your service highly available in case of revocation, but unexpected revocations are rare enough that almost everyone is willing to run the risk of a brief outage in case one occurs.

electroly 1y ago

Lazy vendors. I know how to set up Let's Encrypt for web servers that I directly control, but some of the web servers are embedded in commercial vendor products. If this were just about people's directly-controlled nginx/caddy webservers this would be easy. We're not talking about homelabs here.

allan_s 1y ago

For regulatory requirements: yes ! I currently for EIDAS certificates, I can only choose a vouched certificate provider, and it's mostly somes that requires me to in person with my ID card with someone verifying the guy who made the CSR is actually me. The certificate is used for double SSL to authentify the server doing the request , i.e that the server doing an API call to the bank server is one I own. (I find it a pretty neat solution and much better than requiring to make a theater dance to get a token to renew every 3600 seconds )

Muromec 1y ago
Well, its eidas, ofc you need to show the id
- allan_s 1y ago
  I know, it was to give example of why not every certificate can be "let's encrypt" and why some people still pay for certificate in 2025.

basscomm 1y ago

> Since the advent of LetsEncrypt, ACME, and Caddy I haven't thought about SSL/TLS for more than about an hour per year I run a couple of low-stakes websites just for fun and manually updating certificates takes me about 10 minutes a year, and most of that is remembering how to generate the csr. Setting up an automated process gains me nothing except additional points of failure. Ratcheting the expiration down to 47 days is an effort to force everyone to use automation, which makes no sense for small hobby sites. > I'm not sure why many people are still dealing with legacy manual certificate renewal Not everyone is a professional sysadmin. Adding automation is another layer of complexity on top of what it already takes to run a website. It's fine for large orgs and professionals who do this for a living at their day jobs, but for someone just getting their feet wet it's a ridiculous ask.

roblabla 1y ago
What's frankly ridiculous is that the big softwares like Nginx and Apache don't deal with this on their own. I've been letting Caddy (my http host of choice) deal with TLS for me for _ages_ now. I don't have to think about anything, I don't have to setup automation. I just... configure my caddy to host my website on https://my.domain.com https://my.domain.com and it just fetches the TLS for me, renews it when necessary, and uses it as necessary. You don't need to be a professional sysadmin to deal with this - so long as the software you use isn't ass. Nginx will _finally_ get this ability in the next release (and it'll still be more configuration than caddy, that just defaults to the sane thing)...
- alanfranz 1y ago
  Nginx just added support for acme iirc.
- fanf2 1y ago
  Apache has had mod_md since 2018 https://httpd.apache.org/docs/2.4/mod/mod_md.html https://httpd.apache.org/docs/2.4/mod/mod_md.html
  - znpy 1y ago

unethical_ban 1y ago

Having worked in IT, I assure you this is not a 99% implemented solution. Weird internal setups, dozens of proprietary or in-house sites, different verification needs for internal vs. external. And I'm speaking of the easier scenario of an internal CA.

TrueDuality 1y ago

Speaking as someone who has worked in tightly regulated environment, certificates are kind of a nasty problem and there are a couple of requirements that are in conflict for going to full automation of certificates. - Rotation of all certificates and authentication material must be renewed at regular intervals (no conflict here, this is the goal) - All infrastructure changes need to have the commands executed and contents of files inspected and approved in writing by the change control board before being applied to the environment That explicit approval of any changes being made within the environment go against these being automated in any way shape or form. These boards usually meet monthly or ad-hoc for time-sensitive security updates and usually have very long lists of changes to review causing the agenda to constantly overflow to the next meeting. You could probably still make it work as a priority standing agenda idea but its going to still involve manual process and review every month. I wouldn't want to manually rotate and approve certificates every month and many of these requirements have been signed into law (at least in the US). Starting to see another round of modernization initiatives so maybe in the next few years something could be done...

ericpauley 1y ago
It seems like the core problem here is that certificates are considered part of infrastructure, and further that they're part of infrastructure that requires approval! Clearly not all automated infrastructure requires approval: autoscaling groups spin up and tear down compute instances all the time. Further, changes to data can't universally require approval, otherwise every CRUD operation would require a committee meeting. Are certificates truly explicitly defined to be infrastructure that requires change approval? If not, perhaps more careful interpretation of the regulations could allow for improved automation and security outcomes.
- syncsynchalt 1y ago
  > Clearly not all automated infrastructure requires approval: autoscaling groups spin up and tear down compute instances all the time. In these sort of environments, they do not. We're talking about environments where it is forbidden to make _any_ change of any kind without a CCB ticket. Short cert lifetimes are fundamentally at odds with this. Luckily these systems often aren't public and don't need public certs, but there's a slice of them that do.

gchamonlive 1y ago

I think part of this can be explained by the fact that in many corporations, code and everything supporting it, like development time, developer quality, infrastructure maintenance and software architecture aren't seen as investiment but sunk cost that needs to be reduced ad infinitum to appease shareholders, so they throw human suffering and business risk at it to make it look good in the next quarterly report.

jtbayly 1y ago

One example is FreePBX, which supposedly supports automated SSL renewal via LetsEncrypt, but constantly overwrites the config, thus breaking the “auto.” So I have to manually renew the cert, or I have to upgrade (ie rebuild the whole system from scratch, including installing the OS) to the next major version of FreePBX and hope they fixed the issue. So I’m really not excited about the time limit dropping from 90 days to 47 days.