41–50 of 166 posts
Earlier quoted context omitted.
Why? Is there something wrong with HN's current cert?
1. Funds Comodo's shady behaviour, and arguably increases their brand recognition 2. Ridiculous expiry time
Looks like a cert is similar to a President. Should be around for 5 years.
It's about time that HN switches to Let's Encrypt.
It's a lot more work to switch an existing cert environment to LE than to start from zero.
Just to be clear, this is important because eventually Let's Encrypt wants to no longer have to cross-sign their certificates for them to be considered valid. For that to happen they have to be added as a trusted CA in most major platforms (and Firefox which has their own CA store for some reason).
Firefox has it's own CA store because it's built for all 3 major (desktop) platforms. OSX and Windows have their own but Linux does not and uses Mozilla's.
Earlier quoted context omitted.
Let's Encrypt is pretty great, but if you have the money get a paid SSL. Not all SSL certs are created equal.
> Let's Encrypt is pretty great, but if you have the money get a paid SSL. Not all SSL certs are created equal. Say what? Besides the faux security of the green bar for an EV cert, what's the difference between a LetsEncrypt and a paid one? (non-EV)
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.
https://docs.sandstorm.io/en/latest/administering/wildcard/#...
The one thing stopping adoption for a lot of people is wilcard support. https://community.letsencrypt.org/t/please-support-wildcard-...
I spoke about this earlier this week at a meetup. The consensus in the group was that wildcard certificates are desirable because they're easier to manage. If your tooling is good, the automation afforded by ACME can invalidate the need for wildcard certificates.
That's probably good enough for almost everyone who uses hostnames to represent physical machines or services. But it's totally unusable if you want to create certificates on the fly in response to user signups.
Excellent news. The more trust the better. It's still no good using LE for API endpoints as many client libs (java, etc) don't trust it or it's cross-signer.
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.
Let's Encrypt is pretty great, but if you have the money get a paid SSL. Not all SSL certs are created equal.
> Let's Encrypt is pretty great, but if you have the money get a paid SSL. Not all SSL certs are created equal. Say what? Besides the faux security of the green bar for an EV cert, what's the difference between a LetsEncrypt and a paid one? (non-EV)
Earlier quoted context omitted.
> Let's Encrypt is pretty great, but if you have the money get a paid SSL. Not all SSL certs are created equal. Say what? Besides the faux security of the green bar for an EV cert, what's the difference between a LetsEncrypt and a paid one? (non-EV)
Heads up: I work for a company that speeds up the background checks used for EV. Tying real world identities to public keys is very much a part of crypto. Windows does it with package signing and EV, Debian does it with people holding up their passports at Linux events, and web sites do it with EV HTTPS. And yes, we (CertSimple) are looking at Certbot support for EV.
https://www.ssllabs.com/ssltest/analyze.html?d=certsimple.co...