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

If I were in your shoes, and I were reading this, my very first question would be:

What is this, the trillionth blog on the Internet? Who the heck are you, and why should I read these rants and ramblings?

Allow me to elucidate, dear reader. My name is Jamie Eubanks, and I have 30 years (and counting) of IT experience developing software, working with PCs and servers, networking, databases, web servers and content management systems, analyzing customer needs, providing support, training... The list goes on.

But that only covers my career. Outside of work I also have a great interest in technology in general: Photography, audio/video, home theater, mobile phones and tablets, and all kinds of gadgets. I'm fascinated by cosmology, astronomy, biology, astrobiology, planetary exploration, and science in general. I guess you might sum me up by saying

5,000 years ago, this guy would have been a completely useless sack of skin!

Touche. I guess I should let you know too that I have a great interest in the outdoors. I was raised with a deep appreciation of the natural world, and I love to camp and hike. My ideal vacation would be to explore a national park, or snorkel on a tucked away reef in the tropics. I like to think that I am well rounded. A renaissance man, if you will.

Hey, this isn't a dating profile, buddy, and you still haven't answered why I should read this.

Very true, so let me get to the point. I have life experience. My brain is stuffed, perhaps overstuffed with capital-S Stuff. Stuff that may be of interest to others. Stuff that you might find useful, or helpful, or perhaps even essential to your very being, if you stumble across it. To me, it's always seemed that blogging was an exercise in boasting and self aggrandizement. A way to cry out for attention and external validation. But I've finally realized that it doesn't have to be about that. I can write blog posts without self-promotion; without egotism; without link baiting and SEO and all the other things that turned me off to blogging and kept me from running my own web site, even though I've been on the Internet since 1986. Oh yeah, I was on the 'net long before the World Wide Web was even a gleam in Mark Andreasen's eye.

So that's my proposition. I write stuff, and you read it (or not). Knowledge is power, yadda yadda yadda. So if you happen to find something helpful and/or interesting here, then by all means, keep it to yourself.