On Mon, Feb 13, 2023 at 10:35:31PM -0500, Karl Denninger wrote:
> > However, note that the error reported by OpenSSL is "unsupported
> > purpose", NOT "invalid purpose", for that error, I actually need to
> > specify a made up purpose name. So it is unclear how your server
> > managed to report an "invalid purpose", perhaps there's a typo in
> > the server code, and it rejects all client certificates, because
> > it tries to check them against an unknown (to OpenSSL) "purpose".
>
> I generated a certificate for the connecting device with "server,
> client" as the purpose (not the EKUs but "nsCertType") and the server
> now accepts it.
I see, you're continuing to use nsCertType, despite its entering its 3rd
decade of obsolescence. :-) In that case, yes, OpenSSL still has code
to honour these, and will return:
X509_V_ERR_INVALID_PURPOSE
on failure. The error string for that is:
"unsuitable certificate purpose"
but your application may be reporting it using its own mapping.
> This particular code set was used a number of years (and many OpenSSL
> releases) back and didn't complain about this; its not a big deal to
> issue the certs this way for the connecting client endpoints, but I was
> more than a bit surprised when I got the rejections, since the keyUsage
> and EKU parameters appeared to permit what I was doing.
The sane (non deprecated) thing to do is to never set nsCertType, and
set just EKUs.
--
Viktor.
