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 readingAuthor: kjartan
Security Champion
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.
We’ll see how it goes…
Cheers!
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 reading