HTTP only is fundamentally disrespectful to your users. It places your needs above theirs. It assumes that your threat model is the same as theirs. There is no excuse for it in 2026.
Can't you get certificates by doing DNS challenges and use those certificates internally? If you don't have to be completely airgapped, doing the DNS challenges shouldn't be too hard.
It is my understanding that DNS challenges are discouraged and/or being deprecated due to the challenge results being less trustworthy than more stringent verification methods. There is also the operational overhead that arises as SSL certificate lifetimes shorten; It is my understanding that there is now a case being made for SSL certificate lifetimes shorter than 24 hours.
I don’t know about the DNS challenge being discouraged, do you have something to read up on that? As far as I know it’s the only common way to get a wildcard cert.
And also the lifetime isn’t a problem in the setup I described, the internal server that uses the cert can do the dns challenge so it can get a new cert whenever it wants. It only needs to be able to access the DNS api.
I must correct myself; The DNS challenge is indeed being discouraged in the future, but it is because the DNS-01 challenge is being replaced by the DNS-PERSIST-01 challenge which addresses deficiencies in DNS-01.
The trust and security issues associated with maintaining intranet resources vs. outsourcing to a dedicated professional cloud service provider remain, but are not related to whether any SSL certificates used are issued through DNS-based verification or not.
DNS challenges are a massive PITA, too. I used them for wildcard certificates but gave up after a couple years because manually renewing them every three months was super annoying.
Unfortunately it is not easy to automate either especially if you use multiple domain providers. Not every hosting has an API and Namecheap wanted $50 for enabling it if I remember correctly.
> It is currently not possible to keep your internal network private and still have HTTPS without hacks or problems on standard end user devices.
Only if you consider transferring the cert from the public server to your internal server a hack.
But how would it ever work otherwise? The CA needs to have some publicly accessible way to check your control of the domain, right?
You need a fake DNS entry on your local network for this to work - I would call that a hack.
And what if you aren't running a public webserver like 99% of normal people out there?
> But how would it ever work otherwise? The CA needs to have some publicly accessible way to check your control of the domain, right?
I mean that's exactly the problem: Why do you have to rely on the public CA infrastructure for local devices?
Consider the scenario of a smart wifi bulb in your local network that you want to control with your smartphone.
IMO it would be great to have your home router act as a local CA that can only issue certificates for .local domains and have that trusted per default by user agents. Would make smart home stuff a lot better than the current situation...
> IMO it would be great to have your home router act as a local CA that can only issue certificates for .local domains and have that trusted per default by user agents. Would make smart home stuff a lot better than the current situation...
How would you talk to the router and make sure the communication is actually with the router and not someone else?
The browser/lightbulb comes with trusted CAs preinstalled, but then you would have to install the routers CA cert on every device you add to the network.
Sure, if someone knows your WiFi password they could set up an "evil" router close to your house with the same SSID and credentials, or they could break into your house and install LAN wiretaps, but c'mon, if you are this paranoid you probably don't even have a smartphone in the first place.
Do you mean that you don’t need a way to verify the routers identity on the local network because it is already protected by a password?
Firstly, I don’t think that’s true because you add a lot of sketchy and unknown devices to your network over time (guests, streaming stick, computer with preinstalled OS…) so I wouldn’t trust every device in my WiFi.
And also, if you do trust your network, you don’t really need https inside it, right?
Took another look at this and it looks like you can set a profile to use for a site in the website settings, Open Links With Profile settings. You have to visit first, but it does seem to work. Unfortunately still limited to a whole new window, which makes the whole thing rather awkward, but more useful that I thought.
Chrome's cache is indeed acting correctly. Effectively, it is acting as an intermediary here - your application made a partial content request, and it can satisfy it (partially), so it sends you a 206.
HTTP partial content responses need to be evaluated (like any other response) according to their metadata: servers are not required to send you exactly the ranges you request, so you need to pay attention to Content-Range and process accordingly (potentially issuing more requests).
But the Content-Range header and the Content-Length header both indicated the "expected" number of bytes e.g. the number of bytes that would have been returned if the server had given a 206 or a 200, not the truncated number of bytes that the response actually contained. Is that expected?
Shouldn't the response header returned by Chrome say "4-138724" then though, and not "4-1943507"? The synthesized response body doesn't include bytes "138725-1943507".
Ah - I need to remember to coffee before posting in the AM.
Yes, the mismatch between the response headers and the content is a problem. Unfortunately, IME browsers often do "fix ups" of headers that make them less than reliable, this might be one of them -- it's effectively rewriting the response but failing to update all of the metadata.
The bug summary says "Chrome returns wrong status code while using range header with caches." That's indeed not a bug. I think the most concerning thing here is that the Content-Range header is obviously incorrect, so Chrome should either be updating it or producing a clear error to alert you -- which it looks like the Chrome dev acknowledges when they say "it is probably a bug that there is no AbortError exception on the read".
The embedded politics of the “t” in “tpm” and “tee” are super interesting and revealing. They are “trusted” only from the perspective of the developer; to the user, they represent the complete lack of trust.
On the contrary, it gives me various ways to determine that my laptop is in a trustworthy state before I type a password into it, and it makes it possible for Signal to verify that the server it's communicating with hasn't been tampered with. It can be used in ways that hurt the user, but it can also be used in ways that benefit them.
I've been lusting after an Ochs und Junior for a while now -- very clever and great design. Implementing complications like perpetual calendars off of workhorse calibres is just amazing.
Today, a group of technical experts involved in the development and maintenance of the Internet and the Web, including Vint Cerf (Internet pioneer) and Tim Berners-Lee (inventor of the World Wide Web), published an open letter calling on the United Nations (UN) Secretary-General and the Secretary-General's Envoy on Technology to "uphold the bottom-up, collaborative and inclusive model of Internet governance that has served the world for the past half century" as part of the upcoming Global Digital Compact (GDC).
I think it's questionable whether they really have.
Especially the openness and bottom-up character of the W3C. They wanted closed source DRM running on people's computers despite presumably strong opposition from the bulk of the ordinary members, and then it got pushed through, and who knows what's in that software.
It's better than Chat Control I suppose, but it's the same sort of thing, i.e. foreign software doing who-knows-what running on a user device.
reply