000015566 - Issue with RKM 2.7 sample java client

Document created by RSA Customer Support Employee on Jun 16, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000015566
Applies ToRSA Key Manager Client 2.7.x
RSA Key Manager (RKM)
IssueIssue with RKM 2.7 sample java client

 RKM client error:

au.net.netstorm.boost.primordial.PrimordialException: client doesnot have the necessary privelege to register. either the client doesnot provide a certificate or the certificate provided is not trusted  at com.rsa.keymanager.server.api.emu.adapter.DefaultClientRequestHandler.checkRole(DefaultClientRequestHandler.java:112)


apache httpd had no issue with the certificate
certificate did not have a CN in its subject DN
Resolution

Issue was due to invalid client certificate.
 

This is one of the interesting scenario in the PKI-X509 world. Here are some of the points around this:

 

1.       What went wrong with the client certificate?

In fact, these certificates are correct in one way. It would have been worked fine, if this certificate got another extra field (Authority Key Identifier).

 

2.       Why this client certificate is special to look for an extra field?

This Client certificate?s subject name is same as the issuer (Root CA) certificate?s subject name. Due to this,  certificate chain creation went wrong, and ultimately the certificate validation got failed.

 

3.       How this extra field (Authority Key Identifier) helps, to use this certificate?

 

Before validating the client certificate, the certificate chain (upto the root) will be prepared.

 

There are three different ways to build the certificate chain :  Name Match,  Key Match and Exact Match.

 

Name Match, will be applied if the ?Authority Key Identifier? field does not exist in the client certificate. In this, the issuer name of the client certificate should match with the subject name of a issuer certificate, in order for the certificate to be chosen as a valid issuer. In this use case, as ?Authority Key Identifier? does not exist, it assumed that it is a self-sign certificate and tried to verify and got failed.

 

If the client certificate got ?Authority Key Identifier?, I does use this field to find the valid issuer of this certificate. In this case the real self-sign certificate will be fetched. So the certificate chain creation will be correct and the validation will be successful.

 

 

 

As shown in the above image an ?Authority Key Identifier? can have the Certificate Issuer, Serial Number  and KeyID.

KeyID is nothing but the hash of the public key, which will be used in Key Match mechanism to identify the valid issuer.

Certificate Issuer & Certificate Serial Number combination can help in identifying the valid issuer and this combination will be used in Exact Match.

 

In this current use case, if this Authority Key Identifier exists in the client certificate, then certificate chain validation would have been successful by using either Key Match or Exact Match mechanism.

Legacy Article IDa52460

Attachments

    Outcomes