3

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.

4

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.

  • The last option seems a good choice for both the service and client side; service does not have to install new CA on their part and client does not expose its private key. Do you support this option or you still prefer that is the API Consumer to issue the certificate? – systempuntoout Jul 31 '18 at 14:51
  • Hmm, first version of this wasn't clear in terms of the terminology. I've edited it to make the details clearer: the client generates a CSR (which requires the private key), and then either generates a certificate themselves, or passes the CSR to the service provider or third party. The important part is that they make the CSR, not the service provider. – Matthew Jul 31 '18 at 14:57
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.

  1. 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.

  • Are you sure for the statement at the end? I've seen big entities that prefer to access with their own Private Key (Provided by a trusted CA). – systempuntoout Jul 31 '18 at 14:17
  • You are misunderstanding terms. Private key is generated by clients, it is their responsibility). But public key is signed by trusted CA. In other words, client generate the key, authenticates on CA server and gets signed public key/certificate. – Crypt32 Jul 31 '18 at 16:55
  • 1
    see updated response. – Crypt32 Jul 31 '18 at 17:31
1

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.

  • I disagree with it should be someone other than the service provider and the client. In fact, in many cases service provider runs their own CA and issue certificates to a previously approved list of clients (entities). Alternatively, when there is B2B scenario when flexibility is required and both companies run their own private PKI, the question is resolved via qualified subordination when service provider issues cross-certificate for client company and client company is now responsible to issue client certificates to access service. It really depends on a number of factors. – Crypt32 Jul 31 '18 at 17:04
  • Good luck trying to resolve non-repudiation issues in court. – symcbean Aug 1 '18 at 8:27
  • TLS doesn't even try to provide nonrepudiation of data (in either direction) – dave_thompson_085 Aug 11 '18 at 5:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.