31–40 of 60 posts
I'm a bit confused the benefits? Caddy already makes Let's encrypt incredibly easy. I use the CloudFlare DNS provider, so don't even need to expose port 80 for http verification.
Earlier quoted context omitted.
We theoretically could, but those certificates would show up in CT logs. (For quick & easy monitoring, you can get an RSS feed for your domain on https://crt.sh/ , but it's not the most reliable service.) It would be a reputation killer if we did that, just like it would be for your DNS provider or ISP.
Right, but if you want people to trust you, you need to be open about what people are trusting you with. Your original answer seemed obfuscatory.
With this we could issue or revoke a new certificate, but we couldn't impersonate them because we don't control the rest of their DNS.
myawesomedomain.com {
respond "You just loaded this on https"
}
Or just use caddy as a reverse proxy [0]. This 1 line will do it all for you: myawesomedomain.com { respond "You just loaded this on https" } [0] https://caddyserver.com
Oh dear. I'm sorry. But do you really need to re-invent the wheel yet again ? Go to the Let's Encrypt website, there is a whole page of client implementations[1]. What makes yours better than, for example, `lego` or `caddy` or `step` ? All of which are easy to use, come with sensible defaults and do not provide you with "innumerable ways to shoot yourself in the foot". And for people who really can't use Let's Encryp…
ACME is great and it's certainly an improvement over the legacy CA alternatives. But there's also some rough edges that we think can be streamlined.
Earlier quoted context omitted.
> * If you want an SSL certificate for, say, your printer Ummmm why does my printer need a certificate?
If you can't trust your network, you'll want encryption, regardless of devices on it.
I’ve never understood why there isn’t an easy way (ie that never expires) to use certificates or otherwise encrypt communications. I’m mainly referring to unique or internal use cases where the complications around certificates expiring has made it so that those communications end up unencrypted (SSL disabled). I guess what I’m saying is I’ve come across many cases where even bad encryption is better than plaintext,…
For an internal use case, nothing's stopping you from setting up your own CA, creating certificates that don't expire for 100 years, and telling your clients to trust them. It just takes a couple of OpenSSL commands which, while slightly complicated if you don't know what you're doing, can be easily automated with a shell script. The browser limits on maximum certificate lifetimes only apply to the public web PKI, no…
When creating your CA certificate you can hop into the Advanced tab and add the following line to constrain it to specific domains. This eliminates the risk of your likely-poorly-secured CA being abused to MITM all of your communications:
nameConstraints=critical,permitted;DNS:.home.internal
Or just use caddy as a reverse proxy [0]. This 1 line will do it all for you: myawesomedomain.com { respond "You just loaded this on https" } [0] https://caddyserver.com
I only recently got into Caddy after using Apache and later Nginx for decades, and it's almost disappointing how little configuration it needs. It's very refreshing that we finally have a web server that needs hardly any fiddling with b/c it has nicely sane and comprehensive defaults.
Earlier quoted context omitted.
Right, but if you want people to trust you, you need to be open about what people are trusting you with. Your original answer seemed obfuscatory.
Sorry, not trying to obfuscate anything, hopefully this clarifies: users trust us to hold their ACME account key and we only ask for DNS records prefixed with `_acme-challenge.` to be CNAME delegated. With this we could issue or revoke a new certificate, but we couldn't impersonate them because we don't control the rest of their DNS.
If that were true, nobody would need signed certificates in the first place.
I’ve never understood why there isn’t an easy way (ie that never expires) to use certificates or otherwise encrypt communications. I’m mainly referring to unique or internal use cases where the complications around certificates expiring has made it so that those communications end up unencrypted (SSL disabled). I guess what I’m saying is I’ve come across many cases where even bad encryption is better than plaintext,…
> I guess what I’m saying is I’ve come across many cases where even bad encryption is better than plaintext Where is this? Why would bad encryption be better than plaintext? I can't imagine a scenario where this is the case.
This is strictly better than plaintext as a passive eavesdropper cannot listen in; an active attack is needed.
I wrote much more here: https://alexsci.com/blog/is-email-confidential-in-transit-ye...