search

node-opcua / node-opcua-crypto

node-opcua certificate tools & encryption/signature support
MIT License
5 stars 10 forks source link

Parsing basicConstraints extension without CA tag but with pathLength specified. #18

Closed mchldbrtl closed 1 year ago

mchldbrtl commented 1 year ago

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 commented 1 year ago

CLA assistant check
All committers have signed the CLA.

erossignon commented 1 year ago

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 commented 1 year ago

Thank you! Is this ready to merge ?

mchldbrtl commented 1 year ago

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!