> On 20 Jan 2021, at 01:40, Jacob Champion <pchampion@vmware.com> wrote:
>
> On Tue, 2021-01-19 at 21:21 +0100, Daniel Gustafsson wrote:
>> There is something iffy with these certs (the test fails
>> on mismatching ciphers and/or signature algorithms) that I haven't been able to
>> pin down, but to get more eyes on this I'm posting the patch with the test
>> enabled.
>
> Removing `--keyUsage keyEncipherment` from the native_server-* CSR
> generation seems to let the tests pass for me, but I'm wary of just
> pushing that as a solution because I don't understand why that would
> have anything to do with the failure mode
> (SSL_ERROR_NO_SUPPORTED_SIGNATURE_ALGORITHM).
Aha, that was a good clue, I had overlooked the required extensions in the CSR.
Re-reading RFC 5280 it seems we need keyEncipherment, dataEncipherment and
digitalSignature to create a valid SSL Server certificate. Adding those indeed
make the test pass. Skimming the certutil code *I think* removing it as you
did cause a set of defaults to kick in that made it work based on the parameter
"--nsCertType sslServer", but it's not entirely easy to make out. Either way,
relying on defaults in a test suite seems less than good, so I've extended the
Makefile to be explicit about the extensions.
The attached v22 rebase incorporates the fixup to the test Makefile, with not
further changes on top of that.
cheers ./daniel
