181–190 of 197 posts
The biggest issue we've had is the short expirations. We have 51 certificates in our organization and do not want to rely on auto-renew. As our community project, we built a totally free to the public service to monitor certs and alert you when they get close to expiration or are invalid, etc: https://letsmonitor.org Feel free to use it for any certs.
While registering, I noticed timezone as "Indian Time". It should be "Indian Standard Time(IST)".
Earlier quoted context omitted.
But *.a.com doesn't cover a.com, so it's not very clear that the inverse ownership relationship should hold. Yes, it's true on a DNS level but that's one argument I would imagine against doing it that way.
No, but ownership of a.com heavily implies ownership of (wildcard).a.com (HN is being weird with the asterisk) Alternatively they could just do a DNS check. If you can configure DNS for a.com, you control *.a.com.
"heavily implies" is too low of a bar to make it safe for a CA to provide wildcard certificates through an entirely automated process. While they could do it, they care enough about security to make the decision not to.
> If you can configure DNS for a.com, you control *.a.com.
This assumes that if you can create a TXT record for a.com that you must also have access to the ability to create other records for a.com.
While it is a stretch, I would say that the only bar sufficiently high would be fulfilled is forcing an administrator to prove that they can change the NS records for a domain. Which I don't believe would be a practical thing to test, and might run into problems with things like cloudflare.
Earlier quoted context omitted.
No, but ownership of a.com heavily implies ownership of (wildcard).a.com (HN is being weird with the asterisk) Alternatively they could just do a DNS check. If you can configure DNS for a.com, you control *.a.com.
> heavily implies ownership "heavily implies" is too low of a bar to make it safe for a CA to provide wildcard certificates through an entirely automated process. While they could do it, they care enough about security to make the decision not to. > If you can configure DNS for a.com, you control *.a.com. This assumes that if you can create a TXT record for a.com that you must also have access to the ability to creat…
Yup! And LE is totally fine with this! Have you read the ACME DNS verification spec?
SSL certificate from a traditional provider valid for a year: $10. SSL certificate from a traditional provider valid for two years: $20. Automated SSL certificate generation and deployment via LetsEncrypt with zero human intervention and more importantly zero human intervention to renew it going forward - priceless . --- That's the real value for me. At $10/cert, that's not even a rounding error. But manually generat…
The LE protocol is fully open and even specified in RFCs - I wonder if any paid cert providers will ever move to that type of painless automated renewal (plus automated billing, of course). This would allow folks to potentially get their "advanced" certs (EV, wildcard, crossdomain, etc.) renewed without the rigmarole that you mention (although some cert categories come with their own non-automatable processes). Right…
Also keep in mind that if you're a big customer the big CAs already had products where things are streamlined for you, so the annoying experience you get as a small operator is not necessarily happening at scale for a large corporation like, say, Disney.
Earlier quoted context omitted.
The LE protocol is fully open and even specified in RFCs - I wonder if any paid cert providers will ever move to that type of painless automated renewal (plus automated billing, of course). This would allow folks to potentially get their "advanced" certs (EV, wildcard, crossdomain, etc.) renewed without the rigmarole that you mention (although some cert categories come with their own non-automatable processes). Right…
EV certificates are not allowed to be renewed automatically AFAIK.
For the Domain Name Validation (which is the main thing web browsers and several other kinds of software care about) this is done by one of the 10 Blessed Methods. ACME automates three of those ten methods. Some others can't be automated (e.g. get a bona fide lawyer to sign a physical paper document saying they've checked you really own the DNS name)
EV requires also validating the Subject entity's name and place of business. This cannot be entirely automated today. But some CA issuers specialising in EV get very close, like an hour turnaround in most cases for businesses in places where they operate.
The intent in ACME is that semi-automated processes would be handled to one side of ACME, you'd do them offline, and you'd gain "authz" which are how ACME tracks validation, for the things which had been validated offline.
Also, it's not necessary to re-validate everything for every new issuance. Suppose you prove you're really EXA Metal Pole Location Executives, business #123123123 of Some City, Texas. A CA would be entitled to rely on having validated that for some time, I think it's currently up to three years. In that time you could issue and re-issue hundreds, even thousands of certificates with no extra fuss.
SSL certificate from a traditional provider valid for a year: $10. SSL certificate from a traditional provider valid for two years: $20. Automated SSL certificate generation and deployment via LetsEncrypt with zero human intervention and more importantly zero human intervention to renew it going forward - priceless . --- That's the real value for me. At $10/cert, that's not even a rounding error. But manually generat…
What's the justification of traditional providers to charge for the certificates? Do they offer services or extended certificates that "Let's encrypt" doesn't or is it just a matter of "no one tried to offer it for free before"?
BUT, being _able_ to make certificates is very expensive. ISRG (the charity behind Let's Encrypt) spends _millions of dollars per year_ on this.
Purely mechanically Let's Encrypt needs a data centre with a bunch of high availability servers and pretty good Internet access, employees to look after all that stuff, a deal with CDNs to serve up their OCSP responses around the world (which ensure certificates stay working after they're issued) and so on, none of which is cheap and all of which needed to be in place before issuing even one certificate.
In practice to be any use the certificates need to be trusted, which meant meeting the standards of the big Trust Stores (definitely Apple, Microsoft, Mozilla, probably Google, Oracle, and ideally dozens more besides). Those standards require physical site security, regular third party audits, and so on, which cost even _more_.
Now, for Let's Encrypt the solution is this is a charity, you can pitch in $10 and if a hundreds of thousands of people like you do that then it all gets paid for, or if a few bigger organisations pitch in $1000 each that helps too.
But for a commercial outfit, well, why not charge $10 to cover costs? And if $10, why not $50? Why not $1000?
Earlier quoted context omitted.
> Even people with not a lot experience can secure their sites and apps, and it just works. Yes, you have to update it every three months, but that's worth the price and the excellent documentation. This is just a cronjob, no?
I now just run all of my sites behind Caddy which takes care of cert renewals for me. Can't recommend it enough!
I still wonder how Let's Encrypt works. I understand that the problem they solve: A user wants to get the public key for a certain domain. So he knows he is talking to a server by the domain owner and not some man in the middle. So he asks a third party whos public key he already has. In this case Let's Encrypt. Ok. But how did Let's Encrypt get the public key from the domain owner? I know they make the domain owner…
> A user wants to get the public key for a certain domain. So he knows he is talking to a server by the domain owner and not some man in the middle. > So he asks a third party whos public key he already has. In this case Let's Encrypt. Ok. It works quite differently -- the browser doesn't have to talk to Let's Encrypt at all to verify correctness. How it works: 1. Browser connects to the server 2. TLS handshake, cryp…
The CSR is a signed data structure that says "Hi, here's my public key K1, and I want you to issue me a certificate with properties P1, P2, P3 for names N1, N2, N3" and it's signed using a private key K2.
Using K1 (which is right there in the document) we can check that the K2 signature matches. If not, we can't be sure the real owner of K2 even wanted this certificate and we must reject it.
Then we can look at the list of P1... and N1... and decide if we want to issue a certificate at all. If we do, we can choose to issue any certificate we want, we don't need to issue exactly the one described in the CSR.
This is important because many CSRs, whether generated by well-meaning admins or automatically by an appliance or service, are full of crap that Let's Encrypt doesn't want to, or isn't permitted by the Baseline Requirements to sign.
[ e.g. it's very common for CSRs to claim that London is in a County called Middlesex. Nope, that county was abolished decades ago, London isn't in a county at all, but people see a field labelled "State or County" and they figure they should write something in the box. If a CA signs that, they're claiming Middlesex still exists. ]
By constructing each certificate from first principles after examining the CSR, Let's Encrypt can ensure they sign only certificates for exactly the things they've validated, nothing else.
Earlier quoted context omitted.
> A user wants to get the public key for a certain domain. So he knows he is talking to a server by the domain owner and not some man in the middle. > So he asks a third party whos public key he already has. In this case Let's Encrypt. Ok. It works quite differently -- the browser doesn't have to talk to Let's Encrypt at all to verify correctness. How it works: 1. Browser connects to the server 2. TLS handshake, cryp…
Nit pick: Although toy systems work by "just" signing the CSR a real CA like Let's Encrypt basically throws the CSR away after verifying its integrity. The CSR is a signed data structure that says "Hi, here's my public key K1, and I want you to issue me a certificate with properties P1, P2, P3 for names N1, N2, N3" and it's signed using a private key K2. Using K1 (which is right there in the document) we can check th…
Earlier quoted context omitted.
Currently their only upside is that they provide wildcard (and EV) certificates. EV certs can't be automated for obvious reasons, but LE doesn't support wildcard certs because they don't believe there's a secure way of providing an automated way of getting them. Given that traditional CA models don't actually have much more security than LE (in fact from personal experience they're far less secure), I wonder whether…
One annoying thing I've seen less technical stakeholders ask about with letsencrypt is "why the padlock isn't green" in Safari/Edge. Unlike Chrome and I think Firefox, those browsers only display a green padlock for SSL certs with EV, which of course letsencrypt doesn't (and arguably can't really) do. The "grey padlock" for an otherwise perfectly valid certificate seems to confuse a very small subset of users, especi…
It's not so much about browser-specific behavior, it's about using the padlock to ensure that the company or other entity you're interacting with is the one you wanted, as opposed to only ensuring that the server you're talking to is the one indicated in the address bar.
A gray padlock is better than none, but telling less technically-inclined, clicks-all-the-links, fat-fingered users to trust them outright may not be the best idea now that you can go get bankofomerica.com, dress it up to look like BoA's site, and put a gray padlock on it for free.