[moqmar]

I don't really understand how "hosted" and "internal" go together here - does this mean that a) the devices I need certificates for must connect to your servers, and that b) your servers could theoretically sign certificates for devices which do not exist? If so, especially for the latter point, this IMO isn't really useful for any real-world application, as the most important things of a CA is control.

[benburkert]

Yes, this is both "hosted" and "internal": we build & manage a CAs per org. It's a bit like having an instance of Let's Encrypt, but just for your org (or per environment). Your clients will only trust the certs for your CA, and those CAs have constraints in place so that we could never issue a certificate outside of your set of configured DNS names. For example, even if a certificate was issued for gmail.com, it wouldn't be trusted by your clients.

We always build two-tier PKIs, which means your server certificates are issued by intermediate certificates, and those intermediates are issued by a root certificate. In the future, we will let users bring their own root certificate so that we never see your root key material, which you can keep safely in an HSM or KMS.

[tempay]

> Your clients will only trust the certs for your CA, and those CAs have constraints in place so that we could never issue a certificate outside of your set of configured DNS names.

Does this work in practice? I was under the impression that the extensions for restricting which domains a CA can use weren’t widely supported.

[benburkert]

It does work, and we've found it to be about as well supported as SAN names, which is pretty extensive these days. It's just not commonly used by public CAs because the real value of these public CAs is that they can issue for any valid domain name, not a predefined set.