Search code examples
x509wildcard-subdomain

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

I just started working for a new company. They are an engineering company focused mostly on hardware. They don't have a lot of experience with big data dev/test environments. The company has extensive IT security policies. One of them is "absolutely no wildcard certificates". I have worked in other software shops where wildcard certificates were commonly used in dev and test environments. The advantage is that you can spin up servers and use the wildcard certificate without waiting for the accounting department to issue a purchase order to the CA. I believe I understand all of the security issues for wildcards,

  1. If one subdomain is compromised, all subdomains are compromised.
  2. If you revoke the certificate, all subdomains are revoked.
  3. Wildcards may not be compatible on "really old" browsers and servers.
  4. Single private key floating around on several servers pose security risks.
  5. Some CA's void their warranties for Wildcard certificates.

I probably would not use wildcards for production servers -- mostly because of #4. However, I cannot see the above security issues a problem for a dev and test environment. The dev and test servers have internet facing ports. They all have the usual password and multifactor security built-in. Only necessary ports are exposed and all are https. The data is all test and all of the servers are in their own domain with no connection to the companies internal domains.

Does anyone see any potential security problems or other things I might be missing?

Solution

  • I started out thinking that wildcard X.509 certificates was the way to go with moderate to large server/instance development environments. However, the suggestions of AlexP were quite helpful and I believe it is a better way of approaching the distribution and management of multiple environments and X.509 certificates. Here is a description of his suggestions.

    You have several environments that you will have to support. Each environment has several servers or instances. Each server/instance requires their own X.509 certificates. 

      DEV1, DEV2, ...  Development environment
  TEST1, TEST2,... Test environment
  STG1, STG2,...   Production staging and test
  PROD1, PROD2,... Production Live environment

    The recommended way would be to build a private SSL Certificate Authority (CA). The private CA would issue X.509 certificates for DEV, TEST, and STG. Any development or test machine browser would be manually loaded with the root certificate of your private CA. This way the browser will not squawk about certificate security problems. Each server or instance would have it own unique certificate. Each environment could conceivably have several servers or instances so you could easily have many 10's of certificates to deploy and manage. The use of sub-domain or Fully Qualified Domain Name(fqdn) is also helpful -- DEV1.admin.mydomain.com, DEV1.rest.mydomain.com, TEST1.admin.mydomain.com,...etc. You will need to use the fqdn for the common name of each certificate -- STG1.mongodb.mydomain.com for example. For the production environment, you would use a commercial CA such as Comodo, Symantec, or others. The fqdn for this environment would be mydomain.com, rest.mydomain.com, etc. Private CA certificates are free, easy to create and fast to deploy. Commercial certificates can be expensive and take more time to create and deploy but are necessary. Private CA's represents a good cost, security, and ease of certificate management trade-off in a moderate to large development environment.