Delegated Credentials doesn't seem relevant to this problem. DC is solving a problem for big distributed systems where you have many nodes with one name, and we'd like to neither issue them all separate certificates for that name nor distribute a single key and certificate to every node. popular.example can have five hundred nodes, scattered around the globe at ISPs for example, all answering to the name popular.example. These nodes all hand over a certificate for popular.example to visiting devices, but they don't know the corresponding private key, however they each have a Delegated Credential from some master system (perhaps the one that obtained the certificate for popular.example) proving they're entitled (if you trust Delegated Credentials) to use that name.
We can imagine that CDNs and other big distributed systems want to do DC, because it can improve their security posture / simplify their deployment (if they are willing to take the compatibility hit, now or at some future point) but there's no reason I can see it would make sense for small users.
I don't see why "big CDN companies" have easier access to something that "small users" don't have access to. This infuriates me. For example why can Cloudflare create a certificate for https://1.1.1.1 when signing TLS certificates for IP addresses is not allowed? If Cloudflare may do it, why can't other CAs? I know this is very off-topic - I am just having a useless rant (:
V V ned., 7. feb. 2021 ob 02:43 je oseba Tialaramex via Let's Encrypt Community Support <letsencrypt@discoursemail.com> napisala:
Cloudflare did not create this certificate? It was issued by DigiCert. And yes certificates for IP addresses exist in PKIX and are allowed by the root trust stores although they aren't common (far less than 1% of issued certificates). The rules for them are different from the rules for DNS names, but there are rules, which presumably DigiCert obeyed in issuing this certificate to Cloudflare.
The certificate you want is CA:TRUE and the 1.1.1.1 certificate isn't CA:TRUE so I don't see how it's relevant to your desire at all.
Yeah, you're right, I'm sorry, it appears as if issuing certificates for IP addresses is indeed allowed for all CAs and my previous post was off-topic.
V V ned., 7. feb. 2021 ob 14:46 je oseba Tialaramex via Let's Encrypt Community Support <letsencrypt@discoursemail.com> napisala:
The bigger companies donāt have easier access. There are a LOT of requirements fo a root CA that bigger organizations simply have the resources to be able to handle. Iām pretty sure most companies donāt have an air gapped, powered off server, locked in a room that requires 2 key holders to access, dedicated to generating a root CA certificate, and signing the issuing intermediate certificates. They also donāt have the staff needed to maintain and troubleshoot the CA environment. AD Certificate Services may make it easier, but there is a certain degree of customization that needs to be done to issue certs meeting current standards (the default templates donāt support ECDSA CSRs, most versions still want to use 1024 bit RSA keys - I havenāt tried on 2016 or 2019, but 2012 R2 needed customizations, and a lot of medium sized businesses are still using 2012 R2... I know because my muggle job requires me to support TLS connections from them, and the two RSA ciphers that are not considered weak, that 2012 R2 supports, were bulk disabled by a lot of customers instead of correctly telling SCHANNEL to not use a DHE parameter smaller than 2048...).