We recently setup a two tier internal certificate authority. We also disseminate Root CAs via Active Directory so certificates from our internal CA are automatically trusted by every (Windows) system in our network.

Our devs need SSL certificates for their local workstations. One option would be to generate a wildcard certificate to them like *.foo.bar.com.

The benefits are ease of implementation and future proof-ness (if we create new subdomains in the future, it covers them automatically).

However, the flip side is if we were to issue a wildcard certificate, how can you be certain that a malicious employee won't abuse it?

Imagine a situation where a malicious dev sets up a website on their local workstation (mail.foo.bar.com) and can somehow either also poison DNS or modify a user's local host file. That wildcard certificate lends credibility to their malicious website, making it look more authentic.

Am I being overly paranoid? Should we issue wildcards and make certificate maintenance easier or should we generate unique certificates for every DNS name to limit the scope of use?

Anybody have any thoughts? Experiences?


To me it seems there are two very good solutions posted here:

  1. Separate dev/test and production into independent CAs as recommended by @Kotzu. For us personally I can't justify setting up a second CA just for that purpose. It's too much effort for the number of certificates we have (40 total of which 10-20 are dev). That said, I totally think its the best answer.

  2. Modify the DNS naming structure as recommended by @immbis so that the "dev" portion of the name is the subdomain not the sub-subdomain. Thus making the wildcard more obviously a dev domain. This would alleviate my concerns about issuing wildcard certificates to a great extent. Then impersonation can only occur for *.dev.ourdomain.com - which I'm ok with. That said, we just have it hard coded too many places to make this practical.

I think what we'll end up doing is continue to issue fully qualified SSL certificates to each dev. That feels safer as it leaves a lot less wiggle room for a malicious person to abuse/impersonate a legitimate resource. This entire situation is a bit of a tails case anyway. I hope our devs generally aren't acting maliciously and trying to set up bogus sites. I just don't want to be handing out trusted wildcard certs like free candy only to later have them be ab/used some unexpected way.

If we need more and more certificates and issuing individual certificates becomes unmanageable then we'll consider setting up a second CA that's only trusted by the dev workstations (not the whole company) and issuing new wildcard certs.

  • 5
    Why do they need a wildcard certificate on their local machine as developers? If all their work is local, there is no chance of traffic interception. Commented Jun 1, 2017 at 20:28
  • 6
    "or modify a users local host file" - this requires sudo permissions. If a malicious developer has sudo access to a coworker's machine, then a wildcard cert is hardly a concern.
    – aaaaaa
    Commented Jun 1, 2017 at 21:19
  • 2
    @user52472 Because we're making https mandatory on our website (if you try to access it without https you get redirected to https) so when they test on their local workstation, they have to have functional https and thus certificates.
    – Brad
    Commented Jun 1, 2017 at 21:50
  • 7
    Make a certificate for *.devtest.foo.bar.com instead? Commented Jun 1, 2017 at 22:28
  • 7
    I'm sorry if I'm not understanding, but why do developers need to have externally trusted certs in order to do local testing/development work? What is keeping them from using self-signed certs or managing their own roots? Commented Jun 2, 2017 at 5:50

4 Answers 4


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.

  • That's an interesting idea........ it would solve the problem although I wonder if its not overkill? We have 50 employees total and 10 or so developers. I'm setting up a CA just for 10 people to issue about 10-20 certificates? Seems like a lot of overhead but I'll mull it over a bit. Thank you for the idea!
    – Brad
    Commented Jun 1, 2017 at 21:30
  • 3
    Security is always a trade-off between usability and budget. It depends how much risk you are willing to tolerate. The best solution from a security perspective is to always segregate your environments. The more you can segregate, the better. In any case, you should also have your dev certificates issued to domains that specifically specify they are for dev purposes to help your not so tech-savvy users. For example they should be issued to test-foo.bar.com
    – Kotzu
    Commented Jun 1, 2017 at 21:41
  • The approach we have been using is issuing individual certs to each fully qualified domain. Someone raised the idea of why not use wildcards and I thought... hmmm... Part of me said - that seems like a bad idea from a security stand point. Couldn't that be abused somehow? Part of me said - that would be far less work to manage - you're just making this harder for no actual benefit.
    – Brad
    Commented Jun 1, 2017 at 22:09
  • 1
    Managing distinct certificates for every fully qualified domain seems like a middle ground. Its safer than issuing wildcard certificates, but less work than setting up an entire separate test/dev CA. I very much like the idea of a separate test/dev CA in a larger environment though - it solves the issue more elegantly. If anyone else has any suggestions please let me know. Otherwise I'll mark this as the answer.
    – Brad
    Commented Jun 1, 2017 at 22:10
  • @Brad openssl can stand up a simple CA (where you have to run commands by hand or script to generate the certs) fairly quickly; it also allows you to generate broken certs (expired, revoked, misspelled, etc.), if you're sufficiently paranoid/robust-seeking/etc. and don't want to risk those certs being used in production.
    – Foon
    Commented Jun 2, 2017 at 17:09

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.

  • 1
    Our devs work in perhaps an unusual way. We have a dev environment in AWS, and they also run sites locally occasionally. So they may run dev1.api off their local workstation but dev1.images out of AWS. They need both to have a fully functional environment - but images is too big to run locally (for example). Because they are mixing and matching their local system and remote systems and they have to share a common naming scheme, because the names are sometimes stored in shared places. Mixing and matching DNS naming schemes like workstation.type.ourdomain.com and dev.type wouldn't work for us.
    – Brad
    Commented Jun 2, 2017 at 10:30

Given your constraints, I would say you should set up a script that uses Let's Encrypt (or your own certificate generator, whatever works) to automatically generate any requested subdomain certificates for any developer on your network, with the critical constraint that the suffix of the domain name is quite obviously obnoxious.

For example, let anyone in your coporation create arbitrary subdomains like X-untrustworthy-danger-danger-danger.company.com where X is whatever they want (ASCII-only, preferably). That should be enough for testing without misleading anyone.

  • Some of the domains are private (.local) so a public CA like lets encrypt wouldn't work (public CA's generally won't issue certificates for private dns names). Also what you're proposing is what @immibis has already suggested which is changing the name structure. That's definitely one approach but we have the names hard coded in 100s maybe even 1000s of places. Finding and updating them all would be very difficult, very time consuming and probably a tough sell.
    – Brad
    Commented Jun 2, 2017 at 13:25
  • @Brad: I don't understand, how is this changing the naming structure? I'm saying instead of letting them generate arbitrary subdomain names, only let them generate arbitrary subdomain names that are suffixed by something obnoxious. It doesn't matter what they higher-level domains are; they can be whatever you need them to be, to keep your naming structure the same. As for the domains being private, I don't understand why you need a public CA to verify them then. What's the point of that? If nobody outside can see these domains then what is the point of verifying them?
    – user541686
    Commented Jun 2, 2017 at 20:28

Consider restricting certificates issued to developers with extendedKeyUsage field to only what is absolutely necessary. If there is no Server Authentication purpose, it will be rejected when presented by a web server.

Also consider using extensions. For example, basicConstraints extension will differentiate between certificates that can sign additional certificates (CA:TRUE) and ones that can't (CA:FALSE). This way if any other certificate is issued by a malicious employe using their certificate, it will be rejected everywhere that supports this extension (so any X509v3).

This way if you have a malicious employe with a certificate restricted in the following way they won't be able to abuse it in quite as many ways:

X509v3 Basic Constraints: 
X509v3 Key Usage: 
    Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, Key Agreement

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .