3

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?

skmansfield
  • 1,413
  • 3
  • 19
  • 41
  • Why not set up a local CA for the test and development environments and emit certificates to your heart's content? – AlexP Apr 15 '17 at 19:37
  • This is what I am doing now. The only problem is that the browsers bark at self-signed certificates. Also, I have to have a unique certificate for each server. I have a lot of servers. Keeping track of each certificate and where they go is a slight pain. I guess one solution would be to use a wildcard self-signed certificate. I would use them for the dev & test environments. I could use real CA certificates for the demo & production servers. This is my first time managing a lot of servers in multiple environments. How do you do it? – skmansfield Apr 15 '17 at 19:44
  • Do not use self-signed certificates. Set up a private CA and add it to the list of trusted CAs in the browsers used for development and test. – AlexP Apr 15 '17 at 20:02
  • Makes a lot of sense. Would you use wildcard certificates or just create unique ones for each server. Are their security issues? Since I am in dev/test, I believe wildcard certificates is not really a concern. You agree? – skmansfield Apr 15 '17 at 20:05
  • I would recommend using individual certificates -- they can be emitted and installed automatically when a new server is created. This is more like real-life certificates. It also has the advantage that it obeys the letter of the security policy. But of course you can create wildcard certs. – AlexP Apr 15 '17 at 20:09
  • My initial concern was the time needed to get commercial certificates. Using a private CA and updating the dev/test browsers is instantaneous so a lot of my concerns go away. It is also a lot cheaper. I will go with your recommendations and use unique private CA certificates for each of the dev/test servers. I can use commercial certificates for the production environment. Your suggestions were very helpful. – skmansfield Apr 15 '17 at 20:19

1 Answers1

2

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.

skmansfield
  • 1,413
  • 3
  • 19
  • 41