14

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?

EDIT

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.

Michael
  • 2,391
  • 2
  • 19
  • 36
Brad
  • 613
  • 6
  • 12
  • 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. – Dan Landberg Jun 01 '17 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 Jun 01 '17 at 21:19
  • Their workstations are windows so not sudo but rather local administrator permissions. But say I'm the bad developer and I sit down at your workstation to test something, modify your hosts file when you aren't paying attention.... poof... you're none the wiser and the SSL cert says its valid.... – Brad Jun 01 '17 at 21:25
  • 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 Jun 01 '17 at 21:50
  • 6
    Make a certificate for *.devtest.foo.bar.com instead? – user253751 Jun 01 '17 at 22:28
  • If our naming convention was whatever.environment.foo.com a certificate to *.environment.foo.com would work and I'd be much more comfortable issuing a wildcard to it because its very clearly a "dev" domain. Unfortunately that's not how our DNS naming is structured and re-structuring it would require a TON of work. :-( It's another excellent idea tho. Thank you for the suggestion! – Brad Jun 01 '17 at 23:44
  • 1
    IMO the best solution in terms of security with your current architecture is to have developers or IT create their own root certificates, install them on their own computers, and then create any certificates they need based on those. Each developer gets a different root certificate so they can't impersonate each other (without bypassing a security warning which I'm sure they are knowledgeable about). That's if you absolutely can't have multiple environments... – user253751 Jun 02 '17 at 01:07
  • 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? – Joel Cornett Jun 02 '17 at 05:50
  • 1
    @immibis post as answer? – Please stop being evil Jun 02 '17 at 07:39
  • 2
    What I don't understand here is what exactly the threat is. Who is trusting who? What will go so catastrophically wrong if someone gets the private key and masquerades as, say, `dev-test-only-dangerous-site.company.com`? Who would be the target of an attack? Customers? Why in the world would they visit that website and what could they get tricked into doing? Wouldn't an attacker find it easier to just grab a domain like `c0mpany.com` instead? I feel like if you're doing it right, it should be fine -- even if your cert's private key was printed in the New York Times, it shouldn't do any damage. – user541686 Jun 02 '17 at 09:39
  • 1
    If a dev gets the private key (which they will have) for *.mail.ourdomain.com. They can then setup dev1.mail.ourdomain.com, trusted.mail.ourdomain.com, accounts.mail.ourdomain.com, login.mail.ourdomain.com, etc. The first domain dev1.mail.ourdomain.com looks like a dev domain - no issues, but what about trusted, accounts or login. Those look like could be legitimate domains to our internal (non-tech savvy) employees. And they're further legitimized by having a valid trusted certificate. So the concern is really an internal -> internal attack. Unlikely? Sure. But possible? So is it a good idea? – Brad Jun 02 '17 at 10:01
  • @mehrdad to your point about a malicious party registering a domain similar to our own (or poisoning dns or the hosts file with a name similar to a legitimate name) that's a valid enough point. We can't control that though. We can control who we give out wildcard certificates that are trusted by the entire company. :-) That said I'd like to think our devs are trustworthy - I just don't want to be in a situation where one does something malicious and I've just helped them along by making their malicious activity even more authentic looking. – Brad Jun 02 '17 at 10:55
  • 1
    @Brad: Ah, I see. So the problem I see isn't the fact that you're issuing wildcard certificates; it's that the *parent* of the wildcard already exists and is expected by people to be trustworthy. If you could fix that, then that would fix this issue. Is there no chance you could name your subdomain something obnoxious like `dev-test-only-dangerous-site`, then issue wildcards below that? – user541686 Jun 02 '17 at 11:14
  • @Mehrdad - Thats immibis solution above I believe. Which would alleviate all my malicious impersonation concerns but is completely non-trivial to implement. These names have existed for probably a decade and are embedded throughout the company in various places. Changing it would be very very painful. – Brad Jun 02 '17 at 11:22
  • @Brad: Right, so in that case see my answer. You don't need wildcard certificates to allow a variety of subdomains, right? You can generate them on the fly if they meet reasonable conditions.. – user541686 Jun 02 '17 at 11:28

4 Answers4

48

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.

Kotzu
  • 944
  • 7
  • 10
  • 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 Jun 01 '17 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 Jun 01 '17 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 Jun 01 '17 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 Jun 01 '17 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 Jun 02 '17 at 17:09
  • I've started to prefer cfssl for running your own CA - https://github.com/cloudflare/cfssl It uses modern certificate profiles by default, unlike openssl. – Riking Jun 03 '17 at 07:20
  • Dev and testing certificates are cheap because everyone can generate them for free. You only need paid certificates for your "real enviroments" as stated in the answer – BlueWizard Jun 04 '17 at 22:28
3

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.

user
  • 7,670
  • 2
  • 30
  • 54
  • 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 Jun 02 '17 at 10:30
0

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.

user541686
  • 2,502
  • 2
  • 21
  • 28
  • 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 Jun 02 '17 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 Jun 02 '17 at 20:28
0

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: 
    CA:FALSE
X509v3 Key Usage: 
    Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, Key Agreement
Kirill Sinitski
  • 989
  • 6
  • 12