I did some work related to certificates exactly one year ago. Today I had to repeat some of what I did in order to generate a new cert, and I’d forgotten some of the details in the process. I wrote a little about it here last year, but clearly I’d left out one step: How to generate a signing request which you can then submit to a third party for signing. Luckily I was able to recall the details after messing around with the files from last year. The following is a simple guide to save more time next time.
Continue readingDevelopment
How to sign certificates while retaining SAN fields
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:
Continue readingConvert a .crt certificate with a separate private key to a combined .pfx
This is just a quick follow-up to yesterdays post concerning certificate signing.
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:
openssl pkcs12 -export -out certfile.pfx -inkey keyfile.key -in certificate.crtYou’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.
Create a chain of self signed certificates
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.
Continue readingA customized shortcuts scheme for an improved debugging workflow in Visual Studio
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”.
Shortcuts
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.
