61–70 of 263 posts
Earlier quoted context omitted.
Doesn't ownership of domain.tld also imply ownership of *.domain.tld?
That's the relatively simple case, but there are a number of corner cases that make the process much more complicated. See https://github.com/letsencrypt/acme-spec/pull/97 for a discussion of why this was scraped from the ACME specification proposal.
Earlier quoted context omitted.
> This is not what regular style certificates verify. That is what Extended Validation certificates verify and they're not issued by letsencrypt.org and generally are a lot more expensive. I'd like to see LetsEncrypt move into this territory though. What current private business providers are charging for this service is border-line extortion.
FWIW, you can already get an SSL cert for $4/year.
It's amazing that it takes a free provider to make things simple: https://letsencrypt.org/howitworks/ I'd actually pay more than I do now for SSL certs to get that kind of simplicity.
Earlier quoted context omitted.
Any CA performing domain ownership validation would be vulnerable to the same thing. If you can fake its WHOIS requests or make it appear as if the domain making the request does in fact have the "canary" file they told you to host to prove ownership, then you can get any CA to give you a cert for any site. You have to trust something .
Agreed - but by making this a fully automated system you open up an easily testable and repeatable source of attack. I don't think "You have to trust something" is really right in this case, as you're basically saying "You have to trust every single router between letsencrypt and every server on the internet". I guess it's correct that with most current CAs now automating a lot of this with minimal manual checks, thi…
There are Extended Validation (EV) certs where a human verifies your ownership of a legal entity. Chrome presents these as a big green bar with the name of the corporation in the URL bar. Most certs (including Amazon's) are not EV certs.
Earlier quoted context omitted.
If the registrar held the job of being a CA, then at least there wouldn't be a spoofable link between the CA and the domain owner - the registrar already has your account information and proof of ownership, 100% verified, when your domain is held with them...
Sure, but registrars would need to start doing a lot better job of checking the identity of people applying for domains, otherwise we'd just end up with domain validated certificates all over again. As the grandparent post notes, all CAs completely automate domian validation at present.
Sure, you could have the other CAs still offer EV (real-world identity) validation as a value-add.
But it's pretty silly that, currently, you have to pay a third party (today's CAs) to validate something that the registrar already knows for sure.
Does anybody know if there is any protection built in against MITM or DNS poisoning attacks? It feels like this makes network hop security far more important. If I'm able to insert a MITM or DNS poisoning anywhere between where letsencrypt.org's servers are and where it thinks the requesting server should be then I can generate a false certificate. For example, Amazon's DNS resolves for letsencrypt as 1.2.3.4 which r…
a. if we know of an already existing certificate for the domain that is being authorized you must prove control over both the server and the key used in the existing certificate
b. validation is done over multiple paths to confirm results, an attacker would need to be able to hijack connections from all of our validation servers in order to cause miss-issuance (servers which would move over time)
Currently (a) is mostly implemented but (b) needs quite a bit more work before it can go live.
Earlier quoted context omitted.
This is not what regular style certificates verify. That is what Extended Validation certificates verify and they're not issued by letsencrypt.org and generally are a lot more expensive. The only thing that regular-style certificates verify (this is what current CAs do, you can also grab a free one with automatic validation at https://www.startssl.com/ ) is that the person who controls the domain name has requested t…
Well. I missed that memo. Or rather I kinda sorta knew it was getting devalued, but a Padlock in my browser is something I trust . If it's not trust worthy or verified should we not go the whole hog, dump trusted public keys from all browsers and move to the web-of-trust / certificate pinning. From the blog: just too much of a hassle. The application process can be confusing. It usually costs money. It’s tricky to in…
On the padlock note, Microsoft Edge shows a hollowed out, grey padlock for DV certificates.
Only EV certs get a full green one (as well as the legal name as other browsers show for EV). See https://certsimple.com/blog/dv-ssl-in-microsoft-edge
Earlier quoted context omitted.
I don't understand what it is we should "beware" of? What's the perceived threat? In theory, even if the NSA themselves were creating these site certificates, because of how they're created (i.e. you generate the keyset yourself locally, they sign the public part), it should be secure. So as I said: What is the perceived threat condition here?
> because of how they're created (i.e. you generate the keyset yourself locally, they sign the public part), it should be secure. Note that if the CA has the authority to sign certificates, they don't need your private key. They can just locally create a CSR for your domain, sign it, and have their own equivalently valid certificate for your domain. Moreover, in the absence of HPKP, any CA can do this for any domain.
Google requires CT for all EV certs.
Earlier quoted context omitted.
Looking at http://helloworld.letsencrypt.org/ I see: > Let's Encrypt hasn't yet been added as a trusted authority to the major browsers (that will be happening soon), so for now, you'll need to add the ISRG root certificate yourself. Specifics will depend on your browser. In Firefox, just click the link.
Ah, that is a bit misleading. When it says "just click the link," it's referring to the process for installing the root certificate. It should read "specifics will depend on your browser. In Firefox, just click the link [to the .der file, and you will see a prompt allowing you to trust it.]" It looks like this: http://imgur.com/dzC89xI Without importing the root, Firefox absolutely distrusts https://helloworld.letsen…
> IdenTrust will cross-sign our intermediates. This will allow our end certificates to be accepted by all major browsers while we propagate our own root.
The cross-signature is expected to happen before the mainstream browsers finish processing our application to be a root CA. That will be the main initial mechanism by which browsers trust our certificates.