Idea ID: 2879046

Allow for Certificate Signing Request (CSR) process in order to setup secure comms (https/ssl/tls) between the Controller and all Generators.

Status: Waiting for Votes

Allow for Certificate Signing Request (CSR) process in order to setup secure comms (https/ssl/tls) between the Controller and all Generators.

Currently the controller and generators use self-signed certificates to attempt to secure the comms out of the box. Several issues exist from this method of use. Self-signed certs are being picked up by enterprise security vulnerability scanning engines as an elevated risk... regardless of if in use or not, as the server hostname and the Microfocus default / no hostname is not security best practice. Attempts to remove the self-signed certs have also proven futile; perhaps not knowing or finding all the self-signed certs or registry locations to remove it.

However; instead of removing the self-signed cert, it might be best to update the way these certs are signed /managed as is done in today's normal process. Simply having the LoadRunner Certificate Manager be able to accept user input of specific company certificate detailed info and then have it generate a .CSR file that the user can upload to its in-house Certificate Authority certificate signing process. Once the internal signing is complete then it could be imported into LoadRunner Certificate Manager as a signed cert and usable to secure the communications & in conjunction with performing the same steps on all the Load Generators involved as necessary to "enable" secure connection.

In addition, today MicroFocus / OpenText does allow the customer to use a local internal certificate from a CA but, then ask the customer to provide that CA's -PRIVATE- key, which should never be asked for in any modern configuration. The requirement for a private key should never be necessary or exposed for anything. Our company will never provide this as this not best practice in today's world.

In summary, please provide an updated way to generate a .csr file that can be signed by the customer's internal CA cert signing service/process. Then allow that signed cert be imported into the LoadRunner certificate tools where the communications can be secured normally. At the time the customer is able to utilize this standard process, the LoadRunner Certificate Manager should also allow the revocation and removal of all local self-signed certificates as they would then be unnecessary to pre-exist. Furthermore, should anyone want to use or create a self-signed certificate, then perhaps allow it to be created manually when needed, not pre-exist and just stored on the server in various and duplicate places. This would greately help with enterprise / corporate vulnerability scanners from detecting these non-utilized self-signed certs and therefore unnecessarily elevating system vulnerability risk levels and alerting the system owners, managers and others in the organization of these unnecessary self-signed certs existence.

  • Hello Steve
    Thanks for logging this, its a very valid request for enterprise security.

    There is a workaround:
    If your user can get a CA in their company, then in Cert Manager tool user can ignore CA private key which is optional when importing their CA file (exported somehow) You can then generate CSR separately via openssl utility and use it to get a signed certificate offline before specifying it in step 2 of the wizard

    In fact, the current cert manager implementation doesn’t block the expected flow.