Remix clone Hacker News

> 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.