Certificate Signing Requests
A Certificate Signing Request (CSR) is what is required to allow for the creation of a digital certificate. Typically as part of creating a CSR, you also generate the key pair that will be used, being the private and public key. The private key (where possible) should be generated and remain on the device that it was generated for. The public key must be generated with the private key (as they are mathematically related) and is inserted into the CSR. It is not necessary to protect the public key and in fact it is important that this be known by parties wishing to use the keys for electronic transactions.
CSR Generation Approaches
Generation on the Gateway Service
Where CSRs can be generated on the device on which they are to be used this is the preferred method of creation of the CSR.
Generating CSRs on the device on which they are used allows the private key that is generated as part of the process to be stored within the available key store on the device and ensure it is never exposed externally to the device. Elimination of transferring the key from service to service significantly reduces the possibility of the private key being compromised.
Examples of this may be the generation of the private key within
- a Hardware Security Module (HSM);
- a Smart Card;
- the Windows Security Store;
- a p12 or Pfx file; or
- Java Key Store equivalent.
When generating a CSR and the private key is created within a key store, and depending on the capability of the key store, they can be marked as non-exportable or protected from export with PINs / Passphrases immediately ensuring that the risk of compromise is extremely limited.
CSR Generation within Jellyfish
While not the preferred method, Cogito’s Jellyfish product provides an alternative method to generating the CSR on the device or service for which it is intended, where this is not practical or desirable. Jellyfish has a simplified method of generating CSRs where the information required to generate a certificate can be entered into a form within the Jellyfish interface and the private key and CSR will be generated within the Client session.
Once the CSR is generated it is submitted for processing by the Certification Authority. When the certificate is signed and returned the interface creates a p12 file containing the certificate and the private key, which can then be saved by the user. If the user leaves the session before for the signed certificate is returned the private key is destroyed and the certificate must be re-requested.
The Jellyfish interface provides a more friendly non-technical, guided user experience to the generation of CSRs and also removes the private key from the service once the browser session is closed.
Script/Batch File Process
CSRs could be generated through the use of a script or batch file process that generates the keys and CSR.
Generation of the CSRs by a batch or script file can be problematic where there is a requirement to run unsigned scripts or code on a users machine. This is considered poor security practice and the capability could or should be disabled by default and will most likely be disabled in organisations that have application whitelisting in place. Batches or scripts may also not use strong forms of key generation such as the use of accredited random number generators etc again making them a poor choice for CSR generation. Lastly this method often does not automatically clean up after itself (i.e. it can leave the private key exposed on the file system of the computer used to generate it. This can often be a client user machine (often a mobile device) that is exposed to greater risks than say a server.
Whilst various options are available for the generation of CSRs only two options should be considered as viable:
- Generation on device as the primary means of creating a CSR;
- Generation within the Jellyfish interface as a secondary means of creating a CSR.
Generation on device provides the most secure option as it provides the most protection of the private key, it does have the drawback of requiring some technical knowledge of the application, service or device being used to generate the CSR.
Jellyfish provides a more user friendly option for the generation of CSRs although does have the drawbacks of requiring the session to remain active and the private key being in memory during the request process. This is because Jellyfish request the key be held in the browser so that the application itself never sees the private key. It is also not as safe as generation on the device because the key will have existing on more than just the consuming device or service.
We would not recommend the use of batch files or scripts as often these will clash with application whitelisting in an enterprise and because they often expose the private key to more risk through the use of non approved RNGs and by leaving the private key exposed on a file system.
WANT TO LEARN MORE ABOUT JELLYFISH?
AU: +61 2 6140 4494
NZ: +64 4909 7580
Auckland | Brisbane | Canberra
London | Melbourne | Sydney
Wellington | Washington DC