Since during the CSR code submission, we are giving away a certain amount of valuable information to a Certificate Authority (like domain name, public key, etc.), we would surely want this information delivered without changes, and that our future SSL certificate would have a valid public key.
The size of a cryptographic key defines its strength against various attacks. Not to dive into mathematical basis of public key cryptography too deeply, the simple logic is - the bigger the key, the harder it is to crack. On the other hand, the keys of enormous sizes will consume more computational power during cryptographic operations and can slow down a server’s performance considerably.
Hence, the list of supported key sizes in CSR codes is the following:
Note: The current supported key algorithms on our site are only RSA and ECDSA.
A digital signature helps to ensure the integrity and authenticity of a transmitted message (the CSR code in our case). A signature algorithm is used to sign a piece of data and to calculate its hash with a certain hash function. Then the message is sent along with the hash and the name of the signature algorithm so that the recipient can calculate and compare the hash to make sure that the message was not altered during transmission. The signature algorithm must be robust enough to be resistant against possible data forgery attempts.
Currently, the list of supported signature algorithms is the following:
To avoid possible issues with the SSL certificate activation, the CSR code must comply with the above-mentioned criteria.
How to generate the CSR correctly
Most modern OpenSSL implementations use supported key sizes and signature algorithms during the private key and CSR generation by default. However, if we want to make sure that everything is done properly or to use a specific key size and signature algorithm, we can add the corresponding parameters to the OpenSSL command.
If the CSR and private key are generated with one command:
openssl req -new -newkey rsa:[bits] -nodes -keyout server.key -out server.csr -[digest]
If we generate the private key and the CSR separately:
openssl genrsa -out server.key [bits]
openssl req -new -key server.key -out server.csr -[digest]
[bits] is to be replaced with the needed key size in the range between 2048 and 8192.
[digest] should be replaced with the name of the supported hash function - md5, sha1, sha224, sha256, sha384 or sha512 (e.g., -sha384).
ECDSA keys are generated with a certain curve type, which is specified in the OpenSSL command as follows:
openssl ecparam -out server.key -name [curve]
[curve] here should be replaced with the name of the curve in the format, that can be recognized by OpenSSL:
Just like with OpenSSL, standard keys and signature algorithms in modern Windows Server versions are compatible with the above-listed requirements. However, if we need to tweak these attributes, there is a way to do that.
We will need to open the Create Custom Request wizard from within the MMC (Microsoft Management Console) interface. The full sequence of steps is the following:
Win+R >> mmc.exe >> OK >> File >> Add/Remove Snap-in >> Certificates >> Add >> Computer account >> Next >> Local computer >> Finish >> OK >> Certificates >> Personal >> right-click on empty space >> All Tasks >> Advanced Operations >> Create Custom Request.
More information about creating custom CSR codes on Windows can be found here.
After opening the certificate enrollment’s properties there will be the Private key tab with the sections called Key options and Select Hash Algorithm, where we can select the required key size and hashing algorithm respectively.