Requests

In this section, an operator can set policy for the following areas in the ADSS Web RA:

Certificate Signing Request (CSR) verification settings allows you to verify the key ownership, signature algorithm, strength of key exponents & modulus, Debian weak key, key lengths and key reuse while creating a CSR certificate on web portal.

To setup CSR validation policies, click on Enable CSR Validation, this will display some more options to configure as validation policy including Key Ownership, Signature Algorithm, Public Key Exponent & Modulus, Debian Weak Key, Public Key Reuse and Key Length.
On selection of one of the above configurations, that particular validation policy will be verified at the time of CSR generation. If one of the policies are not fulfilled then the certificate generation request cannot be completed.

These validation policies once applied, will be applicable across the application, and will validate these upon creation of CSR.

Expand Configurations > Policies > Requests from the left menu pane.

Enable CSR (Create Signing Request) Validation

To configure CSR validation policies, first of all you need to select the 'Enable CSR Validation' checkbox. You can tick the following checkboxes to configure settings for CSR generation:

Enable CSR Validation
Validation	Description
Verify the Key Ownership	Verify if the private key is in possession of the user who requested for a certificate at the time of CSR generation.
Verify the Public Key contains Valid Public Exponent and Modulus	Validate if the key length is among the allowed list of key lengths against the algorithm used in the CSR
Verify the Public Key is not already used	Verify if the public key is not already used in previously submitted requests, issued, created or revoked certificates
Verify the Key Length	Validate if the key length is among the allowed list of key lengths against the algorithm used in the CSR
Verify the Signature Algorithm	Verify the signature algorithms must be either RSA or ECDSA.
Verify that Debian weak keys are not used	Validate if the CSR keys are not generated using Debian Weak keys. Debian weak keys are generated because of a bug introduced in openSSL package in 2006. The bug was founded in 2008. All keys generated within that period are vulnerable and should not be used.

1) CSR Validation policies only validate when Enable CSR Validation is set.

2) When one of the above CSR validation policies is configured in ADSS Web RA admin, it validates these policies while approving a certificate request from ADSS Web RA user portal. If one of the CSR validation policies does not meet the criteria at the time of certificate request approval, enterprise RAO can decline the request by adding a reason to decline.

3) If one of the validation policies does not meet, it appears on decline reason dialog as a declining reason. Furthermore, RAO cannot proceed further.

4) If no validation policies failed, RAO can still decline a certificate request but there is no validation policy appears as a declining reason on decline dialog. A custom reason can be added though.

5) CSR-based validation only applies on those certificate requests where either a CSR is imported by the user, or a certificate request created using a PKCS#10, USB/Smart Card Tokens, request for Go> Sign using MSCAPI.

PIN Password Policy

Expand Configurations > Policies > Requests from the left menu pane.

This is a default policy that will determine the default values for PIN and govern the process for users or operators when resetting these credentials.

When enabled by the operator, it applies at the enterprise level. The selected settings and options are automatically reflected at the Enterprise level in the ‘Policies’ section.

When the operator enables the ‘Enable PIN Password Policy’ checkbox, the following fields will appear.

Fields	Description
Minimum Password Length	Defines the minimum number of characters required for a valid password.
Include numeric only	If enabled, only numeric values (for example, 123) can be used to set the PIN Password. Note: Enabling this checkbox disables all ‘Include 1 or more’ policy checkboxes, and only the numeric policy is saved.
Include 1 or more lowercase characters	If enabled, the password must contain at least one lowercase character.
Include 1 or more uppercase characters	If enabled, the password must contain at least one uppercase character.
Include 1 or more special characters	If enabled, the password must contain at least one special character.
Do not retain password	If enabled, the system does not store the PIN password in the application database after issuance or reset.
Force user to reset the password at first login	If enabled, users are required to reset their PIN password during their first login to the Web Portal.
Enforce second factor authentication for PIN access	If enabled, users are required to complete second factor authentication before accessing the token PIN.

The ‘Force user to reset the password at first login' policy is applicable only when the operator creates a request on behalf of a user from the Admin portal using a certificate request, and the user is registered through this request.

When this check box is enabled, the system will display a ‘SET TOKEN PIN’ dialog to the user during their first login, allowing them to reset the Token PIN. The user can skip the dialog to log in; however, the same dialog will continue to appear on each login until the user resets their Token PIN.

To select the secondary authentication method, navigate to Enterprise > Roles > Login Authentications, enable secondary authentication, and choose the required Secondary Authentication Profile. If secondary authentication is not configured in this section, the application will ignore the PIN/PUK policies that require secondary authentication.

PUK Password Policy

Expand Configurations > Policies > Requests from the left menu pane.

This is a default policy that will determine the default values for PUK and govern the process for users or operators when resetting these credentials.

When enabled by the operator, it applies at the enterprise level. The selected settings and options are automatically reflected at the Enterprise level in the ‘Policies’ section.

When the operator enables the ‘Enable PUK Password Policy’ checkbox, the following fields will appear.

Fields	Description
Minimum Password Length	Defines the minimum number of characters required for a valid password.
Include numeric only	If enabled, only numeric values (for example, 123) can be used to set the PUK Password. Note: Enabling this checkbox disables all ‘Include 1 or more’ policy checkboxes, and only the numeric policy is saved.
Include 1 or more lowercase characters	If enabled, the password must contain at least one lowercase character.
Include 1 or more uppercase characters	If enabled, the password must contain at least one uppercase character.
Include 1 or more special characters	If enabled, the password must contain at least one special character.
Enforce second factor authentication for PUK access	If enabled, users are required to complete second factor authentication before accessing the token PUK.

Request Settings

Expand Configurations > Policies > Requests from the left menu pane.

This section allows operators to configure the permitted actions for certificate requests.

Checkbox - Allow operators to create certificates on behalf of the user and facilitate automatic assignment

If this policy is enabled, the operators will have the option to generate certificates for users.

Note: If the certificate is being created for a user who does not exist in the system, a new account will be created for the user along with the certificate.

If the user already has a registered account in the WebRA system, only the certificate will be created. The user will be notified via email about the certificate generation.

Meanwhile, if the user exists in the system but is not part of the enterprise where the certificate is being created, the system will send an invitation for the user to join that enterprise and will generate the certificate as well.

Checkbox - Allow declined requests to be resubmitted

If this policy is enabled, users can resubmit a certificate request that has been declined. This allows them to modify the required details and submit the request again for approval.

Open MPIC Connector

The Open MPIC Connector is responsible for establishing a secure communication with the MPIC service to perform required validation checks during the creation of certificate request.

If you click the dropdown field, it displays all the active Open MPIC connectors created in the Web RA system.

You can select the required connector from the list, which will then appear in the dropdown field.

If you want to view the details of the selected connector, click the ‘Eye’ icon. The system will display the ‘Connector’ dialog with the complete information in read-only mode.

To remove the selected connector, click the cross ‘x’ icon present on the right side of the dropdown field.

Domain Configurations

This section allows an administrator to configure domain names and subdomain names at the global level of the Web RA application. The configured DNS names are used in the certificate request form to ensure that certificates are generated exclusively from the pre-configured domains.

Note: Any change in the Domain Configurations made from this section will be applicable globally to all Enterprises and Users. If the Domain Names field in this section is empty, then the domain settings of each Enterprise will be applied based on its individual configuration.

To add domain names at the global level, navigate to the Configurations > Policy > Requests module from the admin portal.

Enter the domain names in the ‘Domain Names (DNS) field. You can configure multiple domain names in this field.

To configure subdomains that are associated to the pre-configured domain names, enable the ‘Configure Subdomains’ checkbox. The system will display an additional Domain Names (DNS) field under the checkbox.

You can provide subdomain names associated to preconfigured domains only. The application will reject subdomains that are not associated with the main domain name (s).

Operators can configure subdomains that belong to the preconfigured main domain. For instance, if the domain name is webra.com.pk, the relevant subdomain would be web.webra.com.pk. The operator can also leave the subdomain unchecked; in that case, the main domain names will be used in the certificate creation process.
If the operator enters multiple domain names, they can also enter multiple subdomains corresponding to the selected domain names, which will be used in the certificate creation process from the ADSS Web RA web portal.
If the operator updates domain names and subdomains in the Configurations section, it will also impact the ‘Certificate Details’ section under the Registered Users section of the Enterprise. Click here to view domain names in the Certificate Details section.
In the case of TLS certificates, if domain names and subdomain names are configured at the enterprise level, operators and users of that enterprise can create certificates against those domain and subdomain names.
If domain names are not configured at the enterprise level, the system will work according to the configurations made at the admin level.

Certification Authority Authorisation (CAA) Records

Certificate Authorities (CAs) are organisations that are responsible for issuing identity-confirmation certificates for websites, digital IDs, and other entities. To restrict which CAs can issue certificates for your domain, you can configure a CAA record in your domain’s DNS settings.

A Certificate Authority Authorisation (CAA) record is a specific type of DNS record that enables domain owners to specify which CAs are authorised to issue certificates for their domain. By defining these preferences, unauthorized CAs are prevented from issuing certificates for the same domain.

Note: Any change in the CAA Records made from this section will be applicable globally to all Enterprises and Users. If the CAA Recrods checbox is disabled in this section, then the CAA Record setting of each Enterprise will be applied based on its individual configuration.

Configuring CAA records can help in the following situations:

You aim to reduce the risk of relying on untrustworthy Certificate Authorities (CAs).
You want to prevent employees from obtaining certificates from unauthorised certificate vendors.
You want to prevent fraudulent certificate misissuance.

To add Certificate Authority Authorisation (CAA) Records, expand Configurations > Policies > Requests from the left-tree menu and select the ‘Enable Certification Authority Authorisation (CAA) Records’ checkbox. The system will display the ‘Certification Authorities (CA)’ field where you can enter multiple authorities as per your requirement.

After entering the Certificate Authorities (CAs), click ‘Save’ to confirm the policy changes.