X509v3 Name Constraints incorrectly required on subordinate CAs in chain about strongswan

[tobiasbrunner]

Thanks for the report. I recently noticed this myself. The name constraints validation is currently performed for each issuer/subject relation separately (this is basically how the cert_validator_t::validate() method is called), which means there is no context beyond the two certificates. I guess that's why the plugin enforces that name constraints are inherited (with narrowing/widening) through the complete chain so that the issuer of the end-entity certificate will provide all the relevant constraints (this is the first validation that will occur).

Instead, we'd technically have to maintain sets of allowed/disallowed names starting from the root and apply them to each level in the PKI and possibly modify them depending on the name constraints contained in the intermediate CA certificates. This could be similar to the policy constraints validation, which only occurs once the complete chain is available (basically the last call of validate() where anchor is set TRUE). Then we could build the chain and sets of name constraints from the root and properly validate them. I'll try to have a look at this soon.

[rc4]

Wonderful, thank you so much! That sounds exactly like the approach I was thinking would be used.

Let me know if I can assist in testing in any way.

[tobiasbrunner]

I've pushed some changes to the 2114-name-constraints branch that fix several of the shortcomings of the previous code (see the commit message of the last commit for details).

The certificates generated by your script are correctly validated with these changes.

[rc4]

That looks great, thanks! I have only now gotten it built from source so I'll give it a test. Appreciate it!

[rc4]

Hey there, sorry for the delay, I had a busy week and forgot to finish testing!

I can confirm that this fixes my issue with my setup—thanks again so much for the blazing fast turnaround.

[tobiasbrunner]

Great, thanks for testing.