I’ve been interested in all things related to cyber security for many years. In private I’ve played around with things like Wireshark and Burp Suite, explored a few CTF’s, and taken various courses from among other sources, Pluralsight and Cybrary (I’ve even contributed some written material as a paid training assistant for the latter). I’ve also been listening to security-related podcasts on and off for years (“Risky Business” anyone?), and tried to keep up with at least the biggest headlines in the field. For whatever reason though, I’ve never really worked with security in my professional career – at least not beyond dealing with a few things like security certificates and basic authentication and authorization solutions while coding.
A few weeks ago I was given the role of “Security Champion” for the team I’m currently working on, which means I’ll have an excuse for a little extra responsibility for making sure the teams maintains a good security posture.
So what does that mean? Well, it means I get to spend some time thinking not only about how we can make our products more secure, but also about how we can be prepared in case something does go wrong. Hopefully I will get to work on everything from threat modelling and pen-testing up to planning for disaster recovery, and fiddle around with a couple of interesting tools and frameworks along the way. I’ve consumed a substantial amount of theory about security of the last few years, so it will be nice if I can actually apply some of it in my daily work.
I’m really looking forward to this, and I hope I can find the time and inspiration to write a little more about it here as I go along.
I recently wrote a post about certificate signing – specifically, about how to create and sign a certificate request so that you end up with one certificate signed by another. One thing I did not cover there, was how to include Subject Alternative Names (SAN) data in the signed certificate. To be honest, I did not realize I needed that at first, but it soon became obvious, and figuring out how to do it actually took some work.
In the end I found I had to use a different OpenSSL command for the actual signing step, and to create an extra, separate config file for the SAN data. If you’ve followed steps 1-4 in the original post, you should be fine – just replace step 5 with the following:
As briefly mentioned yesterday, the process shown would result in a signed certificate (filename.crt) for each certificate request (filename.pem), and a corresponding key-file (filename.key). If you need to use these (for instance in an Azure key vault, as was my purpose here), you might need to combine the .crt and the .key into a single file which contains both. This can be either a .pfx file or a .pem. If my understanding is correct, .pfx is really just a different file extension, typically used on Windows. Both are essentially .pem files – that is, a certificate which can contain both public and private keys in the same file. This is in contrast with the .crt files we generated, which only contain the public certificate by itself.
So how do we do combine these? Once again, let’s use OpenSSL:
You’ll be requested for a password, which will be used to secure the file while storing and transferring it. You should now have a file named certfile.pfx. Later, you’ll need to provide the password again in order to import the keys from this file into e.g. Azure, or wherever you want to use them.
Note, update: This has a follow up post for the case where you want to keep any Subject Alternativ Name (SAN) fields in the certificate to sign.
On occasion, I’ve needed to create my own self-signed SSL-certificates for various testing purposes. At work today I needed a certificate that was signed by another certificate, i.e. I needed a chain of trusted certificates for testing, where the cert at the top of the chain is used as a trusted root certificate. The premise is is simple: If you trust the root certificate, you should also trust the certificates further down in the chain, since they are signed using the trusted certificate.
I generally work on a Windows system, but for certain tasks such as this, I often find Unix-style tools preferable. Luckily, if you used the Git Bash command line for windows and have OpenSSL included, you’ll have everything you need right there. This post provides a few quick steps needed to create such a chain of trusted certificates using OpenSSL.
Update: I just realized I’d forgotten one of my favorite shortcuts: Alt + N. So what does it do? See the list below! Suffice it to say, after using it I no longer worry about getting lost in tangent code while debugging. 😉
I love a good shortcut. I love it when I can perform a task without removing my hands from their regular location on the keyboard, and without having to look down to find that one special hard-to-reach key. Now as every moderately experienced programmer knows, debugging is often an essential part of the job. In fact it can sometimes take up the clear majority of your time for extended periods. That’s why I’ve always found it so strange that the shortcuts for regular debugging actions such as step over, step into, step out of and so on have such (in my opinion at least) impractical shortcuts.
The following is a scheme of key bindings that I have been using for two or three months now, and which I find natural and easy. The effect of this change has been bigger than I had anticipated: Since I no longer need to pause to look down at the keyboard while stretching for the F11 key for example, my train of thought is slightly less prone to being interrupted. Cutting out these minimal context switches means I can focus better on the code, which means I work faster and spend less mental energy keeping track of where I am, and what is going on — and there’s your improved debugging workflow.
(*) shift + F11 is a common shortcut for “step into”.
These are the main shortcuts I’ve added. Some are inspired by the use of Vim (J moves the cursor to the next line in Vim – her it steps to the next line of code), while others are based on mnemonics (G for “Go” to either start or continue debugging, S for “Stop“), etc.