Earlier quoted context omitted.
I think you’re talking about running DNS locally (not sure) and resolving .local addresses by DNS. In that case, yes, the devices that do lookups by mDNS will experience a delay caused by first querying mDNS before falling back onto DNS. The solution is to set up mDNS for the internal resources. Using an unregistered domain like .lan has serious security implications. See here: https://serverfault.com/a/17566
.lan is called out in appendix G of the MDNS RFC as "not recommended, but many people do this". Personally speaking, I'm not too worried about .lan getting registered as a gTLD anytime soon. I'm a lot more worried about forgetting to renew my domain and having things horrifically break if/when that domain gets picked up by someone else. This is a lot more likely...
Chromium and Mozilla to enforce 1 year validity for TLS certificates
371–375 of 375 posts
Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates
#372I’m so torn here. Personally I like this a lot and think it will really help enforce good practices and allow easier things like root/int key rotation. Professionally it sucks, as there are a ton of valid use cases for real certs in areas that require manual work and tracking them all is a hard problem. If internal PKIs were easier to make work across all OS and Browser combos I’d just use those instead.
> If internal PKIs were easier to make work across all OS and Browser combos I’d just use those instead Even if you use your own PKI, if your certs have a validity > 1 year, won't browsers still complain?
Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates
#373Earlier quoted context omitted.
Check out Certera https://docs.certera.io It's PKI for Let's Encrypt certificates. Helps you issue, renew, revoke certs from a central place. Also get alerts so you know when things have changed, expired, failed to renew. While a lot of places give you certs built in, there's a whole world of places you still need certs. Like FTP, mail, behind load balancers, disparate environments and systems, etc. In the future, I'…
This looks interesting as a log of Let's Encrypt certificate operations, but is it more than that, and why would I want to use it?
Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates
#374Earlier quoted context omitted.
This looks interesting as a log of Let's Encrypt certificate operations, but is it more than that, and why would I want to use it?
To centrally manage all of your LE certificates, keys, alerting, etc. You can also more easily use LE certs in a wider array of scenarios too. Check out the docs to learn more.
I'm still a bit fuzzy on this - why would I want alerting, for example? Automation is a big part of LE, and my certs are configured to auto-renew. If that was to fail for some reason, then LE will send me an email - is it this part where this tool comes in, providing improved alerts where automation has failed?
Re: Chromium and Mozilla to enforce 1 year validity for TLS certificates
#375Earlier quoted context omitted.
To centrally manage all of your LE certificates, keys, alerting, etc. You can also more easily use LE certs in a wider array of scenarios too. Check out the docs to learn more.
I did have a look at the docs, but they more explained the how , rather than the why - I missed some kind of intro/overview explaining the value proposition. I'm still a bit fuzzy on this - why would I want alerting, for example? Automation is a big part of LE, and my certs are configured to auto-renew. If that was to fail for some reason, then LE will send me an email - is it this part where this tool comes in, prov…
To elaborate on the why for alerting, there are many situations that I've seen where things change and subsequently fail silently. Perhaps some dependencies, or maybe configuration changes, caused things to break. Also, alerting doesn't only have to be for your certificates. You can point to any endpoint to monitor as well. There are three aspects of alerting: changes to the cert (perhaps you care about a 3rd party certificate and its underlying key changing), failure to renew, and expirations. Each comes with its own benefits and use cases.
To expand on the why a bit further for the project as a whole, it's really as a way to help consolidate and centralize things. I've seen many disparate ways of using Let's Encrypt. From various clients to some hacks to better support more complicated scenarios. By separating obtaining the certificate from applying, it helps facilitate many things, like using LE certs behind load balancers & proxies, non-standard ports, things that don't speak HTTP, etc.
If certificate expiration continues to decrease in time, we'll need some capabilities to exchange certificates in an automated fashion as well. I'd also like to incorporate Certificate Transparency logs so you can be sure no one has issued certs for your domain(s). There are many cool and interesting scenarios but mostly the challenges come when managing things at scale. So, it's not really all that useful if you're only managing one or two certs.