I will try to keep this short and to the point.

If you work in a Windows/Linux mixed environment, you may come across a scenario where you need to move SSL certificates and private keys from a Windows server using IIS to Linux running Apache or similar.

Windows and Linux tend to use two different key formats and this can make things tricky. Today I want to briefly write down/share the commands you can run using the OpenSSL framework to convert a Windows PFX formatted exported certificate into something Apache can use. (more…)

In this article, let us review how to generate private key file (server.key), certificate signing request file (server.csr) and webserver certificate file (server.crt) that can be used on Apache server with mod_ssl.

Source: How To Generate SSL Key, CSR and Self Signed Certificate For Apache


The above linked article is an excellent overview that is right to the point for generating SSL keys on a linux server. The instructions include generating a CSR (certificate signing request) that can be sent to a third-party cert authority to get yourself a full-fledged certificate file in addition to instructions on generating a self-signed certificate (often used for testing but handy for a myriad of other things…)


I would also recommend you take a look at this link if you need to generate a key without a passphrase: http://serverfault.com/questions/366372/is-it-possible-to-generate-rsa-key-without-pass-phrase


Read about it more in detail here on Redhat’s site. This vulnerability affects all applications using certain versions of OpenSSL, so this is a cross-platform issue.

This isn’t nearly as atrocious as Heartbleed was as there isn’t a chance of leaking your private keys. However, if you use Qualsys labs excellent SSL web scanner to check your site’s security, this will immediately degrade your web application to an “F”.

Scrutiny of SSL has been ramped up significantly in the wake of Heartbleed, so if your application deals with any kind of regulated data I suggest you patch your servers immediately.

For Ubuntu users, this means it is time to do an OS upgrade to 14.04 LTS if you aren’t running a previous LTS version that is still receiving security updates…

do-release-upgrade your way to a safer tomorrow…

I have tagged this post with “heartbleed” as folks researching that issue need to pay attention to this one as well. The fix is the same; patch OpenSSL!



Free penetration testing tools abound. Free, easy-to-use penetration testing tools… not as much. Free, easy-to-use, web-hosted penetration testing tools, rarer still.

I came across an excellent, web-hosted NMAP port scanning tool and I wanted to make sure I linked it here in case I needed it again in the future. Without further ado…


I haven’t explored the rest of the site, but the ability to quickly hit a public site and “fingerprint” the most common open ports is very very handy. I hope others find this as useful as I have! What is nice about it, is that because it is web-hosted, it requires zero setup on your own machine and quickly running scans is simple as everything is GUI’d.

I have found zenmap useful if you are looking for something locally hosted to do internal scans between machines. It isn’t quite as easy to use and I have gotten some odd results from it but it provides more flexibility, especially on windows, vs. just going to the cmd shell and running the common “ping” and “telnet” commands.

While we are on the topic of excellent, free, web-hosted tools. SSL Labs has an absolutely phenomenal SSL testing suite for checking your sites SSL security. In the wake of heartbleed, there has been a lot of attention given to SSL security. If you are a company that runs a public site or sites with SSL, I recommend you start checking them now to make sure that they are configured as well as can be.

You can access that tool here:


I have already discussed Heartbleed in detail and have provided instructions on how to close the hole on affected server. Now that the hole is closed the final step is changing your server’s private key and “re-keying” your SSL certificates. Re-keying simply involves creating a new certificate signing request and sending it to your (most likely) external certification signing authority. Once received, they should send you an updated key pair. The last step will be telling your application that uses SSL (in this case, and many others Apache) to use the new keys. Lets dive in!