The Most Profitable Industry In The World, Just Became A Little Less Profitable ..

The Most Profitable Industry In The World, Just Became A Little Less Profitable .. and Another Nail in the RSA Coffin

Do you really understand how digital certificates work? If not, be worried, as PKI (Public Key Infrastructure) is at the core of security on the Internet. But what is a digital certificate, and why is it so important? Well there’s a public version (that anyone can have) and a private version (that no-one should be able to get). The private one has a key pair — with a unique public and a associated private key— and the public one just has the public key. The magic is that these certificates is that they are signed by a trusted entity. And so if Bob and Alice trust Trent, then Trent can sign a certificate to say that he has proven Bob’s identity to Alice, and vice-versa.

So how can you make $50 for less than a minute’s work? Well, you issue digital certificates. Basically you get someone to send you some ID, and you quickly check that and issue them with a digital certificate. Basically all you have to do is to protect your main encryption key that you will sign the digital certificate with, and then generate an encryption key pair (a public and a private key — normally these are 2,048-bit RSA keys). If this is not profitable enough, you tell them that it will only be valid for a year, and get them back next year for an even faster verification.

The industry is going to be a whole lot less profitable with the news that Let’s Encrypt — who offer free digital certificates — will now be trusted by all the major root certificates, include Microsoft, Google, Apple, Mozilla, Oracle, and Blackberry. Up to now Let’s Encrypt have had to rely on IdenTrust for its trust — using a cross-signature bridge — but can now issue its own trusted signatures. The “piggy-backing” onto another systems chain-of-trust is never a good thing, as a breach for the main trust provider will cause all of the related certificates to be untrusted.

Let’s Encrypt aims to provide free TLS certificates and allow HTTPS on websites without the complexity of existing methods. It is run by the California-based Internet Security Research Group (ISRG). It is backed by a range of organisations, including Cisco, EFF and Facebook. Their certificates now support over 124 millions domains, and in a recent five day period they created over 6 million domains.

Their certificates will be trusted by most of the major browsers, including Chrome and Firefox. It is also open-source and can be downloaded from Github and is run by:

cd ~/src
git clone https://github.com/letsencrypt/letsencrypt.git
cd letsencrypt
./letsencrypt-auto --apache -d mydomainname

After this it will ask for a few other things, such as your email address, and that’s it. The certificates it creates are A graded with 2,048-bit RSA and a SHA-256-bit hash. The new core Let’s Encrypt certificate is ISRG Root X1, and which will be used to sign for Authority X3 certificates (which is an intermediate signer) and thus for new certificates:

At present ISRG keys use RSA keys, but as the industry turns away from RSA, Let’s Encrypt will be using ECDSA keys in the future. With RSA being dumped from TLS 1.3, it looks like RSA keys will become a thing of the past, as elliptic curve methods take over.

Here’s a bit of an overview on digital certificates:

So how are digital certificates used?

The world is moving to HTTPs by default, and sites which just use HTTP will be marked as insecure. Basically we want to setup an encryption tunnel which defines the key exchange method we will use, the actual encryption key, and a hashing method to check of integrity.

In the following, for the negotiation of the key to use for the secure tunnel, the client and the server have bound an encryption contract of 128-bit AES, and using HMAC-SHA1 for signing and verifying entities. It uses RSA as the key exchange method, and where the 128-bit AES is generated by the client and send back in an encrypted form using the server’s public key.

First I’m going to explain what you pay money for. Initially the root CA creates their own keypair and then creates a self-signed certificate. This is the trusted root certificate. The organisation will then generate a keypair (or have a key pair created for them). After this we create a CSR (Certificate Signing Request) for the CA. Next the CA takes the CSR and then checks the details, and signs it with its own private key:

Installing a certificate on server

First we create a private key that we are going to use for our side (myKey.key) and create a csr file (CSR.csr) which can be given to the certificate provider:

openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout myKey.key

A Certificate Signing Request (CSR) file contains encrypted text that is generated that was generated on the server that will be authenticated. It contains a range of information including organization name, common name (domain name), locality, email contact, and country.

We keep the private key secret, and then give the CSR.csr file to the provider, normally by pasting in the text file (from the CSR file):

-----BEGIN CERTIFICATE REQUEST-----

MIIDBzCCAe8CAQAwgacxCzAJBgNVBAYTAlVLMRAwDgYDVQQIEwdMb3Ro

EAYDVQQHEwlFZGluYnVyZ2gxGjAYBgNVBAoTEUFzZWN1cml0eXNpdGUuY

EAYDVQQLEwlDb21wdXRpbmcxGjAYBgNVBAMTEUFzZWN1cml0eXNpdGUu

...

suS9dJmNv9d1LLCJ0cZjg2HhPfvJ41kBtzzK8ssl2mSL49dJJQujXnQCrj02oCJk

eSLIH+qYGzUnVbE=

-----END CERTIFICATE REQUEST-----

This gives the required information on the name of the site, and so on, to the certificate provider. They will then send back a CRT file (server.crt) and intermediate signing entities (gd-g2_iis_intermediates.p7b), and which the public key on it, and intermediate trust providers. We can then produce a certificate with both the public and the private keys on it by adding the private key:

openssl pkcs12 -export -out certificate.pfx -inkey mykey.key -in server.crt -certfile gd-g2_iis_intermediates.p7b

Finally we take certificate.pfx and can convert it into a CRT format (CRT is a digital certificate format) which the server can read:

openssl pkcs12 -in certificate.pfx -clcerts -out certificate.crt

You should be able to see from the screenshot below that we have the private key added on the certificate.

To add this to the server should then be fairly easy.

Conclusions

With governments around the world worrying over secure communications, the introduction of a new open-source version of issuing certificates will worry them even more. We have been doing some research on the usage of certificates: