We use EKU to provide mTLS between components owned and run by other entities, it is not truly authentication, as we have other methods to do that but it does "keep the lumps out". For sure the industry has overloaded the "server cert" CA with other use cases, and this is why we really do need a IETF/IANA type governance and discussion, rather than what we have here with Google dictating the use cases and solution with Web blinkers. What I fear here is the other options which are two fold and ugly, so I propose option 3. 1) In software make server certs work as client certs - Which results in special code and fractured solutions 2) Create a shadow CA infra for non browser use cases - Which results in fragmented CA (yuck!) 3) Get together as an industry and push a little back and make EKU non default and only issued if asked for, which interestingly is how we have Google issue our certs right now If this is interesting to others perhaps we can discuss at the next in person NANOG. Colin On 5/22/2025 11:04:54 AM, Jay Acuna via NANOG <nanog@lists.nanog.org> wrote: On Thu, May 22, 2025 at 12:45 PM Tom Beecher via NANOG wrote:
want it imposed on me from on high. It's **YOUR** certificate that **YOU** are creating. The EKU is NOT mandatory to have present.
Who is "imposing" something on you?
Your CA is imposing it clearly.. in this case LetsEncrypt. However, their reasoning ultimately is Google is mandating a new standard by fiat, and unilaterally to limit the declared purposes for your certificates. Although Google is one vendor and doesn't have IETF or any industry standards body in agreement to make EKU a mandatory field. Google holds a monopoly position which they can abuse to bypass all standards bodies and hold your CA hostage should they not agree to any new arbitrary standards or rules they come up with. If your CA doesn't agree to create and impose the extra restrictions on you and how you can use your certificates with other software, then Google will drop support for all LetsEncrypt certs from their browser Chrome. -- -JA _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZNVKSJHY... [f5f1ef8a-e3e2-4162-a6ed-a98893f440d3]