Few of our web servers are managed by an outsourced partner who works as us in the same office, uses our laptops connected to our corp network, and has user accounts in our AD. They requested and applied wildcard certificates to make some of the IIS sites (all internal facing) https.

Someone in IT raised a concern that it is not advisable, from a security point of view, that outsourced admins request and apply certs on websites. Here is the argument:

With a wildcard certificate you can "impersonate" any service, even the ones not managed by the specific team on the specific servers they have an agreement to manage. If the certificate is leaked outside of our company, it could pose a security risk, e.g. potentially be used to setup services pretending to be owned/validated by us when they are not. We may have NDA in place, but it would still be good practice IMHO to limit number of hands with access to certificates (I'd say even internal hands!), and considering that we even used pseudo-role based usernames as we expect that people may rotate more often than internal employees.

It is an internal certificate which wouldn't resolve on the internet. What do others think of this?

  • 1
    Who/what is the CA? Only an internal entity? The CA cannot be contacted by external parties?
    – schroeder
    Commented Oct 11, 2017 at 13:01
  • 4
    @Jacco For one, Let's Encrypt - or any publicly-trusted CA - logs all certs they issue to CT. For internal resources (servers not visible to the internet), like for example the corporate AD or Exchange servers, I don't really want their domain names to be public knowledge. Commented Oct 11, 2017 at 13:20
  • 6
    @Jacco local CAs are free certificates
    – schroeder
    Commented Oct 11, 2017 at 13:22
  • 2
    Why can't they have a wildcard subdomain specific to them? IE *.partner1.xyz.abc.com which is also valid for parter1.xyz.abc.com
    – Erroneous
    Commented Oct 11, 2017 at 14:58
  • 1
    @Sneftel fair enough. Seems the most obvious solution then is explicitly state all the required sub domains in a single cert. As long as they can enumerate all the domains they need up front (or you can reissue as more are added) then no problem.
    – Erroneous
    Commented Oct 11, 2017 at 15:53

2 Answers 2


I'll supplement @schoeder's answer with some technical details.

My understanding of your situation is that you have servers applications like this:


and your partner also has some applications running on the same server:


All of the above are internal-facing (not accessible from the internet). Now, the partner was too lazy to make individual certs for each of their IIS applications, so they made and installed a global a cert for:


Cool. That covers all of their applications. But it also covers all of yours. Assuming they have access to the private key that belongs to this wildcard cert, then they can Man-in-the-Middle your intranet or documents servers and read all the traffic.

Also, if your company has (or a malicious admin with your partner decides to stand up) any public-facing websites that match the wildcard, for example:


then, since it's a private internal CA, the general public would not be fooled by their spoof, but any of your employees connecting from internally (with that CA installed into their OS) would trust the spoofed version of www.xyz.abc.com.

As @schroeder points out, the potential for insider-threat here is huge.

  • Mike, partner is only supporting few applications hosted on couple of our servers. For example, we have a site intranet.xyz.abc.com & documents.xyz.abc.com, applications.xyz.abc.com etc. which are all internal websites of organiation abc.com. So they raised a request for cert *.xyz.abc.com and applied to the IIS server.
    – Manu
    Commented Oct 11, 2017 at 13:22
  • @Manu Ok. I've updated my answer with your example domain. Does this agree with your situation? Commented Oct 11, 2017 at 13:30
  • It does mostly other than there isn't a partner*.xyz.abc.com site, all the sites are abc.com related no partner/extranet. I get your point and we need to work on our processes and policies if we have to continue working with non-employees managing our systems. Thank you @MikeOunsworth
    – Manu
    Commented Oct 11, 2017 at 14:39

Insider threats are a major problem that not enough organizations think about. The IT person is correct to bring this up.

But the argument is just one factor. A 'threat' has been raised, and now a 'threat analysis' needs to be performed. What is the impact if a malicious insider (outsourced or not) can impersonate services? If this impact is low, then you can choose to ignore this threat.

Just because something could happen does not mean that we need to freak out. We need to consider the impacts and likelihoods and determine if this is something we need to deal with.

Without further details about your environment, services, data flows, etc, (which you probably should not disclose here), that's about as much as we can respond.

  • By internal CA I meant local Certificate Authority. To Rephrase, what is the security threat if someone who has access to 2 application servers (as admin) get hold of an internally issued TLS certificate? What are the potential damage they can cause assuming they do not have access to any other business application as administrator?
    – Manu
    Commented Oct 11, 2017 at 13:12
  • the threat is what your IT explained: impersonated services. An admin running a malicious service on their own laptop with one of those wildcard certs, for instance.
    – schroeder
    Commented Oct 11, 2017 at 13:23
  • Agreed, if the privilege of these partner user accounts are managed properly using roles, etc can the threat be minimised?
    – Manu
    Commented Oct 11, 2017 at 13:26
  • 5
    @Manu I don't think it has anything to do with accounts or roles. The basic question is: when an employee points their browser to your intranet and gets a green HTTPS lock, how do they know they are talking securely to the server, and a rogue admin is not using that wildcard cert to man-in-the-middle the connection from their laptop? With a shared wildcard cert, this is completely possible, and the connection is already broken before the user even sees the login page. Commented Oct 11, 2017 at 13:33
  • 2
    @MikeOunsworth meh, I can imagine a tight account security ship where admins can't launch new services. But I've never seen such a ship float. And accounts are not the correct place to address this threat
    – schroeder
    Commented Oct 11, 2017 at 13:40

You must log in to answer this question.

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