Parsing basicConstraints extension without CA tag but with pathLength specified.

[mchldbrtl]

I found myself in a situation where an OPCUA server is offering me a certificate with the basicConstraints extension specifying pathLength but not CA field. This is probably due to a malformed certificate but it is still correctly parsed by popular tools like openssl etc etc.
The client then fails because the function readBasicConstraint2_5_29_19 expects the CA field to be encountered first and the pathLength second, possibly.
Honestly, the literature and the real world examples are often misleading about the correct structure of this extension.
I don't know if my suggestion is fully compliant with the specs but I hope it should provide a less stringent and more accepted approach for parsing basicConstraints extensions.

[CLAassistant]

All committers have signed the CLA.

[erossignon]

Hi mchldbrtl thank you for bringing this enhancement.

Please make sure to add a unit test that specifically stresses the code that you have added.

This will be a prerequisite before the PR could be accepted.

[erossignon]

Thank you!
Is this ready to merge ?

[mchldbrtl]

Hi! It is ready indeed. Still, the appveyor CI fails in the very early stage with error:

The build phase is set to "MSBuild" mode (default), but no Visual Studio project or solution files were found in the root directory. If you are not building Visual Studio project switch build mode to "Script" and provide your custom build command.

Are you aware of the failures? I saw that happens for other jobs too. Thanks!