Introduction


If the vetting is enabled in an ADSS Service Profile, any certificate request submitted by the end-user against that profile will be submitted to the Admin/ Enterprise RAO. The RAO will vet the request and then either approve for certificate issuance or can reject if it finds any issue in the request. These requests are categorised in three ways, i.e.:


  1. Certificate Creation - A request that is sent to Admin/ Enterprise RAO to issue a new certificate for a user.
  2. Certificate Revocation - A request that is sent to Admin/ Enterprise RAO to revoke an existing certificate of a user.
  3. Certificate Renewal - A request that is sent to Admin/ Enterprise RAO to renew an existing certificate of a user.



If the vetting is not enabled for any profile then no certificate request will be submitted to the admin operators for vetting.

How it Works?


The following are the business rules for the vetting and approvals:


  • An Admin RAO:
    • Receives the certificate requests and may approve, update, revoke, renew or decline them accordingly
    • Can initiate a create certificate request from the admin portal and can issue the certificates in a crypto device
    • Can see the certificate requests of all accounts and may take the appropriate actions (e.g. approve, update, or decline) against them
    • Can initiate a new certificate request using CSR, or generating a new key in smart card/token and can issue certificates against them
    • Can decline a request if it finds the request is not correct.
  • An Enterprise RAO:
    • Receives the certificate requests and may approve, update, revoke, renew or decline them accordingly
    • Can initiate a create certificate request from the admin portal and can issue the certificates in a crypto device
    • Can see the certificate requests that are related to their associated enterprises and may take the appropriate actions (approve, update, or decline)
    • Can initiate a new certificate request using CSR, or generating a new key in smart card/token and can issue certificates related to those service plans that are subscribed by their associated enterprises and issue certificates against them
    • Can also delete a certificate request that is related to their associated enterprises.
    • Can decline a request if it finds the request is not correct. The administrator provides the reason for declining.

1) On creation of a new certificate request, it will be linked to an enterprise and RAO must have to select an Enterprise Name while creating a new request.

2) For Super Admin, all the enterprises will be listed. For an enterprise RAO, only those enterprises will be shown to which that enterprise RAO belongs to. For an Admin RAO, only those enterprises will be listed for which that Admin RAO can perform vetting against certificate requests, as allowed under External Services > ADSS Service Profiles.

3) Upon performing any action (e.g. Certificate Approval, Revocation, Renewal or Deletion etc) the certificate request must be signed by the private key of RA to communicate with ADSS Server (i.e. CA), if Request Signing Key is configured under ADSS Server in External Services > Connectors > ADSS Server and ADSS Server certification service also has configurations set to sign all client request messages. RAS and CSP services do not support request signing configurations.


Submit a CSR


  1. Click Requests from the left menu.
    All the certificate requests (sent from Web RA and/ or added from Admin RA) related to the admin operator role will be listed.
  2. Make sure the Certificate Requests tab is opened.
  3. Click  from the grid header.
  4. A dialog will appear to specify the request details. See the below table for the fields description.
  5. Specify the details and click Generate.
  6. The status of the certificate request will be shown as Approved in the Requests Listing, while the certificate status will be shown as Issued in the Certificates Listing. 
  7. The certificate will be available for download.

1) CSR Validation policies only validates when Enable CSR Validation is set under Configurations > Policy.

2) When one of the CSR validation policies is configured in Web RA admin, it validates these policies while approving a certificate request. 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 declining reason.

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

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

6) An optional message can be added while approving a certificate request, which later also shows under email notification body against certificate approval email. For auto approval this option doesn't show, whereas in case of dual control the message only receives to user once the second reviewer approves a certificate request.


 Feature

Description

 Enterprise Name

This drop down shows the list of enterprises to link a particular certificate request to selected enterprise.

For Super Admin, all the enterprises will be listed. For an enterprise RAO, only those enterprises will be shown to which that enterprise RAO belongs to. For an Admin RAO, only those enterprises will be listed for which that Admin RAO can perform vetting against certificate requests, as allowed under External Services > ADSS Service Profiles.

Certificate Purpose

This field is populated based on the ADSS Service Profile purposes. The purpose in the ADSS Service Profile is taken from the related ADSS Certification Profile e.g. TLS Server Authentication, Document Signing etc. 

Verification Type

If Certificate Purpose is of TLS Server Authentication and in ADSS Service Profile the Verification Type is configured then the list will show up with following options, depending upon External Services > ADSS Service Profile configurations.

  • Domain Validated (DV)
  • Organization Validated (OV)
  • Extended Validation (EV)
  • None

Do you have a CSR? 

The administrator got two options to create a certificate when a user walks-in:

  • CSR - the keypair is generated in a third party application and you got the CSR (Certificate Signing Request) to certify it.
  • No CSR - the keypair will be generated in any device that is attached to the admin computer. The Distinguished Name input will be taken from the form submitted by the end user.  

Request Type

Currently, only one request type is supported i.e. to create the key on smart card/ token. This option is only shown when the user does not own a CSR and wish to generate the key in a crypto device

Certificate Type

Select the certificate profile that will be used to issue the certificate




1) An Admin RAO can upload a CSR while creating a certificate request. CSR Verification Status list shows error if Public Key is being used in of the existing certificate request, irrespective of the certificate request status (i.e. Approved, Pending etc.). A link appears next to Public Key Reuse, to navigate to that certificate request where uploaded CSR is already being used. 

2) While creating a certificate request, if you have $REQUEST selected as a certificate type in case of CSR or if your certification service profile (in case of server side certificate) that contains any Relative Distinguished Names (RDNs) with a $ symbol and it is set as overridable, then your Subject Distinguished Name (SDN) parameters will not be shown as mandatory but can be edited.