Some browsers (notably Firefox) used to support multiple wildcards, but then again it also trusted domain certificates signed by other domain certificates for years, so that's not much to go by. These days, I don't think a single browser will accept ..foo.bar.
Is it? I thought browsers treat localhost/127.0.0.* specifically as if it were served over https, even if it isn't - otherwise, you could basically forget developing anything locally.
Is there any feature which doesn't treat localhost as a secure origin?
I figure you can always buy a hostname, get a cert using the DNS-01 challenge, then resolve the domain to 127.0.0.1 though - or getting back to the OP and running a custom CA.
If you develop locally and it’s only HTTP with no HTTPS, then I think it works.
To my knowledge, https on loopback doesn't give you any kind of added security: Everything with enough privileges to capture the encrypted packets on loopback also has enough privileges to just capture the unencrypted memory directly. And "localhost" is also a single "domain", so a cert wouldn't even give you the ability to distinguish between different origins (as other ports or hostnames that resolve to 127.0.0.1 would do)
So it's just some buerocratic hoops to jump through to satisfy browsers.
Edit: I remember reading about some objection that the "localhost" domain could be resolved to something other than 127.0.0.1, either through the hosts file or through a faulty DNS resolver.
To my knowledge, those objections were addressed in the "let localhost be localhost" proposal which mandated that the hostname "localhost" must be hardwired to 127.0.0.1 in the OS/browsers/resolvers etc and must never be permitted to point to anything else.
But maybe this proposal didn't gain traction and so browsers are defending against such rebound localhost domains.
In that case, I'd try and check if "http://127.0.0.1" works, as the IP address can't be rebound in the same way as the hostname.
If you have the web server's private key, you can decrypt the traffic, but only if PFS ciphers are not used.
It is a common misconception that knowledge of CA keys allows you to decrypt traffic. It does not. It allows you to issue valid certificates. It's only used for signing.
It's the webserver's key that protects the traffic. The webserver's operator has that key regardless of who the CA is. In the case of PFS cipher suites (eg EDH) an ephemeral key is used for confidentiality and the endpoint keys are just used for integrity and key authentication. Even with the webserver key you aren't decrypting those streams.
In no case does the CA private key help you decrypt traffic.
Of course it does. You just generate certificates for every TLS handshake you see and MitM them.
And yes, it works for PFS too. There is no difference for MitM.
> In the case of PFS cipher suites (eg EDH) an ephemeral key is used for confidentiality and the endpoint keys are just used for integrity and key authentication. Even with the webserver key you aren't decrypting those streams.
You never encrypt data with a key from certificate, even without PFS. That would be too slow. You generate a pre-master key and then use it to generate keys for symmetric algorithms, like AES or Chacha20, that are actually used for data stream encryption. The only difference between PFS and non-PFS is that in the former case pre-master is generated using some form of DH, with promise of keys being destroyed after some time, and in the later case, client just generates a random key, encrypts it with the public key and sends it to the server.