Considering online generation of certificate requests

Recently I’ve been researching what other Certificate Authorities do within the domain of online generation of certificate requests (and related private keys).

It is tricky territory: JavaScript and Crypto. Or more generic, webapplications and crypto. But with the advance of the WebCryptoAPI some issues that were raised (e.g. insufficient random number generation) by security experts have been addressed, but still: the WebCryptoAPI entry on MDN starts with a fair warning: “If you’re not sure you know what you are doing, you probably shouldn’t be using this API.”

Why think about a web implementation at all to create a certificate request? Typically tools to generate certificates are hard to use. Just look at the list of options a user has to generate certificates, which are typically all offered as options as companies hope there is a match with the client’s configuration. The complexity leads to such heights that users may jump through insecure loops, such as asking others to generate the request, send private keys by e-mail, downloading untrusted software to generate keys and requests, outsourcing it to a ‘respectable’ middle man, e.g. CloudFlare’s Universal SSL, and hence not owning the private key at all, and more.

Hence, it makes some sense to create an accessible tool, that requires no install, that runs inside the browser. Previously security researchers would have said this is impossible, but some big names are currently offering tools to generate private keys and certificates within the browser.

Why use the typical openssl commands on the server?

The golden standard is running the openssl (or similar) command on the computer that will be using the certificate as proof of identity. The reason is simple: the private key is never moved, and when done correctly, directly stored in a secure folder. Not even the owner of the server ever has to open or move the private key’s content. But it requires knowledge about the terminal. And you need lower level access to the computer you want to secure. Sometimes you even need to install a tool you’re not familiar with.

Cloudflare’s WebCrypto solution

To improve on the security of CloudFlare’s Universal SSL solution, they created an internal CA, OriginCA. This enables encrypted communication between CloudFlare and the server. It still imposes the CloudFlare middleman, but sometimes a solution like CloudFlare is the only way to get low latency results anywhere in the world. To generate a Certificate Request (CSR) Cloudflare uses WebCrypto + PKI.js. This generates a standard Certificate Request.

Since this solution is meant to only encrypt between Cloudflare and the origin server, the attack vector is significantly lower than regular web-certificates; no other party than Cloudflare and you will directly communicate with the server.

NameCheap’s CSR Generator

NameCheap has its own webbased CSR generator, which generates a private key, a certificate request all within the browser. It stores nothing. It’s all within the same single page app. This removes some responsibility for NameCheap, as they do not have to worry about storing the private key securely. On the other hand, the user might still do less wise things with the private key generated with this tool, as it is presented as something they can copy paste. When you look at their support page on how to generate a CSR, it is simply listed among a list of many other CSR generation options. They don’t promote it as the best option available. It’s an option you have. It maybe the best middle ground, to reduce service desk calls, while still adhering to the gold standard of generating private keys at the computer, directly where they can be put to use when the certificate is issued.

There is no information about technologies they use, but WebCrypto is assumed. Since they do not repackage, the WebCrypto API is mostly sufficient.

CertSimple

CertSimple promotes the WebCrypto solution. It puts it front and center. There is a small link to get pregenerated openssl and the Microsoft PowerShell’s equivalent commands, which has its benefits.

You are prompted to immediately store the private key, as it is lost in the follow up process. When you reload you have to start all over again.

Against downloading a private key

• A user may be tempted to leave the private key in the Download folder, which may not have the same level of authorization limitations as a folder meant for secure items.
• In none of the options the private key was encrypted by default. The webservers typically don’t require encryption either, but then, the private key is directly stored, typically never opened by anything other than the webserver itself.

Risks with generating private keys inside browers

The biggest risk when implementing WebCrypto is that someone else might inject Javascript onto your page. This JavaScript may then read and transmit the private keys to somewhere else. There are plenty of attack vectors:

• Package management solutions, it is easy to overlook a small package (a dependency of a dependency) that got infected with some unwanted code.
• Cross Site Scripting (XSS), injecting code within the site
• Content spoofing (one thinks it is your site they’re generating the request at)
• Browser security issues
• …

There are plenty of techniques to mitigate these (preventing access to other domains, keeping Javascript complexity low and using checksums to pin external resources, require user to login), but a single weakness is sometimes all that is required to break trough security.

Additionally there might be a trust issue with your customers, it is hard for them to know for sure that you are not using the CSR and/or have sufficient protections, hence always offer them an option to upload their own CSR.

Conclusion

Security is hard. The right solution is an act of balance between user friendliness, understanding of user behaviour (esp when user friendliness declines), attack vectors, requirements and security.

Photo by Jose Fontano on Unsplash