vSEC:CMS FAQ

• We will stop supporting Windows 2012 and 2012 R2 Server starting October 2023.
• We will stop supporting database schemas of the versions 1-3 (used by vSEC:CMS systems before 6.0) starting January 2024.
• We will stop supporting the SOAP client interface starting March 2024.
• We will stop supporting 32-bit vSEC:CMS server and vSEC:CMS admin/agent applications starting September 2024.
• We will stop developing the SOAP API starting January 2024.

Yes. You can purchase additional licenses at any time. Please look at the article titled License Management for more details.

Yes. Please refer to the article titled Overview for details.

Yes. Extensive administration guide, use case workflow configuration guide and video tutorials are available. Best place to start is from the Home page of the support portal.

If you would like to get more information about the product please contact our partners located in your area from here.

Alternatively, you can test drive vSEC:CMS by registering here to download our evaluation version or please contact us directly by email at info@versasec.com

This can be done using what we call multiple-role. Please refer to the article title Multiple Role Support for details.

Yes. All known open issues are described here

The server on which the system is installed is the single point of failure. A fully clustered configuration is recommended when deploying the vSEC:CMS to avoid system failure. It is possible to configure failover using Microsoft clustering capabilities. Please refer to the article titled Failover Configuration for further details on this.

The System Owner (SO) hardware credential is created when setting up the system on first use. Please refer to the article title Setup Evaluation Version for details on this and look in the section Creation of System Owner Hardware Credential.

It is possible to manage a number of different credentials (physical and virtual). A full list of supported credentials can be found here.

Option 1:

Check your registry and see if this key is set –

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\EscDomains\security_vSEC_CMS_T.exe

If not, can you set it and try to open the vSEC:CMS console again.

Options 2:

In Internet Explorer, go to Tools - Internet Options - Advanced. Scroll down to the Security section and check the box for Allow active content to run on files on My Computer and restart the server.

Option 3: (not recommended)

Turn IE enhanced security settings off.

This error can occur if the key store service is not activated. From the vSEC:CMS console check Options – Operators and make sure the type Service key store is activated.

This can happen if the expected default administration key value on the credential is not set. Please ensure that the smart card administration key value is the default value as expected by vSEC:CMS. You can check what is configured from Options - Smart Cards and when in this page attach the credential that you want to check. The table should be filtered for the credential attached. Then you can check what is configured for this credential.

For highest levels of security the security keys should be stored in hardware. It is recommended to use HSMs to achieve the very highest levels of security.

A customer with a valid support and maintenance contract can download the latest version from our support portal here and follow the DOWNLOADS link.

There are several reasons why you should renew your S&M contract.

These are:

• Software systems that bind several components together, in this case vSEC:CMS, have many external dependencies. When external systems change (and they do all the time – for example Windows update and similar) vSEC:CMS needs to be updated. Therefore we release new versions every quarter. These new versions are delivered as part of the S&M service. If an S&M contract is not in place, getting an update will be priced as buying a new license, i.e. user licenses, plus system licenses and mandatory 1 year of S&M.
• Customer will not receive any support should any issues be encountered;
• Customer will not be entitled to new versions of the system which include new features and bug fixes.

It is possible to share an operator credential BUT this is not recommended for security and traceability reasons. Therefore, it is recommended to issue an individual credential for each operator that uses the system.

This error can typically occur if you are using an SCM reader SCR3310 or SCR3311. The workaround would be to use a different reader when using the operator credential with the system.

This is typically seen if the PIN policy settings that are being applied to the credential are not supported. Make sure that all PIN policy settings are supported on the credential.

This is typically seen when using Microsoft CA. It is necessary to have a fully qualified domain name for your DC server. If you are using an IP address to connect to the DC server make sure that the IP address is resolvable. It may be necessary to add the DC to your local host file for example.

This error can occur if the key store service is not activated. From Options – Operators make sure the Type- Service key store is activated.

A good test is to check that you can issue certificates through the Microsoft MMC from the system where the vSEC:CMS is running. If you cannot issue certificates through the MMC then it is probably an issue with your CA setup. The recommendation would be to consult with your CA administrators to resolve.

Make sure that the account configured to connect to the CA is an account which is a domain account with appropriate permissions on the CA.

GP keys and Minidriver keys have different purposes:

The GP Keys gives you access to the card at the platform level. With the GP key, it is possible to remove and add applet(s) on the card.

The minidriver admin key belongs to the PKI applet. With the minidriver admin key, it is possible to perform admin operation on the PKI applet such as unblock user PIN for example.

In most cases, a customer does not need to get access to the GP keys as the applets are preloaded on the card and will never change. So the only thing that needs to be done is to modify the value of the GP Keys of each card to an unknown value so that it won’t be possible to perform admin operations at the platform level on the card anymore.

The minidriver admin key must remain known as it may be required if the card needs to be unblocked or if some parameters need to be changed. As a result, the first thing vSEC:CMS will do is to change the default admin key value of the card to a unique value that will have been generated by the vSEC:CMS master key securely. That way only the vSEC:CMS will be able to recalculate this value if it is to perform smart card token pin unblock in the future for example.

This is typically because the Windows user account cannot access the dat folder and/or cannot write/execute in the dat folder. Make sure that the Windows user account can access and read/write/execute in this folder.

Additionally, check that the registry key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Versatile Security\vSEC_CMS_T\Service\autorecover] is set to a value of 0.

This can be a caching issue on the client. From vSEC:CMS User application console select from file menu File - Clean Configuration Cache to resolve.

This can be a caching issue on the client. From vSEC:CMS User application console select from file menu File - Clean Configuration Cache to resolve..

There are a number of reasons why this might happen:

1. The card template that you use is not configured to create VSC. Check the card template from the Issue Card dialog and make sure that VSC is configured to be created in the template.

2. If the client operating system is Windows 7 you need to make sure that you have installed Versasec vSEC:CMS VSC.

3. If the client operating system is Windows 7 you need to make sure you have enabled support for Versasec vSEC:CMS VSC from Options - Virtual Smart Card and make sure to click the Apply button.

There can be a number of reasons why this error is reported:

1. The vSEC:CMS Virtual Smart Card Service may not be running on the client or in an unstable state. Try restarting the service and see if that resolves the issue.

2. The client may already have a vSEC:CMS VSC issued but for some reason it is in an unusable state and not being presented correctly to the host system. If this is the case follow the steps below to resolve:

a. Close the vSEC:CMS User application console if open.

b. Open services.msc. Stop the vSEC:CMS Virtual Smart Card Service service.

c. Open C:\Program Files\Versasec\vSEC_CMS Virtual Smart Card in Explorer

d. Take ownership of the dat folder. Right-click on the folder and from Properties - Security - Advanced - Owner - Edit, click user, OK, OK, OK.

e. Navigate to dat folder (pressing Continue to grant yourself access permissions).

f. Take ownership of the card folder. Right-click, Properties, Security, Advanced, Owner, Edit, click user, OK, OK, OK.

g. Navigate to card folder (pressing Continue to grant yourself access permissions).

h. Delete all files in card folder.

i. Navigate up a level and delete the card folder.

j. Navigate up a level and delete the dat folder.

k. In services.msc, start vSEC:CMS Virtual Smart Card Service.

l. Launch vSEC:CMS User application to test that it works.

Follow these steps to resolve this issue:

1. On host where you run the vSEC:CMS console open up regedit.

2. In [HKEY_CURRENT_USER\Software\Versatile Security\vSEC_CMS_T] create a DWORD named app.behave.showsupport and give it a value of 1.

3. Start the vSEC:CMS console and log on.

4. Make sure to Revoke – Retire – Unregister the operator card that is being reported as already being assigned to another user from the Lifecycle page.

5. In the file menu go to Help – Support Console and in the dialog select Sanity check for Operator accounts and click Perform.

6. If the check reports errors select the option to fix them.

7. Close the vSEC:CMS console.

8. Refer to the article Activator Tool and look in the section Issue OT. You should firstly remove the current applet (Clean Smart Card) and then issue a new one.

9. Restart the vSEC:CMS Service and reopen console and try to issue again.

This typically can happen if the CMS database is large in size and therefore the other services cannot start because the vSEC:CMS Service takes some time to startup. A workaround is to change the wait time for the CMS services in a CFG file that is installed on the server. Open up the file CmsServiceDll.cfg, typically found here C:\Program Files (x86)\Versasec\vSEC_CMS S-Series, in a text editor. Then modify the entry <waitforcms>200000</waitforcms>. This is the default value which is a 20 second delay for these services to start. A suggestion is to increase this to 3 minutes, therefore change the value to <waitforcms>1800000</waitforcms>. Save the changes and close the CFG file. Then when you reboot the server again you should see that the services do start up automatically.

This typically can happen if the Enrollment Agent (EA) signing certificate is not configured on the CMS server. From Options - Operators click the Cert request signing button and ensure that an EA certificate is selected.

This typically can happen if the Enrollment Agent (EA) signing certificate is not configured on the CMS server. From Options - Operators click the Cert request signing button and ensure that an EA certificate is selected.

It is recommended to configure the EA to sign server side. See the article Configure Server-side EA Signing MS CA for details on how to configure in this way.

This typically can happen if the Use from domain option is selected for the CA connection and/or the correct permissions on the certificate template are not configured for the Windows service account that the vSEC:CMS is running under. The security permission on the certificate template at minimum needs to be set to Enroll.

This typically can happen if the Use from domain option is selected for the CA connection and/or the correct permissions on the CA are not configured for the Windows service account that the vSEC:CMS is running under. The Windows account that the vSEC:CMS service runs under needs to have Issue and Manage Certificates permissions on the CA, which are configurable from the certsrv console on the CA.

Additionally, the warning could be due to restrictions that may be set for remote access on the CA. Please check the Interface Flags as defined in MS Certificate Services Remote Administration Protocol. This flag is configured on the CA server in the registry key: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\{CA Name}\InterfaceFlags]. It is expected that a skilled MS Certificate Services engineer would be performing this check.

It is recommended to configure the EA to sign server side. See the article Configure Server-side EA Signing MS CA for details on how to configure in this way.

This can occur for a number of reasons. Here are the most common reasons why this can happen:

a) If you are issuing the credential from the Lifecycle page of the Operator console a valid Enrollment Agent (EA) certificate needs to be available to the Operator that was used to log into the Operator console. You can check that a valid EA certificate is installed from the Options – Connections page and click the Edit button for the CA connection that you use. Then you should check from the Enrollment Agent section that an EA is configured for use.

b) If you get this error when issuing a credential via USS then you should check either of the following:

• Make sure that the CA is actually operational;

• Check that a valid EA certificate is configured from Options – Operators and click the Cert request signing button. You should have a valid EA already selected in the Certificate(s) drop-down list and a message below this saying Store at: System, service user.

This can occur if the permissions on the dat folder on the server are not configured for the specific Windows account that the vSEC:CMS service runs under. Make sure that the Windows account has full permissions on this folder and all files located within this folder.

This is an error from your Microsoft CA. For a CA that is running in a DC environment the CA connection should be configured as described in the article Setup Evaluation Version in the section CA Configuration.

This error can occur if a user is moved to a different OU in the user directory. Since the vSEC:CMS uses the user’s DN to renew the certificate it will be necessary to adjust the DN as stored in the vSEC:CMS database. From Repository – Smart Cards select the user from the table that needs to be adjusted and click the Fix ID button. Then from the dialog that appears click the Get ID button and search for the user that needs to be adjusted. Click Ok and enter your operator PIN when prompted. A success dialog will appear informing you that the user record has been updated. You will now be able to renew the certificate on the credential.

This error will occur if there is no authentication key in the CMS for the operator credential that you are attempting to log on with. The issue can be resolved by having another operator log on and then navigate to Options – Operators and connect the operator card that you received the error with. Then select the operator from the table and click the Update keys button. You will be requested to select the card reader that the operator card is inserted into and click Ok. The application will then update the system with an authentication key. Once done you can log off the CMS console and attempt to log on with the operator card that failed before.

The time taken to issue a credential has several factors that can affect this. In best conditions, based on recommended hardware requirements as described in the Overview article, it can take approximately 1 minute 30 seconds to issue a credential where 1 certificate is issued.

Factors that can influence the time taken are as follows:

The credential that is being issued can influence the timings. The credential has an operating system. Therefore, the time taken to issue the credential will be influenced by the speed at which the credential can perform operations on it. This is token (hardware) dependent and not influenced by vSEC:CMS.

The network speed will have a determination on the speed at which a credential can be issued. The slower the network the longer it will take to issue the credential.

The number of certificates issued to the credential during the issuance will have an affect in the time taken to issue it.

If printing is to be part of the credential issuance then this will have an affect on the time taken. Typically, and this is dependent on the smart card printer and whether RFID encoding is also carried out, this can add an additional 2minutes+ to the time taken to issue the credential.

An important final point to know about vSEC:CMS is how the issuance process works. During the issuance process, and in order to minimize the risk of permanently damaging the credential, vSEC:CMS performs each step in the issuance process as an isolated event, i.e. after the event is completed then the next step will be performed. Because of this some tasks are repeated which adds to the issuance time. Taking this approach, we ensure that if the connection breaks or the credential is removed or something else happens during the credential issuance the credential can still be recovered and used.

This usually occurs if the Enrollment Agent (EA) for the operator who is issuing the card is not configured/available on the system. You can check that a valid EA certificate is installed from the Options – Connections page and click the Edit button for the CA connection that you use. Then you should check from the Enrollment Agent section that an EA is configured for use.

It is recommended to configure the EA to sign server side. See the article Configure Server-side EA Signing MS CA for details on how to configure in this way.

This usually occurs when a MS certificate services CA is used and the Enrollment Agent (EA) certificate, that is used when issuing on behalf-of, has expired. It will be necessary to issue a new EA as it is not possible to renew a certificate from the MS certificate services CA when it has already expired. See the article Update Enrollment Agent Certificate for details on this.

It is recommended to configure the EA to sign server side. See the article Configure Server-side EA Signing MS CA for details on how to configure in this way.

This can occur if the disk space on the vSEC:CMS server is full OR the vSEC:CMS service is not able to write to the SQL database if this is used. In either case you should check the disk space on the server where vSEC:CMS is installed and check your SQL database if the vSEC:CMS is configured to use MS SQL.