121–130 of 166 posts
Earlier quoted context omitted.
SAN isn't a practical solution for cases where you don't want to expose which subdomains exist, or where you allocate them dynamically.
Unless all your subdomains are unique (e.g. coming out of a PRNG) AND there are no public DNS entries for them, subdomain enumeration by DNS or IP space is super easy. Not using SAN because of info disclosure concerns is security through obscurity.
Earlier quoted context omitted.
HN uses ycombinator's wildcard certificate, and it's not up until August 2019. It's likely that they don't want to go through the trouble until it's really needed.
With Let's Encrypt, the trouble became "Whoaaa I just ran a command and everything works like magic!"
For sufficiently nonstandard setups, it's often easier to do the commonplace email-based verification than make Let's Encrypt work. I'd love to switch all of our internal services at $dayjob over to LE, but emails to webmaster@ already go somewhere useful, and setting up externally-visible DNS and fake servers is much more involved. (Either we write some code, or we do it by hand each time, and if we're doing it by hand, it's easier to just handle an email.)
Earlier quoted context omitted.
That's called automation and it's a good thing.
"Magic" is automation that is hidden from you. That one is not universally good. The one thing you don't want on the configurations of a server farm is "magic". It is simply impossible to manage. But it's a good thing LE is available without the magic too.
Are you managing all your TCP connections manually then? It's a miracle that "magic" works without you having to manage it.
Earlier quoted context omitted.
not for wildcards, also if you don't want to take your website down during the process, the command line becomes slightly more convoluted
There are multiple ways of using Let's Encrypt that don't have to take the website down.
Earlier quoted context omitted.
That doesn't prevent domain enumeration for your application though. Once you publish an application, anyone using it can find the address its hosted behind
> publish Sandstorm is a platform for personal computing; each person runs their own applications, much like in a PC. Also, applications don't get hostnames; each document (or equivalent) in the application gets its own hostname.
Earlier quoted context omitted.
SAN isn't a practical solution for cases where you don't want to expose which subdomains exist, or where you allocate them dynamically.
Unless all your subdomains are unique (e.g. coming out of a PRNG) AND there are no public DNS entries for them, subdomain enumeration by DNS or IP space is super easy. Not using SAN because of info disclosure concerns is security through obscurity.
Earlier quoted context omitted.
I feel like this is one of those "faster horse" moments. You don't need a wildcard cert! Just get certs for each one of your subdomains, even internally.
I get where you're coming from but I depend on a subdomain for each one of my user signups and we're talking thousands. LE limits us to 100 subdomains on a single cert and would require a restart for each signup. I'll definitely be using LE for other projects but many use cases require wildcards.
Earlier quoted context omitted.
Yeah until two hours later when you notice it messed with random shit it wasn't even supposed to touch. At least, that was my experience; I suppose it depends on how common your setup happens to be. I still love Let's Encrypt for its principle, but I don't dare running it in full auto mode anymore. A few custom shell scripts get the job done easily enough.
The auto mode just confused me. Every setup is different. Some use Apache, nginx, or both -- and proxied behind Haproxy or varnish. Then there's stuff like cpanel or virtualmin. So you got to expect any combination of those -- one or more, or combined. Their scripts would have to accommodate for so many different things. How could I anticipate what it would do? Am I missing something that would make this magically wo…
I'm overall, very happy that it works at all... Some things I'd like to see...
Namely, automatically allow higher thresholds for domains used/provided by dynamic dns providers such as freedns, that have more domains that may want/need to register than limits allow.
Have a more transparent interface for requesting higher thresholds, or for submission of virtual tlds for those domains that offer subdomains to others.
Earlier quoted context omitted.
With Let's Encrypt, the trouble became "Whoaaa I just ran a command and everything works like magic!"
If you're running in a standard config. If your config is nonstandard (you have multiple servers that need a cert to stay in sync, you're not running a common web server, you're on a private network, you're pinning a client to a public key etc.), it's still easy but not a single command. For sufficiently nonstandard setups, it's often easier to do the commonplace email-based verification than make Let's Encrypt work.…
Earlier quoted context omitted.
Any idea what makes it a hard problem? I see nothing that actually explains the issue.
It's because once someone has a wildcard cert they can use it anywhere, in malicious ways: phishing emails that send you to bankofamerica.banking.io or other nefarious type of things.
Unless something has changed, I could also get bankofamerica.com.banking.io, from LE or many other CAs. The wildcard issue has no effect on this situation.