They have weird semantics, especially in scenarios with multiple prospective validation paths: path `EE -> ICA' -> ICA'' -> TA` might result in different name constraints than `EE -> ICA' -> ICA''' -> TA`, resulting in hard-to-debug validation errors (or successes) depending on the user's trust store state.
(I don't believe that's why Chrome doesn't support them, however. Chrome's stated reason[1] is that they don't support them on user roots because RFC 5280 doesn't require them to, which is IMO a correct reading of the spec.)
[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=107208...
Dockerfile:
``` FROM certbot/certbot RUN pip3 install certbot-dns-cloudflare cloudflare ```
docker-compose.yml:
``` volumes: - ${CREDENTIALS_DIRECTORY:-.}/cloudflare.ini:/cloudflare.ini - ${STATE_DIRECTORY:-./certbot}/:/etc/letsencrypt/ - ${LOGS_DIRECTORY:-/var/log/certbot}/:/var/log/letsencrypt/ command: " \ certonly \ --non-interactive \ --agree-tos \ --email [email protected] \ --preferred-challenges dns-01 \ --dns-cloudflare \ --dns-cloudflare-credentials /cloudflare.ini \ --dns-cloudflare-propagation-seconds 30 \ -d foo.bar,*.foo.bar" ```
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.
It's well supported now. I use it and it works for OpenSSL, Firefox, and Safari.
Personally, I don't think there's much to gain from using public PKI for internal infrastructure. I already manage secrets on my personal devices and this is no different. Also, being able to issue certs for .home.arpa domains is nice too.
Lets Encrypt offers wildcard certificates, there is no reason to have internal DNS records exposed.
> An obvious downside of this is having to guard a bunch of secrets and the need to rotate the host certificates yearly – because Apple says so.
The guarding secrets thing makes me too uncomfortable with managing my own CA. I'm sure it'd be fine, but since there are other equivalent and safer ways to do it.. Name constraints are a thing in the spec for restricting your CA to specific domains (which is amazing,) but browser/etc support was crappy when I looked at it and maybe getting better? I don't understand why name constraints aren't implemented everywhere. Unless an enterprise environment is doing TLS inspection, name constraints are a way saner implementation.