Security concerns issuing wildcard certificates to individual employees

I think you should segregate your environment. Only production certificates should be trusted on all your network. Dev and testing certificates should only be trusted on the computers where developers work. In a more secure environment you would not even use the same root CA for production and development environments.

I'm going to assume that your developers need locally trusted SSL certificates. As pointed out previously, it might be worth considering if they really do need those in the first place.

A wildcard certificate refers to a certificate with a CN or SAN on the form *.something.example.com.

The * expands to only a single label; it does not expand to multiple labels. So the above would match foo.something.example.com (* expanding to a single label) but not foo.bar.something.example.com (two labels) let alone foo.example.com (missing label).

Also keep in mind that if I recall correctly, multiple * labels are specifically disallowed in certificate SAN and CN fields. So you can't create a valid certificate for e.g. *.*.something.example.com; that would be rejected because it has multiple * in a single name. (I think this was one of the problems Stack Exchange the company ran into when working to set up network-wide HTTPS.)

Presumably, each developer workstation is named differently. So you might have developer workstations like dev033.internal.example.com, dev7g-vm2.example.com, or what have you.

So give each developer a single certificate for a single wildcard SAN under their own host's fully qualified name plus the fully qualified name of their own host. Set it up to not be allowed to use for signing other certificates (leaf certificate).

For example, give the developer who uses dev033.internal.example.com a certificate valid for only dev033.internal.example.com and *.dev033.internal.example.com.

That way, the developer is free to set up aliases to their own host (for example, api.dev033.internal.example.com and web.dev033.internal.example.com would both work with such a certificate) but can't set up any SSL for anything not under their own workstation's hostname. Presuming that you don't expose internal.example.com to any external hosts, outside of your network the developer also cannot really do anything with the certificate that they couldn't do with a self-signed certificate.

For bonus points, but not really required: sign these with an internal CA that is only used for such development (or testing, or whatever) certificates.