unhandled critical extension in client when ca has name constraints

[BenjaminHae]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

I've setup an intermediate-ca with name constraints. When using step ssh certificate against this CA, I receive this error:

x509: unhandled critical extension

I suggest supporting the "name constraint" extension.

Why is this needed?

Many people setup step-ca as an internal ca, limiting this ca to the internal domain name (using name constraints) reduces the impact of a compromised private key.

[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.

[BenjaminHae]

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

[hslatman]

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

[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.

[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