Certificate Inventory and Management and Request "types" (Manual/Automatic)

[Tone1]

Hi everyone,

Our Certificate Inventory and Management system offers two distinct request "types": one for automatic certificate issuance and another for manual issuance.

My question is: Why the separation, and how can we simplify this for our end-users?

In most cases, the requestor isn't aware of the underlying infrastructure. We operate multiple PKIs across various domains (external, internal, production, development, etc.). Some of these PKIs support automatic issuance, while others require manual intervention.

Is there a way to use a single request form for the end-user that can accommodate both manual and automatic issuance, without heavily modifying the out-of-the-box automatic request workflow?

Any insights or suggestions would be greatly appreciated!

[Abbas_5]

Hello @Tone1,

The separation into automatic and manual certificate request types exists because some certificate requests can be automated based on pre-defined criteria, while others require manual review and intervention due to specific needs or complex requirements. To simplify this for end-users, a single, intelligent form can be used where the system automatically determines the issuance type based on the user's input and pre-configured rules. This allows users to submit a single request while the system handles the underlying process. 

Why the Separation?

• Automation:

  Automatic issuance streamlines the process for common, well-defined certificate requests, saving time and resources.
• Manual Review:

  Manual issuance allows for handling unique or complex cases, ensuring compliance with specific requirements or policies that cannot be automated.
• Different Infrastructures:

  Different KPIs (Key Performance Indicators) and domains might have varying infrastructure requirements and security protocols, necessitating different issuance processes. 

Simplifying for End-Users

Instead of separate forms, a single, intelligent request form can be implemented. This form would:

1. 1. Collect Information:

   Gather all necessary information for certificate requests (e.g., domain name, purpose, validity period). 
2. 2. Automated Logic:

   Utilize the collected information to determine if the request can be automatically fulfilled based on predefined rules and configurations. 
3. 3. Conditional Fields:

   For requests requiring manual review, display additional fields or information requests as needed, potentially triggered by specific selections within the initial form. 
4. 4. Hidden Logic:

   The system can handle the underlying logic of whether to trigger automatic or manual workflows, keeping the process transparent to the end-user. 

Example

A user requests a certificate for a publicly accessible web server. The system, recognizing the domain and environment as suitable for automated issuance (based on configured rules), would automatically fulfill the request. If the user requests a certificate with custom settings or for a non-standard environment, the system might route the request for manual review and intervention, displaying additional fields for the reviewer. 

If this is helpful, please hit the thumbs up button and accept the correct solution by referring to this solution in future it will be helpful to them.

Thanks & Regards,

Abbas Shaik

[Tone1]

Hi Abbas, sorry but your input is not really helpfull.

All the automatisation in your example is handled via routing policies, but in the end the enduser have to decide if he needs a manual issued certificate or an automated, because those are two different request OOTB. Why there is no routing policy to route a request to a manual cert task is beyond me, that i can build a request around this issue myself, i know, but i dont want to and aim to keep as close to OOTB as possible.

But maybe i'm wrong in my assuption and somebody with more inside into the technical aspects of cert mgmt can help.