I'm a software designer (former IT SysAdmin) trying to wrap my head around some authentication requirements in an API Specification document.

Let's say government department (abc.gov) has created a new online web portal to receive 'incident reports' electronically via a RESTful JSON (Swagger) API secured with Mutual SSL (TLS).

Various Service Providers (we'll call one xyz.org) are to ask their software vendors to provide an updated system that can connect to the abc.gov API.

Our software is cloud-based (ASP.NET, IIS8, - let's say jkl.net). Various organisations would log into our web system (username + password), then our software would have to connect to abc.gov and impersonate (for lack of a better word) xyz.org.

abc.gov provides the following information along with the API specifications:

  • Client certificates will need to be issued by a Trusted Certificate Authority
  • Client certificates cannot be shared across different organisations.
  • This client certificate needs to be shared only with the certificate's public key.
  • If the same vendor is submitting incidents on behalf of multiple service providers, the vendor must use a different client certificate for each service provider.
  • When client certificates expire, new client certificates will need to be issued by the Service Provider and provided to abc.gov, without the private keys.

From the research that I have done so far, I roughly know that we can:


  • What I am not sure on, is where are these client certificates from?
  • What type of certificate is required, and how would it work given that the domain names will not match? (i.e. xyz.org requests a new certificate, gives it to jkl.net, to authenticate with abc.gov).
  • Would IT staff from service providers conclude that this practice is unsafe?

Thanks in advance - looking forward to learning more about this.

1 Answer 1


What type of certificate is required

A certificate suitable for authentication as a client. As for the exact requirements which CA's are trusted by abc.gov check the documentation you got from abc.gov.

how would it work given that the domain names will not match

Client certificates are usually not checked against domain names since there is usually not a specific domain associated with the client. There is no standard on what the subject should contain so you would need to check again the provided documentation what is expected. One option would for example the email address of the client.

Would IT staff from service providers conclude that this practice is unsafe?

I assume they would. Giving somebody a client certificate so that he can impersonate the client is similar to giving somebody the username and password, i.e. abandoning any control what can be done by impersonating the client. Therefore it is usually forbidden by various security guidelines. And I doubt that abc.gov will like that practice too.

You must log in to answer this question.

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