000022373 - Subject Key Identifier field is not unique when using Keon Certificate Authority API

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 Number000022373
Applies ToKeon Certificate Authority 6.5.1 API
Sun Solaris 2.8
Microsoft Windows
IssueSubject Key Identifier field is not unique when using Keon Certificate Authority API
XudaEnforceProfile being used
After using the sample code provided with the Keon Certificate Authority server against a Jurisdiction profile that has SSL extensions set as mandatory, the generated SSL-certificates appears to have a non unique Subject Key Identifier field. According to an ASN1parse, it holds the following value:

OBJECT :X509v3 Subject Key Identifier
 974:d=9 hl=2 l= 15 prim: OCTET STRING 0000 - 04 0d 41 55 54 4f 5f 47-45 4e 45 52 41 54 45 ..AUTO_GENERATE

According to RFC3280, this should be a SHA-1 of the public key.
Certificate SKI extension contains the text "AUTO_GENERATE"
CauseThe customer is using the function call XudaEnforceProfile() in the API. The purpose of this function is to ensure a Certificate request matches any given Profile in the KCA before it is submitted for Signing. If the request does not match all the requested certificate extensions in the Profile, it will provided an updated request that includes them. The resulting request can be manipulated further or presented to a Jurisdiction that does not necessarily have those extensions enforced.

In this instance the SKI extension has been set in the profile used in XudaEnforceProfile. The value for this extension is generated at the time of signing by the CA, so the function call does the best it can and creates a 'dummy' extension with fake data ('AUTO_GENERATE').
ResolutionWhen using the KCA API  you create an object called the 'session' that contains all the data needed for signing; for instance the KCA host name, port to contact it over, whether to use SSL etc. This 'session' object can also have the Profile ID put in it. So when the API comes to sign the request it will sign it according to the details in the Session, and as this is done by the CA the SKI extension is created correctly. XudaEnforceProfile should not be used to force extensions in the request that are a function of the CA.
Legacy Article IDa28068