On Jul 20, 2021, at 4:40 PM, Michael Richardson <mcr+i...@sandelman.ca> 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 Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
