security

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 reading

Convert 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.crt

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.

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

HSTS preload list: Pending Submission

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!

PS: You can check if the submission has been accepted here.

MasterCard’s new biometric security

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.

So what is Master Card using? Well according to articles from biometricupdate.com and mobileworldlive, they’re experimenting with fingerprint scans and short video shots of faces (facial recognition) as replacements for passwords when authenticating payments. CNN Money has this video demonstrating the facial recognition solution.

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:

Continue reading