Note: This guide is based on my experiences requesting an ECDSA certificate from a single CA. Not all CAs offer ECDSA certificates yet, so you may need to shop around to find one that does.

As computing power and prime number factoring speed increases, keys based on RSA become more vulnerable to cracking. To combat this, RSA key lengths have been growing over time. Currently, the minimum accepted size of an RSA key for web site use is 2048 bits. As key length increases, so does the computational workload on the server to support each incoming TLS connection.

In contrast, as of the time of this writing, no cryptographic weaknesses have been found in ECC (Elliptic Curve Cryptography) implementations, which means an ECDSA key of just 256 bits is considered as strong as a 3072 bit RSA key, and a 384 bit ECDSA key is equivalent to 7680 bit RSA. So using an ECDSA certificate means higher security with less server CPU overhead and lower power consumption per connection, and thus more total concurrent client connections supported.

In order to issue you a trusted public key certificate, your chosen Certificate Authority (CA) will need a signed certificate request, generated on the server where the certificate will be installed. Most CAs will guide Windows website customers to generate their CSR using the IIS GUI. But in IIS 8.5 and below, the Create Certificate Request wizard does not allow specifying the parameters required for an ECDSA CSR, only RSA and DH. Hopefully the ability to request an ECDSA CSR will be added in the future (perhaps with Windows 10 Server next year).

In the meantime, in order to request an ECDSA certificate under Windows you'll need to dust off your command prompt skills and use certreq.exe tool.

Step 1: Build the certreq input file (e.g. certreq_input.txt).

Here is an anonymized version of the parameters I used. For a complete list of the available parameters for certreq.exe, consult the Microsoft certreq documentation page.

[NewRequest]
Subject="CN=www.mysite.com,OU=my_org_unit,O=my_org,L=my_city,S=my_state,C=US"
Exportable=TRUE
HashAlgorithm="SHA256"
ProviderName="Microsoft Software Key Storage Provider"
KeyAlgorithm="ECDSA_P384"
KeyLength=384
KeyUsage=0xf0
MachineKeySet=TRUE

Step 2: Run the input file through certreq.exe to generate a CSR output file. Open an administrator-level command prompt, and run a command like the following:

certreq.exe -new certreq_input.txt my_csr.txt

Step 3: Submit your CSR to the CA. Typically you’ll end up pasting the contents of the my_csr.txt file into a box on the CA’s web site.

Step 4: Download the generated certificate. For Windows, the easiest format to work with would be a P7B file containing the certificate and all intermediates. For example purposes, we’ll save it as mysite_ECDSA_P384.cer

Step 5: Load the certificate on the server. At an administrator-level command prompt, run a command like the following:

certreq –accept mysite_ECDSA_P384.cer

Step 6: In IIS, bind the new certificate to https on port 443.

To test the security and compatibility of your site, I recommend using the Qualys SSL Labs SSL Server Test.

I decided to post about security first, because many people likely consider security last when they are evaluating a CMS. Other CMS projects offer features like "one click" upgrades, or executable plug-in installers. People often don't realize that along with the convenience that features like these offer comes a high level of risk. Because if an administrator of a site can upload and execute code through the web server itself, then an attacker wielding an exploit can do the same.

So rather than allowing this convenience, mojoPortal requires that you either use the Web Platform Installer, or upload the CMS or add-on module through a separate means, such as FTP. After the files are uploaded, you navigate to the Setup page to install it into your site. Along with this, mojoPortal advocates that you specifically deny the web server the ability to write to any folders but App_Data and Data, where site skin and other media files sit. On top of that, you should even prevent files from being executed in these data folders. This way, if an exploit occurrs, the attacker will not be able to modify the CMS code itself in order to cause harm or install backdoors into your site.

Based on this core security philosophy of mojoPortal, the hypothetical CMS shopper might think:

But I trust CMS X's team of programmers. I know they'll keep the attackers out, and I have strong passwords, so I don't have to worry about it. mojoPortal is too hard to customize and upgrade. Bring on the convenience!

Well, I hate to be the one to break it to you, but the coders of the CMS are not necessarily going to be the ones responsible for your site getting "pwned." In fact, a mistake on their part might not even be the most likely route to a site compromise. Maybe your password falls into the wrong hands. Maybe the attackers figure out a way to exploit your web server and make it overwrite or delete executable files for your site. Whichever way they do it, the underlying attack method ultimately relies on the ability of the web server to write to disk locations containing the site's executable files.

For more reading about this topic, check out the Installing mojoPortal documentation at mojoportal.com