Remix clone Hacker News

The whole PKI concept is dead anyway. Users have been trained to bypass certificate warnings by CA store wars between browsers and OSes, MitM corporate SSL proxies a-la ZScaler / Intune, corporate self signing CAs for intranets and whatnot, blindfolded public CAs giving certs to whatever.

▲

peanut-walrus 3 days ago | parent [-]

What? When was the last time you had to bypass a cert warning because of "CA store wars" (whatever that means)? What examples can you give for public CAs giving certs to "whatever"?

▲

Galanwe 3 days ago | parent [-]

> When was the last time you had to bypass a cert warning because of "CA store wars" (whatever that means)?

Essentially all the time for the last 10 years...

Did you ever try to deploy a website with a certificate from a non public CA? Like, say, your company CA?

If you want it to be valid for Java users, you will have to store your CA cert on the Java trust store.

Want it available for users of Firefox ? Store it in the OS certificate store.

Want it available for Chrome users? Store it in the Chrome certificate store.

Want it available for Python users? Add it to certifi.

And so on.

No single piece of software validating certificates agree on a single CA certificate store.

So, essentially, no company out there supports all these stores, and you just train users to bypass these warnings.

> What examples can you give for public CAs giving certs to "whatever"?

There have been dozens of CAs removed from widespread trust stores for failing to do proper diligence or reporting leaked keys.

Not only that, but essentially I never myself to do any kind of diligence for whatever certificate I requested from public CAs beyond proving I had TXT records update powers at some point in time.

I'm not even mentioning fortune 500 websites running with expired certs.

▲

LiamPowell 3 days ago | parent [-]

> So, essentially, no company out there supports all these stores, and you just train users to bypass these warnings.

This just sounds like a problem with your company. The barrier for getting certs from a public CA is lower than ever now that Let's Encrypt and others exist. If you really must have a non-public CA then your company needs an IT team that can properly manage that.

This isn't an issue for normal users.

▲

Galanwe 3 days ago | parent [-]

> This just sounds like a problem with your company.

I have seen that pattern in enough companies to be convinced this is widespread.

> The barrier for getting certs from a public CA is lower than ever now that Let's Encrypt and others exist

I don't think you understood what I'm talking about. Public certificates are cute for your public website, but any sizeable company is _also_ hundreds of internal websites and services, especially for the non IT departments. Think legal, compliance, accounting, HR, etc.

Most companies use a private CA for these, and that makes sense:

- You want subsigning CAs for your VPN, contractor services, websites, teams, etc.

- You want private DNS to private IPs (lots of ISPs won't even serve your private IPs through their DNS caches)

- etc

> If you really must have a non-public CA then your company needs an IT team that can properly manage that.

On the contrary, managing private CAs is what most companies do _well_. What they don't (and honestly nobody can) do well is distribute CA certs to user devices. This is often not done right on work devices, but BYOD made it even worst. No company can distribute its CA certs on the hundreds of different stores that one could think of, so after 2 years, some benign change of default corporate browser for users ends up with them learning to auto bypass certificate warnings.

▲

LiamPowell 3 days ago | parent [-]

> You want private DNS to private IPs

Nothing stops you getting a cert while pointing your DNS records to internal addresses. The DNS-01 challenge exists to serve exactly that kind of configuration.

> lots of ISPs won't even serve your private IPs through their DNS caches

I have never seen this, could you give an example? However, if this is an issue then there's nothing stopping you from just using your public DNS for DNS-01 challenges and using your internal DNS for everything else.

It is also impossible for your ISP to do this if you're using DoH or DoT, which you really should be, especially if you already know that your ISP is messing with DNS traffic.

> You want subsigning CAs for your VPN, contractor services, websites, teams, etc.

You can't do this, but you can have your own ACME server that forwards requests to a public CA if you really need to let different teams manage their own certs. A better option is probably to use one of the paid CloudFlare tiers where you can create scoped API keys that provide DNS editing access scoped to a subdomain, or you could of course host your own DNS server or find a different DNS provider that offers this service.

▲

cj 3 days ago | parent | next [-]

We have a team who uses a ".dev" domain for local development (with a publicly issued SSL cert), with an A record of 127.0.0.1.

We had someone new join the team and couldn't get the dev environment working. Turns out his ISP's DNS wouldn't resolve to an internal IP. Simple fix was updating his system DNS away from his ISP. We only saw this happen to one person, so wouldn't say it's common but it happens.

	▲	andrewaylett 3 days ago \| parent [-]
		That's protection against DNS Rebinding attacks -- you don't want external domains to be able to make same origin requests to internal domains, and while it suffices to only block changing resolution, that's harder than blocking internal IPs altogether.

▲

devrand 3 days ago | parent | prev [-]

You could also use the `_acme-challenge` CNAME record to delegate cert acquisition, assuming you're using separate subdomains for each.