ADSS Web RA allows users to create certificate requests and can also perform actions such as renewal, revocation, and re-issuance of certificate requests. This section entails all such certificate request divided into various categories. 


Click "Requests". It will toggle down to a sub-menu that consists of the following items:


  1. Certificate Requests
  2. Renewal Requests
  3. Revocation Requests 
  4. Reissue Requests 



If vetting is enabled in a certification 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 as follows:


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


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


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 perform 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 he 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 perform appropriate actions (approve, update, or decline).
    • Can initiate a new certificate request using CSR, or generate 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 he finds the request is not correct. The administrator should also mention the reason for declining.



1) On creation of a new certificate request, it will be linked to an enterprise and the enterprise RAO has 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 certification 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 the external services 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.