Follow

Creating a Certificate Signing Request (CSR) when setting up RedShield

This article describes a suggested method for creating a "Certificate Signing Request" or "CSR", which is required when obtaining a TLS certificate from a certificate provider. 

A certificate signing request (CSR) is a file that contains information about your organization and domain name, as well as a public key. The CSR is used to apply for an SSL/TLS certificate, which is used to encrypt web traffic. 

A CSR is not required for applications which use Let's Encrypt - RedShield will generate keys and certificates automatically when this option is selected. 

 

Note: this process will create a private key, which must be stored securely to prevent unauthorised access to your application. Never send your private key to any party by email, or in a support ticket. When sending certificates and keys to RedShield, please use the secure uploading process in the RedShield portal, or ask RedShield support engineers for assistance.

 

Here is a step-by-step guide for generating a CSR on Windows and Linux workstations:

 

Windows:

  1. Open the Windows Start menu and search for "Internet Information Services (IIS) Manager."
  2. In the IIS Manager, click on the server name in the left-hand pane.
  3. In the center pane, under the "IIS" section, click on "Server Certificates."
  4. In the right-hand pane, click on "Create a new certificate request."
  5. In the "Distinguished Name Properties" window, enter the required information, such as the Common Name (i.e., the domain name you want to secure) and the organization name.
  6. In the "Cryptographic Service Provider Properties" window, select the appropriate options, such as the key length and encryption algorithm.
  7. Click "Finish" to save the CSR file to the specified location.

Notes:

Cryptographic Service Provider

You may be required to select either Microsoft RSA SChannel Cryptographic Provider, or Microsoft DH SChannel Cryptographic Provider.

RSA SChannel, which uses the RSA algorithm as the key exchange mechanism, is widely used in digital signatures and secure communications. RSA is considered to be a strong algorithm and has been widely adopted in the industry.

On the other hand, DH SChannel, which uses the Diffie-Hellman (DH) key exchange algorithm, is considered to provide an additional layer of security by providing perfect forward secrecy (PFS). PFS ensures that even if the server's private key is compromised, previous sessions cannot be decrypted.

In general, when choosing between RSA SChannel and DH SChannel, it is recommended to use RSA SChannel if PFS is not a concern and DH SChannel if PFS is a requirement.

Many organizations that handle sensitive data like financial institutions, e-commerce and other businesses that handle sensitive information usually opt for DH SChannel to provide the added security of PFS.

It is also worth noting that many CAs and certificate management platforms now offer certificates that support both RSA and DH/ECDH key exchange mechanisms. This allows the server administrator to choose which key exchange mechanism to use for a given connection.

It is also worth noting that DH SChannel may have some performance impact as it can be slower than RSA SChannel, but the difference may not be significant unless the application is highly sensitive to latency during the TLS handshake.

Bit length

RedShield suggests that for the DH SChannel provider, a bit length of 1024 is used. For RSA, a bit length of 2048 is considered sufficient. 

 
 

Linux:

  1. Open a terminal window and run one of the following commands (replace example.com with the domain name you want to secure).

    For RSA:
    openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr
    For ECDHE:
    openssl ecparam -name secp384r1 -genkey -noout -out example.com.key
    openssl req -new -sha256 -key example.com.key -out example.com.csr

     

  2. Fill in the distinguished name fields as prompted. The Common Name (i.e., the domain name you want to secure) is the most important field to fill in correctly.
  3. The CSR file, example.com.csr, and the private key file, example.com.key will be created in the current directory.

Notes: You can use -newkey to specify the RSA key length, if you wish to use a different length than 2048, however 2048 is RedShield's currently recommended standard. For ECDHE, RedShield suggests using secp384r1. Also, you should keep the private key safe and private as it will be required when installing the certificate.

After generating the CSR, you can then submit it to a certificate authority (CA) to apply for an SSL/TLS certificate. The CA will use the information in the CSR to verify your identity and the ownership of the domain, and then issue a certificate if everything checks out.

You can also use the resulting private key and CSR file to request a cert for other platform like AWS, Google Cloud, Azure etc

 

Further suggested references:

https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices 

 

 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments