Hello all, I have run into the same issue and decided to check the RFCs on this behaviour. Turns out, it is correct behaviour per specifications. See RFC5280 section 4.2.1.12.
If the EKU is present, it will restrict the allowed usage purposes of the certificate to only those items listed in the EKU. So, if a client needs to use such certificate for DTLS/TLS, it needs to add id-kp-clientAuth. And if a server needs to use such certificate for DTLS/TLS it needs id-kp-serverAuth. Consequence for a Registrar server, that MUST have id-kp-cmcRA set, is that it also needs id-kp-serverAuth set in the EKU. Older DTLS 1.2 stacks for example may not check EKU yet in such a way (e.g. an older Scandium I used did not check) but I expect never 1.2/1.3 stacks to check EKU. @Michael this could be worth adding to our constrained-BRSKI draft as a clarification, as it seems non-trivial. (It was to me for sure.) And maybe also keep this for considerations for a BRSKI-bis document. Regards Esko -----Original Message----- From: Anima <[email protected]> On Behalf Of Alan DeKok Sent: Tuesday, July 20, 2021 22:54 To: Michael Richardson <[email protected]> Cc: Anima WG <[email protected]> Subject: Re: [Anima] Registrar certificate EKU bits On Jul 20, 2021, at 4:40 PM, Michael Richardson <[email protected]> wrote: > > When debugging another issue, I found that my test Registrar had stopped > being able to connect to my MASA. Some upgrades to Openssl, Apache meant > that one of those two decided the Extended Key Usage for the client > certificates had better be right. > > What I found: > 1) If there is no EKU, then it's all okay. > 2) If there is an EKU, and it contains only cmcRA, then it is rejected. > 3) If I add "clientAuth" EKU, then it works. > > I don't know if this is enforced in Apache (via some callback), or within > OpenSSL. Having run into similar issues, I suspect a combination of both. OpenSSL does it's own validations, and the application using OpenSSL can add more. For EAP, we've added our own certificate validation callbacks, largely to shut off much of the automatic behavior of OpenSSL. i.e. the "heavy lifting" of checking ASN.1 formats and certificate chains is up to OpenSSL. But the validity of the contents of each cert is up to the application. > There are nothing logged in Apache, so I think it's autocratic actions by > a minor patch level of OpenSSL, and Apache probably needs to override the > behaviour. Or, it could be Apache's certificate verify callback. > The lack of logging on the server is a serious problem. That is a wide-spread issue. We've added voluminous debug logging, which is horrible for the average user, but allows anyone *reading* it to trivially debug fairly complex issues. > What does occur is that there is a TLS level response, an SSL Alert, saying > that the certificate was rejected. "Failed" Why? "Failed". <sigh> > Perhaps someone else will find this email useful. > Mostly, it convinces me to never set any EKU bits. > I guess, I need to set serverAuth too, now that I think about it. Yes. Alan DeKok. _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
