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.
So I finally got around to setting up headers for a 301 redirect HSTS for my site. What does that mean? It means that hopefully some time soon, chronology.no will be added to Chrome’s HTTP Strict Transport Security (HSTS) preload list, i.e. it will be hardcoded into Chrome as being an HTTPS only site.
In simpler terms: From now on, you’ll only be able to access any resources under the domain chronology.no using https, i.e. with encryption and authentication.
Great! Now all I need is a little more content on my site!
I came across this announcement today. Apparently Master Card is applying biometrics in an attempt to make online shopping faster and safer. My impression of the current state of biometrics is that it is not great. Some technology may be considered reliable (a relative term in any case), but it is generally expensive, and typically consists of invasive things like retina scanning, which requires a person to physically lean close or right up to a specialized piece of equipment. General consumer technology like the fingerprint scanners on phones and the like are easily fooled, and may give a false sense of security.
The motivation behind this is to make security less of a hassle for customers, to keep them from abandoning purchases at the final step. I think this is an interesting and admirable effort, and the solutions seem pretty cool. A number of questions come to mind though: