9 ms·

SSL certificate requirements are becoming obnoxious

• FergusArgyll 1y ago
  sudo certbot --nginx
• duxjcjig 1y ago
  [flagged]
• gdbsjjdn 1y ago
  I understand OP's frustration, but the alternate view is that mandating better practices is a forcing function for businesses that otherwise don't give a shit about users or their privacy or security. For all the annoyance of SOC2 audits, it sure does make my manager actually spend time and money on following the rules. Without any kind of external pressure I (as a security-minded engineer) would struggle to convince senior leadership that anything matters beyond shipping features.
  • Jeslijar 1y ago
    Why is a month's expiration better than a year or two years? Why wouldn't you go with a week or a day? isn't that better than a whole month? Why isn't it instead just a minute? or a few seconds? Wouldn't that be better? Why not have certificates dynamically generated constantly and have it so every single request is serviced by a new one and then destroyed after the session is over? Maybe the problem isn't that certificates expire too soon, maybe the problem is that humans are lazy. Perhaps it's time to go with another method entirely.
    • bananapub 1y ago
      dunno why you're being so obnoxious about it? a month is better than a year because we never ever ever managed to make revocation work, and so the only thing we can do is reduce the length of certs so that stolen or fraudulently obtained certs can be used for less time.
      • naasking 1y ago
        On the vulnerability ladder since SSL was introduced, how common and how disastrous have stolen or fraudulent certs really compared to other security problems, and by how much will these changes reduce such disasters?
        • FuriouslyAdrift 1y ago
          China currently has a large APT campaign using a comprised CA (Billbug). https://www.darkreading.com/endpoint-security/china-based-billbug-apt-infiltrates-certificate-authority https://www.darkreading.com/endpoint-security/china-based-bi...
          • naasking 1y ago
            I agree with the article, this is "potentially very dangerous". Potential is not actual though, and I'm asking about what damage has actually materialized. Is there a cost estimate over the past 20 years vs. say, memory safety vulnerabilities?
        • capitol_ 1y ago
          Is this some sort of troll comment? I'm sure that you are perfectly able to do your own research, why are you trying to push that work onto some stranger on the internet?
          • naasking 1y ago
            Is this a troll article? The article asked basically the same question: I also wonder how many organizations have had certificates mis-issued due to BGP hijacking. Yes, this will improve the warm fuzzy security feeling we all want at night, but how much actual risk is this requirement mitigating? Scope creep with diminishing returns happens everywhere.
    • nisegami 1y ago
      Every year is too infrequent to force automation, leading to admins forgetting to renew their certs. Every minute/day may be too demanding on ACME providers and clutters transparency logs. Dynamic certs just move the problem around because whatever is signing those certs just becomes the SSL cert in practice unless it happens over acme in which case see the point above.
    • yjftsjthsd-h 1y ago
      > Why wouldn't you go with a week or a day? isn't that better than a whole month? There is in fact work on making this an option: https://letsencrypt.org/2025/02/20/first-short-lived-cert-issued https://letsencrypt.org/2025/02/20/first-short-lived-cert-is... > Why isn't it instead just a minute? or a few seconds? Wouldn't that be better? > Why not have certificates dynamically generated constantly and have it so every single request is serviced by a new one and then destroyed after the session is over? Eventually the overhead actually does start to matter > Maybe the problem isn't that certificates expire too soon, maybe the problem is that humans are lazy. Perhaps it's time to go with another method entirely. Like what?
    • allan_s 1y ago
      I think it's all about change management a whole month put you in the "if you don't have the resource to automate it, it's still doable by a human, not enough to crush somebody, but still enough to make the option , let's automate fully something to consider" hence why it's better than a week or a day (it's too much pressure for small companies) better than hours/minutes/secondes (it means you go from 1 year to 'now it must be fully automated right now ! ) a year or two years was not a good idea, because you loose knowledge, it creates pressure (oh my.... not the scary yearly certificate renewal, i remember last year we broke something, we i don't remember what...) A month, you either start to fully document it, or at least to have it fresh in your mind. A month give you time to everytime think "ok, we have 30 certicates, can't we have a wild card, or a certificate with several domain in it?" > Perhaps it's time to go with another method entirely. I think that's the way forward, it's just that it will not happen in one step, and going to one month is a first step. source: We have to manage a lot of certificate for a lot of different use cases (ssh, mutual ssl for authentification, classical HTTPS certificate etc. ) and we learned the hard way that no 2 years is not better than 1 , and I agree that one month would be better also https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days https://www.digicert.com/blog/tls-certificate-lifetimes-will...
      • belval 1y ago
        > it creates pressure (oh my.... not the scary yearly certificate renewal, i remember last year we broke something, we i don't remember what...) Ah yes, let's make a terrible workflow to externally force companies who can't be arsed to document their processes to do things properly, at the expense of everyone else.
        • hombre_fatal 1y ago
          But it's a decent trade-off and you're using sarcasm in place of fleshing out your claim. Monthly expiration is a simple way to force you to automate something. Everyone benefits from automating it, too.
      • ameliaquining 1y ago
        I think the less conservative stakeholders here would honestly rather do the six-day thing. They don't view the "still doable by a human" thing as a feature; they'd rather everyone think of certificate management as something that has to be fully automated, much like how humans don't manually respond to HTTP requests. Of course, the idea is not to make every tiny organization come up with a bespoke automation solution; rather, it's to make everyone who writes web server software designed to be exposed to the public internet think of certificate management as included within the scope of problems that are their responsibility to solve, through ACME integration or similar. There isn't any reason in principle why this wouldn't work, and I don't think there'd have been a lot of objections if it had worked this way from the beginning; resistance is coming primarily from stakeholders who don't ever want to change anything as they view it as a pure cost. (Why not less than six days? Because I think at that point you might start to face some availability tradeoffs even if everything is always fully automated.)
    • yladiz 1y ago
      I'm not sure if you're arguing in good faith, but assuming you are, it should be pretty self-evident why you wouldn't generate the certificate dynamically each request: it would take too much time to do so, and so every request would be substantially slower, probably as slow as using Tor, since you would need to ask for the certificate from a central authority. In general it's all about balance, 1 month isn't necessarily better than 1 year, but the reduced timeframe means that there's less complexity in keeping some renovation list and passing it to clients, and it's not so short to require more resources on both the issuer and the requester of the certificate. > Perhaps it's time to go with another method entirely. What method would you suggest here?
      • zimpenfish 1y ago
        > since you would need to ask for the certificate from a central authority Could it work that your long-term certificate (90 days, whatever) gives you the ability to sign ephemeral certificates (much like, e.g. LetsEncrypt signs your 90 day certificate)? That saves calling out to a central authority for each request.
        • yladiz 1y ago
          Without knowing the technical details too much: Maybe, although I don’t think it would make much difference in my argument, since it would still add too much time to the request. Likely less, but still noticeable.
    • Thorrez 1y ago
      >Why isn't it instead just a minute? or a few seconds? Wouldn't that be better? Then if your CA went down for an hour, you would go down too. With 47 days, there's plenty of time for the CA to fix the outage and issue you a new cert before your current one expires.
      • 8organicbits 1y ago
        Lots of ACME software supports configuring CA fallbacks, so even if a CA is down hard for an extended period you can issue certificates with the others. Using LetsEncrypt and ZeroSSL together is a popular approach. If you need a stronger guarantee of uptime, reach for the paid options. https://github.com/acmesh-official/acme.sh?tab=readme-ov-file#supported-ca https://github.com/acmesh-official/acme.sh?tab=readme-ov-fil...
        • Thorrez 1y ago
          If everyone uses that with 1 minute or 1 second expirations, I could certainly see a case where an outage in 1 CA causes traffic migration to another, causing performance issues on the fallback CA too. >If you need a stronger guarantee of uptime, reach for the paid options. We don't. If we had 1 minute or 1 second lifetimes, we would.
          • 8organicbits 1y ago
            Oh, agreed. I was responding to the part about extended outages.
    • FuriouslyAdrift 1y ago
      I just recently had a executive level manager ask if we could get a 100 year cert for our ERP as the hassle of cert management and the massive cost of missing a renewal made it worth it. He said six figures for the price would be fine. This is an instance where business needs and technology have gotten really out of alignment.
      • 9dev 1y ago
        How on earth would that make more sense than properly setting up ACME and forgetting about the problem for the next hundred years?? If your bespoke ERP system is really so hostile toward cert changes, put it behind a proper reverse proxy with modern TLS features and self-sign a certificate for a hundred years, and be done with it. It'll take about fifteen minutes of time, and executive level won't ever have to concern themselves with something as mundane as TLS certificates again.
        • zoeysmithe 1y ago
          Yep this. This is just "we have so much technical debt, our square pegs should fit into all round holes!" Business culture devaluing security is the root of this and I hope people see the above example of everything that's wrong with how some technology companies operate, and "just throw money at the problem because security in an annoying cost center" is super bad leadership. I'm going to guess this guy also have an MFA exception on his account and a 7 character password because "it just works! It just makes sense, nerds!" I've worked with these kinds of execs all my career and they are absolutely the problem here.
          • FuriouslyAdrift 1y ago
            IT serves business needs... not the other way around. If anything, cloud services and mobile device access has made securing anything just about impossible.
            • Loudergood 1y ago
              Classic case of business not understanding that it doesn't just need access to the data, it needs secure access to the data.
    • btown 1y ago
      Sure, there is an argument about slippery slopes here. But the thing about the adage of "if you slowly boil a frog..." (https://en.wikipedia.org/wiki/Boiling_frog https://en.wikipedia.org/wiki/Boiling_frog) is that not only is the biological metaphor completely false, it also ignores the fact that there can be real thresholds that can change behavior. Imagine you run an old-school media company who's come into possession of a beloved website with decades of user-generated and reporter-generated content. Content that puts the "this is someone's legacy" in "legacy content." You get some incremental ad revenue, and you're like "if all I have to do is have my outsourced IT team do this renewal thing once a year, it's free money I guess." But now, you have to pay that team to do a human-in-the-loop task monthly for every site you operate, which now makes the cost no longer de minimis? Or, fully modernize your systems? But since that legacy site uses a different stack, they're saying it's an entirely separate project, which they'll happily quote you with far more zeroes than your ads are generating? All of a sudden, something that was infrequent maintenance becomes a measurable job. Even a fully rational executive sees their incentives switch - and that doesn't count the ones who were waiting for an excuse to kill their predecessors' projects. We start seeing more and more sites go offline. We should endeavor not to break the internet. That's not "don't break the internet, conditional on fully rational actors who magically don't have legacy systems." It's "don't break the internet."
      • tyzoid 1y ago
        Pretty much any legacy system can have a modern reverse proxy in front of it. If the legacy application can't handler certs sanely, use the reverse proxy for terminating TLS.
        • btown 1y ago
          "Just use Nginx" was not a viable option here, without additional Certbot etc. orchestration, until 14 days ago! And this is still in preview! https://blog.nginx.org/blog/native-support-for-acme-protocol https://blog.nginx.org/blog/native-support-for-acme-protocol And, if you haven't been using a reverse proxy before, or for business/risk reasons don't want to use your main site's infrastructure to proxy the inherited site, and had been handling certificates in your host's cPanel with something like https://www.wpzoom.com/blog/add-ssl-to-wordpress/ https://www.wpzoom.com/blog/add-ssl-to-wordpress/ - it is indeed a dedicated project to install a reverse proxy!
    • johannes1234321 1y ago
      The exact time probably has no "best" but from past times: I have seen so many places where multi-year certificates were used and people forgot about them, till some service suddenly stopped working and then people having to figure out how to replace that cert. A short cycle ensures either automation or keeping memory fresh. Automation of course can also be forgotten and break, but it's at least somewhere written down in some form (code) rather than personal memory of a long gone employee who previously uploaded certs to some CA website for signing manually etc
    • ozim 1y ago
      There was an attempt doing it differently by CRL but it turns out certificate revoking is not feasible in practice on web scale. Now they are doing next plausible solution. Seems like 47 days is something they found out by let’s encrypt experience estimating load by current renewals but that last part I am just imagining.
      • fanf2 1y ago
        CRL distribution at web scale is now possible thanks to work by John Schanck at Mozilla https://hacks.mozilla.org/2025/08/crlite-fast-private-and-comprehensive-certificate-revocation-checking-in-firefox/ https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co... But CRL sizes are also partly controlled by expiry time, shorter lifetimes produce smaller CRLs.
        • ozim 1y ago
          Oh wow that’s really fresh. I was still stuck on cascade bloom filers
    • supertrope 1y ago
      As the limit approaches zero you re-invent Kerberos.
• sunneyx 1y ago
  [flagged]
  • skylurk 1y ago
    Not for long. https://blog.nginx.org/blog/native-support-for-acme-protocol https://blog.nginx.org/blog/native-support-for-acme-protocol
    • stackskipton 1y ago
      CaddyServer is still easier since declaring HTTPS for a site will trigger let's encrypt. Nginx requires module loading and other things.
    • ComputerGuru 1y ago
      It’s not clear if this supports dynamic configurations where the server name is pulled out of an nginx map?
  • dkiebd 1y ago
    SSL certificates are not only used by HTTP servers.
    • auguzanellato 1y ago
      If working in a Kubernetes environment you can use cert-manager that basically manages certificate lifetime for you, just need to make the crt/key available to your services using secret references as volumes. If you're not using k8s certbot is also an option, you get your certificates under /etc/letsencrypt/live/$domain.
• azeemba 1y ago
  I think a large enough org that needs many different certificates should have an internally-trusted CA. That would then allow the org to decide their own policy for all their internal facing certificates. Then you only have to follow the stricter rules for only the public facing certs.
  • ocdtrekkie 1y ago
    It used to be only a large enough organization needed this, but smaller organizations could slap their PKI wildcard on everything. Between the 47 day lifetime and the removal of client authentication as a permitted key usage of PKI certs, everyone will need a private CA. Active Directory Certificate Services is a fickle beast but it's about to get a lot more popular again.
  • linsomniac 1y ago
    We make extensive use of self-signed certificates internally on our infrastructure, and we used to manually manage year-long certs. A few months ago I built "LessEncrypt", which is a dead simple ACME-inspired system for handing out certs without requiring hijacking the HTTP port or doing DNS updates. Been running it on ~200 hosts for a few months now and it's been fantastic to have the certs manage themselves. https://github.com/linsomniac/lessencrypt https://github.com/linsomniac/lessencrypt I've toyed with the idea of adding the ability for the server component to request certs from LetsEncrypt via DNS validation. Acting as a clearing house so that individual internal hosts don't need a DNS secret to get certs. However, we also put IP addresses and localhost on our internal certs, so we'd ahve to stop doing that to be able to get them from LetsEncrypt.
    • jraph 1y ago
      Why or in which cases is opening a dedicated port better than publishing challenges under some /.well-known path using the standard HTTP port? (You say hijacking the HTTP port, but I don't let the ACME client take over 80/443, I make my reverse proxy point the expected path to a folder the ACME client writes to, I'm not asking for a comparison with a setup where the acme client takes over the reverse proxy and edits its configuration by itself, which I don't like)
• ocdtrekkie 1y ago
  I do not think PKI will survive the 47 day change. I am not sure the CAB will survive that change. It seems extremely apparent the people who made the decision have neither any relevant experience in IT nor any practical understanding of security, and I think they've finally flown too close to the sun. Automated renewal is... probably about a decade or two from being supported well enough to be an actual answer. In our case, we'll be spending the next couple years reducing our use of PKI certificates to the bare functional minimum.
  • gruez 1y ago
    >Automated renewal is... probably about a decade or two from being supported well enough to be an actual answer. ??? All my servers use certbot and it works fine. There's also no shortage of SaaS/PaaS that offer free ssl with their service, and presumably they've got that automated as well.
    • ocdtrekkie 1y ago
      Out of about three dozen places I need a certificate, I believe one recently added support for ACME. Tell me you aren't in enterprise IT without telling me you aren't in enterprise IT. ;) It may help you to understand that it is not an assumption any given product even supports HTTPS well in the first place, and a lot of vendors look at you weird when you express that you intend to enable it. One piece of software requires rerunning the installer to change the certificate. Yeah, there are also some very expensive vendors out there to manage this for big companies with big dollars.
      • 9dev 1y ago
        Your perspective may be just as narrow, albeit from the other end of the spectrum. Huge heaps of things do work just fine with ACME now, or support being fronted by a reverse proxy which does. Plus, how would you ever get enterprise tool vendors to add support if not for customers pestering them with support requests because manual certificate renewal has gotten too painful? > I do not think PKI will survive the 47 day change. […] In our case, we'll be spending the next couple years reducing our use of PKI certificates to the bare functional minimum. Maybe PKI will die… or you will. Progress doesn't treat dinosaurs too well usually.
• xnorswap 1y ago
  I think the author has missed the point of the 47 day expiry. It is short enough to force teams to automate the process. You're not supposed to be human-actioning something every month. But yes, it'll be a huge headache for teams that stick their head in the sand and think, "We don't need to automate this, it's just 6 months". As the window decreases to 3 months it'll be even more frustrating, and then will come a breaking point when it finally rests at 47 days. But the schedule is well advertised. The time to get automation into your certificate renewal is now. In the real world however, this will be a LOT of teams. I think the organisations defining this has missed just how much legacy and manual processes are out there, and the impact that this has on them. I don't think this post makes that argument well enough, instead trying to argue the technical aspect of ACME not being good enough. ACME is irrelevant in the face of organisations not even trying, and wondering why they have a pain every 6 weeks.
  • rini17 1y ago
    When it's automated we're back at square one: after few years it breaks and nobody will have any idea where the acme scripts are or how to debug them.
    • sam_lowry_ 1y ago
      I already had this with the certbot on Debian that was running perfectly for 5-6 years by that time.
    • pferde 1y ago
      That could be an argument against automating anything, ever. The solution is just like with any other automation - document it.
      • quesera 1y ago
        ... which is also the solution for any other infrequent manual process. :)
    • syncsynchalt 1y ago
• dale_glass 1y ago
  I believe the low maximum lifetimes are becoming a thing because revocation failed. CRLs become gigantic and impractical at the sizes of the modern internet, and OCSP has privacy issues. And there's the issue of applications never checking for revocation at all. So the obvious solution was just to make cert lifetimes really short. No gigantic CRLs, no reaching out to the registrar for every connection. All the required data is right there in the cert. And if you thought 47 days was unreasonable, Let's Encrypt is trying 6 days. Which IMO on the whole is a great idea. Yearly, or even monthly intervals are long enough that you know a bunch of people will do it by hand, or have their renewal process break and not be noticed for months. 6 days is short enough that automation is basically a must and has to work reliably.
  • ashleyn 1y ago
    Certbot has this down to a science. I haven't once had to touch it after setting it up. 6 days doesn't seem like an onerous requirement in light of that.
  • layer8 1y ago
    CRLs don’t have to be large, since they only need to list revoked certificates that also haven’t expired yet. Using sub-CAs, you can limit the maximum size any single CRL could possibly have. I’m probably missing something, but for SSL certificates on the public internet I don’t really see the issue. Where is the list of such compromised non-expired certificates that is so gigantic?
  • Andoryuuta 1y ago
    Semi-related: Firefox 142 was released a few days ago and is now using CRLite[0], which apparently only needs ~300kB a day for for the revocation lists in their new clubcard data-structure[1]. [0]: https://hacks.mozilla.org/2025/08/crlite-fast-private-and-comprehensive-certificate-revocation-checking-in-firefox/ https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co... [1]: https://github.com/mozilla/clubcard https://github.com/mozilla/clubcard
  • FuriouslyAdrift 1y ago
    Because of all my internal systems that use certs to connect (switches, routers, iot, etc) that have manual only interfaces (most are tftp), I have had to go back to just running my own CA infrastructure and only using public CAs for non-corporate or mixed audience sites/services. It's really annoying because I have to carve outs for browsers and other software that refuse to connect to things with unverifiable certs and adding my CA to some software or devices is a either a pain or impossible. It's created a hodge podge of systems and policies and made our security posture full of holes. Back when we just did a fully delegated digicert wildcard (big expense) on a 3 or 5 year expiration, it was easy to manage. Now, I've got execs in other depts asking about crazy long expirations because of the hassle.
• b112 1y ago
  I've spent 15+ minutes searching, and the digicert (linked to in the article), and other cert providers all reference a vote on "Multi-Perspective Issuance Corroboration (MPIC)". Everywhere I've read, one "must validate domain control using multiple independent network perspectives". EG, multiple points on the internet, for DNS validation. Yet there is not one place I can find a very specific "this is what this means". What is a "network perspective", searching shows it means "geographical independent regions". What's a region? How big? How far apart from your existing infra qualifies? How is it calculated. Anyone know? Because apparently none of the bodies know, or wish to tell.
  • nikanj 1y ago
    It means the barrier of entry to the SSL certificate market gets higher, favouring established players
    • wongarsu 1y ago
      Renting five servers 500km apart each, spread across at least two continents is hardly a difficult or costly requirement
    • cpach 1y ago
      I kind of get your point, but think about what low barrier of entry for becoming a CA would imply. Also, there are loads of other requirements except this one and they are there for good reasons. It’s not easy to get your root certificate accepted by Firefox/Google/Microsoft/Apple and it shouldn’t be.
  • deleted 1y ago
    [deleted]
  • jaas 1y ago
    Section 3.2.2.9 of this document: https://cabforum.org/working-groups/server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.1.7.pdf https://cabforum.org/working-groups/server/baseline-requirem... You can also just search the document for the word "Perspective" to find most references to it.
• dark-star 1y ago
  > I am responsible for approving SSL certificates for my company What does this even mean? Does he check the certificates for typos, or that they have the correct security algorithm or something? I'm pretty sure such an "approval" could be replaced by an automatic security scanner or even a small shall script
  • Avamander 1y ago
    It means that they click on the link in the email they get and confirm issuance for their domain that way.
  • tialaramex 1y ago
    This is what fascinated me too. FWIW the idea of inspecting the certificate "for typos" or similar doesn't make sense. What you're getting from the CA wasn't really the certificate but the act of signing it, which they've already done. Except in some very niche situations your certificate is always already publicly available when you receive it, what you've got back is in some sense a courtesy copy. So it's too late to "approve" this document or not, the thing worth approving already happened. Also the issuing CA was required by the rules to have done a whole bunch of automated checks far beyond what a human would reasonably do by hand. They're going to have checked your public keys don't have any of a set of undesirable mathematical properties (especially for RSA keys) for example and don't match various "known bad" keys. Can you do better? With good tooling yeah, by hand, not a chance. But then beyond this, modern "SSL certificates" are just really boring. They're 10% boilerplate 90% random numbers. It's like tasking a child with keeping a tally of what colour cars they saw. "Another red one? Wow".
    • ameliaquining 1y ago
      It's possible that this was just a slight imprecision of language, and the thing being inspected is the CSR rather than the actual certificate. (But the point about individual certificates/CSRs being unworthy of human attention is totally right.)
      • 1y ago
• jraph 1y ago
  The decreasing validity time pushes for the process to be automated, and automation reduces the possible human errors. Many things need to be run and automated when running stuff, I don't understand what makes SSL certificates special in this. For a hobbyist, setting up certbot or acme.sh is pretty much fire and forget. For more complex settings well… you already have this complexity to manage and therefore the people managing this complexity. You'll need to pick a client and approve it, sure, but that's once, and that's true for any tool you already use. (edit: and nginx is getting ACME support, so you might already be using this tool) It's not the first time I encounter them, but I really don't get the complaints. Sure, the setup may take longer. But the day to day operations are then easier.
  • birdman3131 1y ago
    One of the arguments to be made is that while " automation reduces the possible human errors." it also reduces the amount of human oversight as well.
    • auguzanellato 1y ago
      Do you really need more oversight on renewals than a simple success/failure notification? For new certificate you can keep the existing amount of human oversight in place so nothing changes on that front.
      • everforward 1y ago
        Yes, because you want to know what certificates you're issuing. You could be automatically issuing and deploying certs on a system where the actual app was decommissioned. It's probably mostly a risk for legacy systems where the app gets killed, but the hardware stays live and potentially unpatched and is now vulnerable to a hacker taking it over. With manual renewals, the cert either wouldn't get renewed and would become naturally invalid or the notification that the cert expired would prompt someone to finish the cleanup.
        • 1y ago
• gwbas1c 1y ago
  With Azure-hosted sites, I find it's significantly easier to have Microsoft perform all certificate management for us. All we do is verify that we own the domain, and then they do all the certificate management for us. When I saw the 47-day expiration period, it made me wonder if someone is trying to force everyone onto cloud solutions like what Azure provides. The old geezer in me is disappointed that it's increasingly harder to host a site on a cable modem at home. (But I haven't done that in over two decades.)
  • yjftsjthsd-h 1y ago
    > When I saw the 47-day expiration period, it made me wonder if someone is trying to force everyone onto cloud solutions like what Azure provides. > The old geezer in me is disappointed that it's increasingly harder to host a site on a cable modem at home. (But I haven't done that in over two decades.) It might be harder to host at home, but only for network reasons. It is perfectly straightforward to use letsencrypt and your choice of acme client to do certificates; I really don't think that's meaningful point of friction even with the shorter certificate lifetimes.
    • eichin 1y ago
      Yeah - the best time to do automated renewal was ~5 years ago, the second best time is now - I just get email once a week with the list of cert renewals (which is how I learned, to my surprise, that sometimes the letsencrypt renewals do fail! but I've never seen it happen twice in a row.) And it's not like the automation is hard (when I first did letsencrypt certs I did a misguidedly-paranoid offline key thing - for my second attempt, the only reason I had to do any work at all, instead of letting the prepackaged automation work, was to support a messy podman setup, and even that ended up mostly being "systemd is more work than crontab")
• Avamander 1y ago
  There's two sides to this, if it's not a public service, why should it have a certificate from a public CA? If your risk assessment says that you do not need MPIC, then just don't do that, yourself. The second side is that if it's so tedious to approve and install, use solutions that require neither. Surely you don't need to have some artisanal certificate installation process that involves a human if you already admit that stricter issuance reduces no risk of yours. Thus, simplify your processes. There are automated solutions to pretty much all platforms both free and paid. Nginx has it, I just checked and Apache has a module for this as well. Could the author write a blog post about what's stopping them from adopting these solutions? In the end I can think of *extremely* few and niche cases where any changes to a computer system are actually (human) time-consuming due to regulatory reasons that at the same time require public trust.
  • ameliaquining 1y ago
    "If it's not a public service, why should it have a certificate from a public CA?" Probably because making sure that clients trust the right set of non-public CAs is currently too much of a pain in the ass. Possibly an underrated investment in the security of the internet would be inventing better solutions to make this process easier, the way Certbot made certificate renewal easier (though it'd be a harder problem as the environment is more heterogeneous). This might reduce the extent of conservative stakeholders crankily demanding that the public CA infrastructure accommodate their non-public-facing embedded systems that can't keep up with the constantly evolving security requirements that are part and parcel of existing on the public internet.
    • Avamander 1y ago
      > Probably because making sure that clients trust the right set of non-public CAs is currently too much of a pain in the ass. Possibly an underrated investment in the security of the internet would be inventing better solutions to make this process easier. I don't see a reason why that should be a problem to solve for public CAs and rest of the internet? Complaining about multi-perspective validation or lifetime is silly if the hindrance is someone's own business needs and requirements.
• romaniv 1y ago
  The web today is a rotting carcass with various middlemen maggots crawling all over it and gorging themselves on the decay. The only real discussion to be had is what to replace it with and how to design the new protocols to avoid the same issues.
  • jacquesm 1y ago
    The reason the web is a rotting carcass is not because of the way the web is architected, it is because a lot of people's livelihoods depend on making it as rotten as possible without collapsing it entirely. From advertising companies, search engines (ok, sometimes both), certificate peddlers and other 'service' (I use the term lightly here) providers there are just too many of these maggots that we don't actually need. We mostly need them to manage the maggots! If they would all fuck off the web would instantly be a better place.
    • ameliaquining 1y ago
      Who do you propose needs to fuck off in order for the web to not need certificate authorities?
  • bloomca 1y ago
    What do you think is better? The web is indeed questionable, but it is literally the best we have, it is still reasonably simple to deploy a web app. Desktop app development gets increasingly hostile and OSes introduce more and more TCC modals, you pretty much need a certificate to codesign an app if you sideload (and app stores have a lot of hassle involved), mobile clients had it bad for a while (and just announced that Android will require a dev certificate for sideloading as well). edit: also another comment is correct, the reason it is like that is because it has the most eyes on it. In the past it was on desktop apps, which made them worse
  • pixl97 1y ago
    Thats the neat thing, you cant really avoid the same issues. Security is not a destination, it's a process. Everything you find a way to make something more secure someone seems to find a new way to attack it, and so the ecosystem evolves.
• fidotron 1y ago
  Looking at the changes going on in computing regarding the need for constantly updating certificates for a website, verified identity to develop mobile apps etc. it's clear there is a background push for control of everything such that when things are considered problems they can promptly be cut off from everything all at once.
  • ameliaquining 1y ago
    Are 389-day certificates really that much less concerning from a censorship perspective than 47-day ones? Also, DNS is already much more censorable than the Web PKI, so I don't see how increasing reliance on the latter makes things worse.
• Intermernet 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, 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.
  • 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.
• compumike 1y ago
  It's strange: SSL certificates (and maybe domain name registrations?) are one of the only "ticking time bomb" elements present in every modern web stack, whether a static site or not. By "ticking time bomb" I mean that there's a hard date N weeks/months from now where your site will definitely stop working, unless some external pile of dependencies work smoothly to extend that date. Software didn't have that sort of "ticking time bomb" element before, I think? I think I understand why it's necessary: we have a single, globally shared public namespace of domain names, which we accept will turn over their ownership over the long run, just like real estate changes hands. So we need expiration dates to invalidate "stale" records. We've already switched over everything to Let's Encrypt. But I don't think anyone should be under the delusion that automation / ACME is failproof: https://github.com/certbot/certbot/issues?q=is%3Aissue%20renew https://github.com/certbot/certbot/issues?q=is%3Aissue%20ren... https://github.com/cert-manager/cert-manager/issues?q=is%3Aissue%20renew https://github.com/cert-manager/cert-manager/issues?q=is%3Ai... https://github.com/caddyserver/caddy/issues?q=is%3Aissue%20ACME%20renew https://github.com/caddyserver/caddy/issues?q=is%3Aissue%20A... (These are generally not issues with the software per se, but misconfiguration, third-party DNS API weirdness, IPv6, rate limits, or other weird edge cases.) Anyway, a gentle reminder that Let's Encrypt suggests monitoring your SSL certificates may be "helpful": https://letsencrypt.org/docs/monitoring-options/ https://letsencrypt.org/docs/monitoring-options/ (Full disclosure: I wrote the most recent addition to that list, with the "self-hosted scripts".)
• mholt 1y ago
  First line: > I am responsible for approving SSL certificates for my company. And that is exactly what the requirements are intending to prevent. Automation is the way. The system is working!
  • cr3ative 1y ago
    Right. This unfortunately reads like a human process has been set up where automation should have been set up, and now that hand is being forced. The hand-waving away of certbot/ACME at the very end of the article only really goes to show that it hasn't been looked in to properly for whatever reason.
• ExoticPearTree 1y ago
  I think that the author is a bit confused about email validation. When I was doing this, via email, if you wanted a certificate for sub.subdomain.example.com - the list of email addresses were in order something like hostmaster@sub.subdomain.example.com and hostmaster@example.com - you clicked the radio option that best suited you and you were good to go. You don't need email addresses for every subdomain.
  • jeroenhd 1y ago
    I think the reason they couldn't do it is that they want a certificate for *.sub.example.com. Wildcards tend to trip up certificate provisioning in annoying ways.
• rco8786 1y ago
  They are obnoxious and they used to be 10x more obnoxious.
• Havoc 1y ago
  > I am responsible for approving SSL certificates for my company. I’ve developed a process What does that even mean? Is he smelling them to check for freshness? I get process around first time request perhaps to ensure it’s set up right, but renewals? > My stakeholders understand their roles and responsibilities Oh no. All that’s missing here is a committee and steering group and daily stand ups
• ozim 1y ago
  It would not be a problem if we could have magic way to make CRL working on scale and not having other smaller issues.
• the_mitsuhiko 1y ago
  The one complaint that I think is valid is that automating wildcard certificates at the moment is really tricky. And that really is because most of the DNS providers do not have proper APIs for it.`
  • mdaniel 1y ago
    Most? https://registry.terraform.io/search/providers?q=dns https://registry.terraform.io/search/providers?q=dns seems to be a pretty healthy list, and https://registry.terraform.io/providers/hashicorp/dns/latest https://registry.terraform.io/providers/hashicorp/dns/latest will work for any one that honors https://datatracker.ietf.org/doc/html/rfc2136 https://datatracker.ietf.org/doc/html/rfc2136 (although "honoring standards" is probably the very problem you were citing)
• stblack 1y ago
  Nobody has yet mentioned how certificates induce and support churn. In 2025 it's not possible to create an app and release it into the world and have it work for years or decades, as was once the case. If your "developer certificate" for app stores and ad-hoc distribution is valid for a year, then every year you must pay a "developer program fee" to remain a participant. You need to renew that cert, and you need to recompile a new version within a year. Which means you must maintain a development environment and tools on an ongoing basis for an app that may be feature- and operationally-complete. All this is completely unnecessary except when it comes to reinforcing hegemony of app-store monopolists.
  • deleted 1y ago
    [deleted]
  • dns_snek 1y ago
    But that has nothing to do with certificates as such and everything to do with app store policies. Certificates don't induce churn - app stores do.
  • xg15 1y ago
    Yeah, we went from "software is a good that can be duplicated with no cost" to "software can be a service" to "software must be a service".
  • supertrope 1y ago
    A $100 fee makes it costly to burn and churn new accounts. So it's a spam filter. Forcing developers to stay engages pushes out feature complete software but also pushes out unmaintained software. An app store is an inherently higher cost distribution method. The operating systems are gratis so development is cross subsidized from app store royalties. They have an incentive to host more paid apps, especially micro-transaction apps that trick kids into spending thousands of dollars off mom's credit card. Of course they've banned or are going to ban alternative channels so you can't choose to self-distribute.
  • Loudergood 1y ago
    Yup, I bought and paid for a simple Android game that my kids could play together while we were waiting for thing. New phone and suddenly I can't install it from Google Play anymore simply because the developer hasn't updated it in awhile. Not that it needs to be updated. I've since repurchased it from itch.io and it runs fine, but that's not unusual for lots of good old software.
• ollybee 1y ago
  What is obnoxious is that certificate transparency logs mean that you now have to effectively centrally register any new domain you put online. That means you instantly see a whole load of traffic to your domain from bots, scrapers, beg bounty scanners etc. Any new site has to be designed to handle that baseline of traffic. I understand the point of CTL's and it's necessary given that every browser and device is configured to trust CA's that you wouldn't actually trust. It's had awful side effects for people who want to host low traffic sites, or fly under the radar for whatever reason.
  • cpach 1y ago
    Point taken. One option to avoid this could be to use the DNS-01 challenge to get a wildcard cert from Let’s Encrypt. Then CT will not expose your subdomains.
• ComputerGuru 1y ago
  I actually don’t have a problem with the SSL changes as they specifically pertain to http servers – it’s largely a dived problem with automated solutions compatible with all the major players on most fronts. But certs and every other context have become neigh impossible except in enterprise settings with your own CA and cert servers. From things like printers and network appliances to entirely non-http applications like VPN (StrongSwan and OpenVPN both have/support TLS with signed SSL certs, but place very different constraints on how those work in practice and what identities are supported, how or if wildcards work, etc). Very little attention has been paid to non-general purpose and non-http contexts as things currently stand.
  • DougN7 1y ago
    The last time I looked, if you ran your HTTPS service on anything other than port 443 LetsEncrypt was not for you. Maybe that’s built into ACME?
    • OptionOfT 1y ago
      You can get LetsEncrypt certificates for endpoints that aren't publically accessible through the DNS-01 challenge.
    • mdaniel 1y ago
      I can't tell if it's a typo but HTTP-01 would contact your webserver on :80 in order to successfully retrieve a very, very, very specific ACME path and does not care at all what you do with your issued TLS afterward, including what port you run it upon Also, I know firsthand that the DNS Validator also works perfectly fine, no http check required
      • DougN7 1y ago
        That’s right. So a private server hosted on something other than port 80 (like port 81 in my case) is where you’re out of luck :(
• commandlinefan 1y ago
  I would be ok with all of this if it meant anything. My computer has 151 trusted Certificate Authorities installed on it, including heavy hitters in the CA industry such as TUBITAK, Telia and Sectigo. As a user, I have no idea what sort of actual verification went into verifying the certificates that the site I'm visiting is presenting.
  • ameliaquining 1y ago
    The reason you can trust all those CAs is because Certificate Transparency makes it very likely that misissuances will be caught, and a CA that screws up and fails to credibly ensure that it won't happen again will be distrusted be browsers. The chance that the particular domain you're interested in will be the one that gets a misissued certificate before that happens is really quite low. It's not a perfect system but it works surprisingly well in practice.
• watusername 1y ago
  To be frank, the whole post reads like "I hate change" with no convincing argument otherwise. The author even acknowledges the very lenient ramp-up from CAB _and_ the myriad of available tooling, yet still throws his hands up. > I am responsible for approving SSL certificates for my company. [...] I review and approve each cert. What started out as a quarterly or semi-monthly task has become a monthly-to-weekly task depending on when our certs are expiring. I don't get the security need for manually approving renewals, and the author makes no attempt to justify this either. It may make sense for some manual process to be in place for initial issuances, as certificates are permanently added to a publicly-available ledger. And to take a step back, do you need public certs to begin with? Can you not have an internal CA? Again, the author makes no attempt to justify this, or demonstrate understanding in the post. > email-based validation may as well not exist when we need to update a certificate for test.lab.corp.example.com because there is no webmaster@test.lab.corp.example.com. I know that this is an example, but as a developer it would be a pain to have to go through a manual, multi-day process for my `test.lab.corp.example.com` to work. And the rest of the post seems to imply that this is actually the case at OP's org. > Which resource-starved team will manage the client and the infrastructure it needs? It will need time to undergo code review and/or supplier review if it’s sold by a company. There will be a requirement for secrets management. There will be a need for monitoring and alerting. It’s not as painless as the certificate approval workflow I have now. There are additional costs and new processes to be made, yes, but even from a non-technical POV this appears to be a good time to lead and take ownership. > Any platforms that offer or include certificate management bundled with the actual services we pay for will win our business by default. [...] What is obvious to me is that my stakeholders and I are hurrying to offload certificate management to our vendors and platforms and not to our CA. That's okay. If you hate change and don't want to take ownership, pay someone else to take ownership.
• bell-cot 1y ago
  Not mentioned - especially for smaller or short-staffed org's, it may be a non-trivial effort to automate, then secure/document/maintain the automation. Vs. shoving httpS proxy services in front of insecure backends is often easy.
  • OptionOfT 1y ago
    That is my standard approach when I deploy something. My application shouldn't deal with TLS unless it needs to. Usually fronting a service with Traefik or NGINX fits all the business needs. I do recall a setup in Kubernetes where nearly all traffic had to be encrypted, even within the cluster. The boundary was the pod. Within a pod you are guaranteed that all containers run on the same node. And since a node is a physical boundary (it's either a physical machine or a vm on a physical machine) you're guaranteed that that traffic never goes over a network cable. The solution then is to deploy something like LinkerD which ensures that traffic between pods is encrypted transparently. We could've eased the policy that traffic between pods on the same node shouldn't be encrypted, but then we introduced more variables in the process, and it wasn't worth it.
• sigseg1v 1y ago
  The first link in the article I clicked for context led to a cert provider whose business name I recognize. Found the problem. I inherited a process using the same thing last year and it is the absolutely most insane nonsense I can think of. These types of companies have support that is totally useless and their entire business model is to charge 1000x or more (eg. compare signature price to a HSM in GCP) what competitors charge while also providing less functionality, and hoping that people will get sucked in and trapped in their ecosystem by purchasing an expensive cert such as an "EV" cert which I'm still not totally clear does by the way, but I'm assured it's very important for security on Windows. Not security against bad guys though... it appears to be for security against no-name anti virus vendors deleting your files if they detect you didn't pay this "EV" cert ransom. They don't need to actually detect threats based on code or behavior, they just detect if you have enough money.
• creatonez 1y ago
  If short lived certs are a problem, your methodology is wrong and has been for a long time. Period.
• FpUser 1y ago
  I used to pay for certs for my company and it had started to feel like extortion business and was also stealing my time/ so at some point I've said fuck you vultures and switched to LetsEncrypt.
• riffic 1y ago
  47 day certs are going to be glorious. Get with the times, please.
• _JamesA_ 1y ago
  Code signing certificates are even worse.
• tzs 1y ago
  I've only put maybe 2 seconds of thought into this so it is probably stupid, but why don't we have an alternative that does not require third party certificate authorities? For example why not allow an organization to have its own self-signed certificate authority, and allow it to publish its self-signed root certificate through DNS, and make browsers accept that root for use with that domain? I see two objections offhand. Objection #1. It doesn't provide any validation that the certificates were actually made by the legal entity that they claim to be for. It just shows that whoever made the CA had write access to the domain's DNS records. It can't replace EV certificates or OV certificates. Retort #1. So? Those sites that need EV of OV certificates can keep using the current approach. But a very large number of sites don't need EV or OV certificates. This can be seen by the success of Let's Encrypt which only issues DV certificates. Even some large sites use DV certificates, such as Amazon. Objection #2. If someone gets write access to your DNS records they can replace your CA! Retort #2. So? If someone gets write access to your DNS records they can make Let's Encrypt certificates for your domain. What have I overlooked?
  • alanfranz 1y ago
    This is called DANE. I don’t know if I missed an implied /s in your message. You overlooked the need for DNSSEC, so another PKI with his own quirks, and somehow less reliable than CAs.
  • tptacek 1y ago
    Downgrade protection. It's very tricky to come up with an alternate root of trust for TLS connections that isn't strippable by middleboxes. Stripping isn't even always intentional: a big part of why DANE failed was that middleboxes reject DNSSEC responses, forcing browsers to fall back to X.509. If you have to have an X.509 WebPKI certificate no matter what, then the alternative root of trust just adds attack surface, and while a tiny subset of nerds with ideological objections to X.509 might be fine with that, it flunks the cost/benefit calculations for the browser developers themselves. If you want to get more specific about using DNS as an alternate root of trust, there are bigger problems. The X.509 WebPKI has mandatory certificate transparency, so misissuance can be detected. Just as importantly, and relatedly, the browser developers can kill a CA that misissues. They've done so multiple times, and have killed one of the largest CAs over misissuance incidents. Neither capability exists for a DNS-based PKI, which is deeply problematic given that the DNS PKI is --- de jure --- run by state actors.
• jmwilson 1y ago
  Another obnoxious behavior is clients enforcing lifetime requirements for domains they have no business imposing their opinion about: .internal and .home.arpa. These are specifically carved out for private use. If I want to roll my own CA with a 2.5.29.30 name constraint extension for one of these domains and hand out a 10 year wildcard certificate, I should be able to without interference from my web browser. Additionally, Google and the PSL have inadvertently broken .home.arpa on Chrome by misclassifying it as a public suffix, while leaving .internal alone. A wildcard cert for *.home.arpa will not work on Chrome, but *.internal will, despite these two domains being essentially equivalent in purpose.
  • jeroenhd 1y ago
    > I should be able to without interference from my web browser You should be. From what I can remember, both Firefox and Chrome add exceptions to user installed certificates that disable requirements such as certificate transparency logs and even things like HPKP back when that was a thing. It's easy to make a mistake and install certificates in the system chain instead (especially on Windows), but if you pick the right certificate store I don't think you should be having any trouble. That said, it's been a while since I last dealt with Chrome, maybe things have gotten worse.
    • jmwilson 1y ago
      Firefox does do the right thing and seems the most usable browser for private CAs. Chrome and derivatives mostly too, except the problem mentioned about the public suffix list. Mobile clients seem the most broken. I can't get iOS to work well with my private CA packaged into a .mobileconfig, but it could be my error as well.
• m-p-3 1y ago
  It's cumbersome for a reason, and I believe it will lead to better tooling and automation.
  • syncsynchalt 1y ago
    The better tooling and automation already exists, it's really all over but the shouting. The pain comes from supporting vendor equipment that's already on its way to the dustbin. Vendors that fired their entire engineering group half a decade ago and have no way to respond, but the equipment will still be in production for another 20 years. There are many solutions (reverse proxies, private CAs, literally hiring a guy to manually update certs on each bit of equipment every 35 days), some of them are painful, but it's not worth handicapping the security of the entire public web for them.
• deleted 1y ago
  [deleted]
• immibis 1y ago
  Too many people don't realize that it's not an open ecosystem any more. The Web is no longer an open collection of a large number of HTTP/HTML clients and servers. It's a singular platform, produced by control a centralised consortium of a small number of entities (browser vendors (mostly Google), ad vendors (mostly Google), and a few very large for-profit sites (mostly Google)) and since it is their product alone, they dictate how it works and they don't have your interests in mind. You not liking this fact doesn't make it untrue. We're not heading towards this endpoint - we're already there. You will either obey the rules of the product (as dictated by mostly-Google), or you will stop using the product. It's no different in kind from either obeying the new Play Store policies or getting removed from the Play Store. It's no different in kind from either obeying the new Twitter terms or getting banned from Twitter. These are applications, centrally controlled platforms, not ecosystems. If the Web decides that you need to meet some requirement but your corporate process is set up in a way that makes it onerous to meet, then you either change your corporate process or you get off the Web. At least it still doesn't cost actual money or ID documents to be on the Web, like it does on the Play Store. I'm not very sympathetic to corporations who put roadblocks in front of themselves and then play the victim. The Web has demanded that you must have a streamlined fully automated process for certificate issuance and deployment, but, key point, this isn't an unreasonable requirement. It's justified to keep a close eye on the rollout of new Web requirements, because unreasonable ones are surely not far behind. Google has just announced that in the next version of Android you won't be able to sideload apps that Google hasn't approved. It'd be folly to assume they aren't trying to impose something similar on the Web as well. But this isn't that, and can't become that.
• beaugunderson 1y ago
  it's even worse if you are an individual developer who wants to sign the products you're releasing on Windows. Azure had an "individual developer" beta that lasted less than a year and is now closed... so you have to be able to prove your "business" has been around for three years. they're one of the very few low-cost options who support cloud signing... $10/month or $120/year is VERY reasonable compared to $300/year the other registrars want, PLUS the cost of an HSM you can't use from the cloud. how are people doing signed binaries on Windows for open source projects? I bought a three year file-based certificate to kick the can down the road but those three years are now up.
• 1vuio0pswjnm7 1y ago
  "File-based domain validation was less secure; one dangling DNS record or webserver mis-configuration is all it takes to hijack a certificate. The remaining domain control validation (DCV) methods for my organization have been reduced to two options: DNS TXT records and email-based validation. DNS validation is a decent and secure option in an organization where DNS management access is tightly controlled. A recent change aims to thwart BGP hijacking and DNS spoofing attacks. Indeed, there are CA consulting services that will offer to "bring PKI and DNS together to validate domain ownership and issue certificates without manual DNS record updates"." This CA-based, i.e., third-party-based, "Web PKI" appears to depend heavily on the ICANN DNS. But in ICANN DNS the authoritative nameservers are not required to accept encrypted queries or send encrypted responses In this ICANN DNS upon which "Web PKI" depends, specifically the system of authoritative nameservers, there is no encryption, only authentication, and it is not mandatory for all nameservers. Even more, the setup and maintenance of this authentication system for the data^1 served by these nameservers (DNSSEC) is as difficult if not more than the CA-issued certificates system for networked computers that the blog post is complaining about^2 1. Nevermind the authentication of the computers serving the zone data 2. https://ianix.com/pub/dnssec-outages.html https://ianix.com/pub/dnssec-outages.html
• unl0ckd 1y ago
  thank you everyone for your time and insights, especially those that challenged me and opened me up to new possibility.
• lulceltech 1y ago
  Hey there I feel your pain, ironically this is what lead me to create a new tool for developers like yourself called VanityCert that takes away the headache. My journey personally was with my previous company and we had the challenge of 1-n domains pointing at 1-n sub domains so a simple solution like certbot just didn’t work for us sadly. Not only that but my bosses were doing it manually and still paying for the certs which was consuming time and money. So over the course of a few months I wrote a solution to that problem to easily issue, manage, and renew 1-n certs for 1-n vanity domains. Was a good bit of work but for the last 2 years it’s been flawless and turned into a upsell and a money maker from a losing situation previously. This is funny timing because we actually just put VanityCert on product hunt if you’re interested in checking out what I build. Would love your thoughts!