Then use DNS-01. If clients can connect via globally valid hostnames, then you can make the challenge name available in DNS and use that for verification.
wait what UNTIL A MONTH AGO?!?
why would it be a mis-issuance if a higher domain's owner (except for public suffixes) is getting a cert for a lower level domain?
That is something CLEARLY different.
I agree that webvalidation should no go to subs
I actually made an issue at the acme wg for that.
what also would be nice and make stuff easier would be allowing just the acount keys (you need signatures from them anyway so why make it more complicated than it needs to be?
which is sad if you only have a subdomain.
usually you get a bunch of the *master and admin mail addresses OR the one that's in the whois (perfect for ppl who dont have a webserver running on that domain)
exactly.
guess why I prefer DANE/TLSA (okay but then all names would be needed on the DNS, not good for internal stuff)
but only if the validation is "good enough" (http-01 is certainly not.)
Yes, while issuance for internal names/IPs was stopped back in November 2015, existing certs could remain valid until October 2016 when they were all revoked.
dafaq lol, but then again why should internal names be a problem in the first place if they cant even be used in the internet (I mean specific names that cant be domains like anything without a dot or not having a valid tld in the first place)
Because of man-in-the-middle attacks. Since internal names are pretty much impossible to validate, an attacker could get a certificate for âexchange.corpâ and then MitM users with a rogue hotspot and intercept traffic and credentials.
I don't see why it isn't good enough. It doesn't matter where you validate it from, www or dns, its still the same string that gets validated.
Supporting both would be epic.
For wildcards? The person or people who have write access to the website may not have permission to get certificates for other server or service names. The person or people with DNS edit access have the ability to set up any authorization anyway.
1 Like
Sorry mate, this is a strawman argumentâŚ
And we have a winner.
not really. (honestly I dont like HTTP auth in the first place)
if I let someone do the website for me, he shouldnt have the ability to make certs for e.g. my email server and whatnot.
and even I who is provenly for easier usage in many ways (make wildcard certificates or at least wildcard validation e.g. for DNS, make a year certs possible and whatever) get that it's a bad idea to to wildcard certs or even validations over http-validation, then I think it shouldnt be THAT wrong.
I even specifically mentioned for example instead of posting random data at the DNS http or whatever that the protocol could instead just use the accountkey, meaning ou wouldnt have to mess with the challenges everytime, because you need to prove your key to LE anyway, meaning the verification challenge just makes it unnessecarily (I hope I wrote the word right) complicated.
How is it so? I know several orgs where the people managing the main website but aren't exactly authorized to gets certificates for the mail servers or other things. The old method of e-mail validation at a defined account (hostmaster@, etc.) at least made sure that a valid request would have to be approved by someone who managed the core domain. That cannot be relied on with methods like checking for a file on a website. You need to verify against infrastructure, not a single service if you want to make sure the requestor at least has control over the whole domain and all sub names.
and that is exactly why I dont like http auuth in the first place.
It's not bad for authenticating a single name, like how LE is doing now. I would argue that it's very inadequate for verifying control of anything other than that name.
Taking this back to the topic of StartSSL, they did only e-mail validation of defined or WHOIS-found addresses (without OCR) until the WoSign acquisition.
so anything else came only after wosign did stuff?
well I personally like the email validation a lot especially because startssl also does the whois mail meaning you dont have to keep a mail server ready for the certs
Yet that is your choice as the domain owner.
This is a policy problem - not a technical one.
Its only really suitable for certs longer than 90 days though.... Otherwise you're doing things manually again for every renewal...
of course, (unless you can automate the email stuff 
)
well jokes aside one thing that also may help is keeping the validation longer than just for the small timeframe the cert is issed in, meaning you dont have to do too much stuff for getting more certs.
It seems like the only fix for this would be to have a DNS-based "I trust all subdomains for TLS, we're cool" flag. Then LE could look at that and say oh, cool, we'll issue whatever you want based on top-level auth. But there's nothing in DNS like that, I believe, or anyone trying to get it in place.
Basically, no one has bothered to solve the issues brought up, instead hoping LE will just handwave them away. LE obviously won't do that, and despite that people just keep bringing up the same tired old arguments, instead of finding a way to fix the well-understood problems with their wants.
well I did bring up a way that could be used at an even higher level than LE, the acme (protocol used by LE) spec just check #14 where I posted links to stuff that could do something.
although sadly I didnt get much response yet.
I wonder if its something that could gain traction?
well it would be epic. because it would remove the requirement to mess with anything, and allows the client to run alone.