x509 - Wildcard X.509 Certificates -- Do they make sense in development environments -

i started working new company. engineering company focused on hardware. don't have lot of experience big data dev/test environments. company has extensive security policies. 1 of them "absolutely no wildcard certificates". have worked in other software shops wildcard certificates commonly used in dev , test environments. advantage can spin servers , use wildcard certificate without waiting accounting department issue purchase order ca. believe understand of security issues wildcards,

1. if 1 subdomain compromised, subdomains compromised.
2. if revoke certificate, subdomains revoked.
3. wildcards may not compatible on "really old" browsers , servers.
4. single private key floating around on several servers pose security risks.
5. some ca's void warranties wildcard certificates.

i not use wildcards production servers -- because of #4. however, cannot see above security issues problem dev , test environment. dev , test servers have internet facing ports. have usual password , multifactor security built-in. necessary ports exposed , https. data test , of servers in own domain no connection companies internal domains.

does see potential security problems or other things might missing?

i started out thinking wildcard x.509 certificates way go moderate large server/instance development environments. however, suggestions of alexp quite helpful , believe better way of approaching distribution , management of multiple environments , x.509 certificates. here description of suggestions.

you have several environments have support. each environment has several servers or instances. each server/instance requires own x.509 certificates.

  dev1, dev2, ...  development environment   test1, test2,... test environment   stg1, stg2,...   production staging , test   prod1, prod2,... production live environment 

the recommended way build private ssl certificate authority (ca). private ca issue x.509 certificates dev, test, , stg. development or test machine browser manually loaded root certificate of private ca. way browser not squawk certificate security problems. each server or instance have own unique certificate. each environment conceivably have several servers or instances have many 10's of certificates deploy , manage. use of sub-domain or qualified domain name(fqdn) helpful -- dev1.admin.mydomain.com, dev1.rest.mydomain.com, test1.admin.mydomain.com,...etc. need use fqdn common name of each certificate -- stg1.mongodb.mydomain.com example. production environment, use commercial ca such comodo, symantec, or others. fqdn environment mydomain.com, rest.mydomain.com, etc. private ca certificates free, easy create , fast deploy. commercial certificates can expensive , take more time create , deploy necessary. private ca's represents cost, security, , ease of certificate management trade-off in moderate large development environment.