000017805 - 'Certificate already exists' error when auto-enrolling clients

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

Article Content

Article Number000017805
Applies ToRSA Key Manager Server 2.5.0.2
RSA Key Manager Client 2.5.0.x
RSA Key Manager Server 2.7 SP1
Microsoft SQL Server 2005
Issue"Certificate already exists" error when auto-enrolling clients
RKM Client auto-enrollment failing with the following exception in key-manager.log on the server side:

30 May 2011 11:03:28,027 1306767807745 anonymous (-1) INFO TP-Processor2 - Client : Internal, Created identity ID3333
30 May 2011 11:03:28,027 1306767807745 anonymous (-1) ERROR TP-Processor2 - NO LOG MESSAGE
com.rsa.keymanager.core.auth.e.DuplicateCertificateException: Certificate already exists: com.rsa.keymanager.core.identity.DefaultCertificate@16a38b9
 at com.rsa.keymanager.core.database.sql.cud.DefaultCertificateAuthenticationCud.checkForDuplicates(DefaultCertificateAuthenticationCud.java:78)
 at com.rsa.keymanager.core.database.sql.cud.DefaultCertificateAuthenticationCud.bindIdentity(DefaultCertificateAuthenticationCud.java:35)
 at com.rsa.keymanager.core.natural.core.DefaultCertificateAuthenticationOperations.bindIdentity(DefaultCertificateAuthenticationOperations.java:11)
 at com.rsa.keymanager.core.natural.core.DefaultAuthenticationNatural.bindCertificate(DefaultAuthenticationNatural.java:30)
 at com.rsa.keymanager.core.natural.core.SecureAuthenticationNatural.bindCertificate(SecureAuthenticationNatural.java:35)
 at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at au.net.netstorm.boost.nursery.proxy.DefaultMethod.invoke(DefaultMethod.java:26)
 at com.rsa.keymanager.core.entry.LogLayer.invoke(LogLayer.java:42)
 at com.rsa.keymanager.core.entry.LogLayer.invoke(LogLayer.java:35)
 at au.net.netstorm.boost.util.proxy.LayerInvocationHandler.invoke(LayerInvocationHandler.java:20)
 at $Proxy12.bindCertificate(Unknown Source)
 at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at au.net.netstorm.boost.nursery.proxy.DefaultMethod.invoke(DefaultMethod.java:26)
 at au.net.netstorm.boost.spider.onion.layer.passthrough.DefaultPassThroughLayer.invoke(DefaultPassThroughLayer.java:9)
 at au.net.netstorm.boost.util.proxy.LayerInvocationHandler.invoke(LayerInvocationHandler.java:20)
 at $Proxy12.bindCertificate(Unknown Source)
 at com.rsa.keymanager.core.api.DefaultSimple.bindCertificate(DefaultSimple.java:302)
 at com.rsa.keymanager.core.api.SecureSimple.bindCertificate(SecureSimple.java:229)
 at com.rsa.keymanager.core.audit.AuditSimple.bindCertificate(AuditSimple.java:154)
 at sun.reflect.GeneratedMethodAccessor104.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at au.net.netstorm.boost.nursery.proxy.DefaultMethod.invoke(DefaultMethod.java:26)
 at com.rsa.keymanager.core.entry.LogLayer.invoke(LogLayer.java:42)
 at com.rsa.keymanager.core.entry.LogLayer.invoke(LogLayer.java:35)
 at au.net.netstorm.boost.util.proxy.LayerInvocationHandler.invoke(LayerInvocationHandler.java:20)
 at $Proxy3.bindCertificate(Unknown Source)
 at sun.reflect.GeneratedMethodAccessor104.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at au.net.netstorm.boost.nursery.proxy.DefaultMethod.invoke(DefaultMethod.java:26)
 at au.net.netstorm.boost.spider.onion.layer.passthrough.DefaultPassThroughLayer.invoke(DefaultPassThroughLayer.java:9)
 at au.net.netstorm.boost.util.proxy.LayerInvocationHandler.invoke(LayerInvocationHandler.java:20)
 at $Proxy3.bindCertificate(Unknown Source)
 at com.rsa.keymanager.server.api.crow.adapter.DefaultClientRequestHandler.createIdentityObjects(DefaultClientRequestHandler.java:166)
 at com.rsa.keymanager.server.api.crow.adapter.DefaultClientRequestHandler.retrieveKeyStore(DefaultClientRequestHandler.java:299)
 at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown Source)
Just prior to the failed client auto-enrollment, other auto-enrollments were successful.  The following entries in key-manager.log show successful enrollment:

30 May 2011 11:03:19,167 1306767798886 anonymous (-1) INFO TP-Processor2 - Client : Internal, Created identity ID2222
30 May 2011 11:03:19,167 1306767798886 anonymous (-1) INFO TP-Processor2 - Client : Internal, Bound certificate authentication to identity ID2222
30 May 2011 11:03:19,183 1306767798886 anonymous (-1) INFO TP-Processor2 - Client : Internal, Auto enrollment succeded for profile 'MyTestProfile', new identity 'ID2222' created with certificate[subject=CN="Certificate 555555 ", O=Acme, serialnumber=150000007798270541111222]
30 May 2011 11:03:19,246 1306767799230 ID2222 (10687) INFO TP-Processor2 - Client : 10.10.10.2, Client registered with the following details, appname=ID2222, hostname=someclienthost.acme.net, ip=10.10.10.2, version=2.5, managed=false, identity=ID2222
CauseDue to a bug in RKM Server, duplicate PKCS#12's were uploaded resulting in an attempt to assign a duplicate PKCS#12 / certificate (which has already been previously assigned to another client) to a new client during auto-enrollment process.

If a large batch (approximately a few hundred or more) of PKCS#12 files are uploaded through /KMS GUI bulk upload option (Settings => Auto Registration Profiles => Manage Certificates => Bulk Upload), the browser session may time out.  As a result an administrator may try to upload the same batch again a second time shortly after the first apparently failed attempt.  Although browser may appear to time out, the first transaction to upload the PKCS#12 carries on in the background while the second upload attempt (of the same batch of PKCS#12) also begins.  Due to a bug in RKM Server, concurrent uploads of the same batch of PKCS#12 will be successful resulting in duplicate PKCS#12 in the pool of certificates.  Note that outside of the concurrent uploads of the same batch of certificates, RKM ensures that an already existing PKCS#12 (in the pool of certificates) or an already assigned certificate (to an identity) is not allowed for upload again.
ResolutionThis problem of allowing upload of duplicate PKCS#12 (when same batch is uploaded twice at the same time) has been fixed in RKM Server 2.7.1.3.

If you have already run into the issue with duplicate PKCS#12 in the pool of certificates, the duplicate PKCS#12's must be deleted from the database.  Follow the procedure below to confirm existence of duplicates and how to remove the duplicates:

A) Find out if duplicates exist:

1. Run the following query. This first query will give you a count of the duplicates:

  select hashbytes('MD5', keystore_data) keystore_data, count(keystore_data) as cnt
  from autoreg_keystore
  group by keystore_data
  order by cnt desc;

On RKM Appliance (Oracle database), the same query will look like the following:

  select DBMS_Crypto.Hash(keystore_data, 2) keystore_data, count(keystore_data) as cnt
  from local.autoreg_keystore
  group by DBMS_Crypto.Hash(keystore_data, 2)
  order by cnt desc;


Sample output for the above query:

  keystore_data                            cnt
  ---------------------------------------- -----
  0x99961FA44097E1C94734A89FFA0ECF16       2
  0xF318C5DD6A2B4F015CCE113DA1A3A220       2
  0xFA8F0E8A62F50BD3E92A450ADA6A0568       2
  ...
  0x37EED62E3BC97CF384519BF9DE5F564F       1
  0x277DDC4C0BFF0489529B18F026431FD8       1
  (500 row(s) affected)

In the above sample output, say if a batch of 500 was uploaded twice and auto-enrollment for 185 clients was successful then every subsequent enrollment failed, you would see a total of 500 rows with 315 rows with a count of 2 and 185 rows with a count of 1.

2. If you get the second column value for all rows as 1, then that would mean there are no duplicates in the table (pool of certificates / PKCS#12). If you see any one row that has greater than value 1 (which would be the case if there are duplicates), then run the second query below to identify the rows that are duplicate:

  select a.keystore_id keystore_id, hashbytes('MD5', a.keystore_data) keystore_data, key_alias
  from autoreg_keystore a
  where 1 < (select count(*)
  from autoreg_keystore b
  where a.keystore_data = b.keystore_data
  having count(*) > 1)
  order by 2,1;

On RKM Appliance (Oracle database), the same query will look like the following:

  select a.keystore_id keystore_id, DBMS_Crypto.Hash(a.keystore_data, 2) keystore_data, key_alias
  from local.autoreg_keystore a
  where 1 < (select count(*)
  from local.autoreg_keystore b
  where DBMS_Crypto.Hash(a.keystore_data, 2) = DBMS_Crypto.Hash(b.keystore_data, 2)
  having count(*) > 1)
  order by 2,1;


Sample output for the above query:

  keystore_id keystore_data                        key_alias
  ----------- ------------------------------------ ----------
  7348        0x00784413F7C84D1C385A759D7F3D3DA0   10398
  7520        0x00784413F7C84D1C385A759D7F3D3DA0   10897
  ...
  7311        0x99961FA44097E1C94734A89FFA0ECF16   10383
  7505        0x99961FA44097E1C94734A89FFA0ECF16   10882
  ...
  7316        0xF318C5DD6A2B4F015CCE113DA1A3A220   10385
  7507        0xF318C5DD6A2B4F015CCE113DA1A3A220   10884
  ...
  7353        0xFA8F0E8A62F50BD3E92A450ADA6A0568   10400
  7522        0xFA8F0E8A62F50BD3E92A450ADA6A0568   10899
  ...
  (630 row(s) affected)

In the above sample output, say if a batch of 500 was uploaded twice and auto-enrollment for 185 clients was successful then every subsequent enrollment failed, you would see a total of 630 rows (for 315 duplicate records) for those records that showed count as 2 in query #1.


B) Delete duplicates:

Note that there are two scenarios here (for duplicate PKCS#12 / certificates in the pool):

- Duplicate PKCS#12 exist in the pool of certificates (AUTOREG_KEYSTORE table) that are not yet assigned to any identities. The SQL queries provided steps #1 and #2 help determine those duplicate PKCS#12 records.

- Some of the duplicate PKCS#12 / certificates in the pool have already been assigned to identities/clients that have successfully enrolled, and their duplicates still exist in the pool (AUTOREG_KEYSTORE) but would show up with count 1 in the query in step #1.

3. Before proceeding, make a backup of the database.  Alternatively AUTOREG_KEYSTORE table can be backed up using the following SQL query:

  SELECT * INTO AUTOREG_KEYSTORE_back FROM AUTOREG_KEYSTORE;

4. Stop RKM Server (stop application server)

5. If there are duplicates, the following sql statement successfully removes the duplicate p12s from AUTOREG_KEYSTORE table in Micorsoft SQL Server 2005:

  with cte as (
  select row_number() over ( partition by KEYSTORE_DATA order by KEYSTORE_DATA ) as id ,KEYSTORE_DATA from AUTOREG_KEYSTORE
  )
  delete from cte where id !=1;


6. Also remove any PKCS#12 in the pool that show up as a count of 1 in the query in step #1 above, but their duplicates have already been assigned to identities/clients that have successfully enrolled.

7. Start RKM Server (start application server)

8. Now resume auto-enrollment for the rest of the clients that have not yet enrolled.
KMSRV-1234
KMSRV-1551
WorkaroundUploaded a batch of PKCS#12 (certificates) on KMS gui for client auto-enrollment (/KMS => Settings => Auto Registration Profiles => Manage Certificates => Bulk Upload).
Legacy Article IDa55041

Attachments

    Outcomes