'Certificate already exists' error when auto-enrolling clients
Originally Published: 2011-06-08
Article Number
Applies To
RSA Key Manager Client 2.5.0.x
RSA Key Manager Server 2.7 SP1
Microsoft SQL Server 2005
Issue
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
Cause
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.
Resolution
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
Workaround
Related Articles
Error 'NoSuchPropertyException: evaluation.mode' Number of Views healthCheck.do returns 'Get Key Error: 20010' and key-manager.log shows 'ClientID and Identity doesnot match' Number of Views How to export RADIUS server certificate on authentication manager 8 Number of Views How to create / recreate a cluster in EA environment Number of Views Password Available External email incorrectly defaults to localhost for hostname in RSA Identity Governance & Lifecycle Number of Views
Trending Articles
Passwordless Authentication in Windows MFA Agent for Active Directory – Quick Setup Guide RSA Authentication Manager 8.9 Release Notes (January 2026) RSA Authentication Manager Upgrade Process RSA Authentication Manager 8.7 SP2 Setup and Configuration Guide An example of SSO using SAML and ADFS with RSA Identity Management and Governance 6.9.x
Don't see what you're looking for?
