unhandled critical extension in client when ca has name constraints about cli

[BenjaminHae]

Thank you, I'm hoping for it to be fixed in Go stdlib.

[hslatman]

@BenjaminHae Name Constraints have recently been discussed amongst some members working on the Go crypto packages. There's some movement in Web PKI and requiring those to be handled. I haven't familiarized myself with the exact specifics yet, but I'll check if I can find something. Adding full support is on the radar and might land in Go 1.22. It could be later, though.

[hslatman]

Hey @BenjaminHae,

Thank you for opening the issue. Name constraints should already be supported, but there are limitations in the implementation.

As a TLS client, we rely on the Go stdlib, and the error originates from that. Can you share some details on the type(s) of name constraints you're using? Are you using constraints on the DN, by any chance? If I'm correct, the Go stdlib doesn't support constraints on all name types. Relevant issue: golang/go#15196 (and there are some more to be found).

[BenjaminHae]

I've set it up like this:

 X509v3 Name Constraints: critical
                Permitted:
                  othername:<unsupported>
                  email:mydomain
                  DNS:.mydomain
                  DirName:
                  URI:.mydomain
                  IP:XXX.YY.0.0/255.255.0.0

So it probably is indeed DirName...

[hslatman]

Hi @BenjaminHae,

We've discussed this issue in our open source triage. We're not big fans of having to implement a workaround for this, because ideally we would like the Go stdlib to be fixed. A potential workaround could be to ignore certain, user-specified, OIDs when validating a certificate in the CLI. This would have to be plugged into the default TLS validation code path, which makes it more complex and in return we don't get a lot of value. At the moment it's unlikely we'll build something for this, but if more similar use cases pop up, we may reconsider.

You could of course reissue your intermediate without the DN constraint as a workaround too and if you feel that's "safe enough" for your use case.

[hslatman]

@BenjaminHae I'll reach out to someone close to the Go crypto libraries to see what we can do about this 🙂

[luizluca]

@BenjaminHae Name Constraints have recently been discussed amongst some members working on the Go crypto packages. There's some movement in Web PKI and requiring those to be handled. I haven't familiarized myself with the exact specifics yet, but I'll check if I can find something. Adding full support is on the radar and might land in Go 1.22. It could be later, though.

@hslatman , there is a pending patch at https://go-review.googlesource.com/c/go/+/238362 that fixes this issue.

@BenjaminHae , you can pick one of these branches (Since 1.14) that includes the fix (I've been doing this for some time):

https://github.com/luizluca/go/tree/1.14/nameconstraint
https://github.com/luizluca/go/tree/1.15/nameconstraint
...
https://github.com/luizluca/go/tree/1.20/nameconstraint
https://github.com/luizluca/go/tree/1.21/nameconstraint