Vault PKI should support roles that constrain the CN domain but not the email domain

[chadparry]

Is your feature request related to a problem? Please describe.
My use case is that I want to issue a certificate for a service that will be running on a certain host. I want the PKI role permissions to be as constrained as possible. Say the host will be "mexec99.example.net". To help with maintenance, I also include an email address "myteam@example.com" in the certificate's SAN. To support that, I have to create a role with the field "allowed_domains": ["example.com", "mexec99.example.net"]. The resulting role could potentially submit a CSR for the DNS "example.com" even though my intention is for it to only be able to get a certificate for "mexec99.example.net". But if I remove "example.com" from the allowed_domains, then the email address in the SAN causes the entire request to be rejected.

Describe the solution you'd like
I would like to have separate constraints for the email domain and the CN domain. They have drastically different security requirements. Either there could be a separate field for allowed email domains, or there could be a flag for allowing any email domain. The simplest solution would be to add an allow_any_email field or an enforce_email_hostnames field to the PKI role.

[aphorise]

@chadparry I wonder if enforce_hostnames = "false" could achieve you're after. Have you tried?

[vishalnayak]

Issues that are not reproducible and/or have not had any interaction for a long time are stale issues. Sometimes even the valid issues remain stale lacking traction either by the maintainers or the community. In order to provide faster responses and better engagement with the community, we strive to keep the issue tracker clean and the issue count low. In this regard, our current policy is to close stale issues after 30 days. If a feature request is being closed, it means that it is not on the product roadmap. Closed issues will still be indexed and available for future viewers. If users feel that the issue is still relevant but is wrongly closed, we encourage reopening them.

Please refer to our contributing guidelines for details on issue lifecycle.