Who should issue the client certificate for client certificate authentication?

Question

In case of client certificate authentication, who should issue the client certificate?
The service provider which exposes the API or the client consumer which consumes the API?
In my experience, I have seen both the approaches but I would like to know what sacred texts say.

Answer 1

The API consumer should generate a CSR, usually, so that there is confidence that the consumer is the only party with the corresponding private key for the certificate. The certificate issuing can then be carried out by the service provider (service-signed), the client (self-signed), or a third party trusted CA (CA-signed).

If the service provider creates the client CSR, there is an integrity issue, in that they could potentially issue the same certificate to multiple end users. This isn't always a problem - if the certificate is being used to secure a channel and further steps are taken for authentication, for example, or if it is being used for an initial connection where a client specific public key can be transferred - but isn't ideal.

Similarly, if the service requires that the client certificate be signed by a trusted third party, that isn't going to work if the service generates it - the third party verification steps would then apply to the service, rather than the actual end user, nullifying the benefits. It's not particularly uncommon for service providers to sign client certificates, however, which allows them to have a very small list of trusted root certificates (their own ones), and doesn't require that the client expose the private key to anyone. Instead, the client sends a CSR to the service, gets a certificate in response, and can use that in conjunction with the key, which has never left their control.

Answer 2

who should issue the client certificate?

An approved authority which is trusted by API service provider. This is not necessary the API service provider itself (though, it is common), this task may be delegated to another entity which will follow requirements set by API provider. When delegated, API provider should be assured that only legitimate and properly authenticated clients receive client certificates.

Certainly, not client is responsible to create client certificates.

Update

Depending on particular case, there might be several common scenarios:

1. service provider issues all client certificates. API server is configured to trust only certificates issued by service provider's CAs.

This is simplest approach. Client generates CSR and submits it to service provider's CA. When request is properly authenticated and validated, client receives signed certificate which is then used to access API.

Pros: service provider tracks all individual clients and their certificates.

Cons: service provider has to maintain all infrastructure to work with validation of client requests and maintain them (renew, reissue, revoke, etc.). May have a notable overhead (for both parties) when client entities are not strictly defined. That is, when you have only 5 clients, this approach is certainly good. When you have thousands, this may be a problem, because service provider will have to follow SLA.

2. there is B2B (business-to-business) relationships. Service provider's CA may issue a qualified cross-certificate (with required constraints) to client's issuing CA. Client organization's CA issues certificate to its own personnel to access remote service provider API

This option is required to have an operable private PKIs in both organizations, service provider and client organization. Client organization may have a large number of client entities who are allowed to access service provider.

Pros: reduces certificate management costs on service provider end. Especially when exact number and name of client entities is not known in advance (for example, access is granted on a departament basis). Allows better certificate lifecycle management within client organization.

Cons: requires a qualified trust between client organization and service provider organization. This opens a hole when client organization may misissue client certificates and not considered well trusted. This question is commonly solved by using PKI audits by a 3rd party audit company. There will be a written policy that describes all technical and legal relationships between organizations. But this approach is costy too (audits, writing policies, etc.).

In some cases, this scenario is grown to more than just 2 organizations and in order to limit a number of cross-certificates, a Bridge CA is built to organize a trust between organizations.

Answer 3

I have to disagree with Crypt32's answer.

(I assume by "issue" that you mean "sign")

It should be some entity trusted by both the service provider and the client, and it should be someone other than the service provider and the client.

Since the service provider presumably trusts the client once they are authenticated then its not unreasonable to trust the client's organization to sign the client's certificate, however in practical terms it makes the service provider's life a lot more difficult to maintain a large number of CA certs.

The purpose of the certificate is to publicly identify an entity, hence while it is likely true that the client might trust the provider to sign a certificate for them, this will usually only provide a certificate which can be validated by the service provider. If the certificate was used in interactions with other providers, it gives the original provider control over the clients interactions with others.

Using a third party as the CA provides protection to both the client and the provider and separates the technical and organizational (contractual) issues around certificate management from the existing relationship around the service.