Digital Certificates

Public Key Infrastructure:

Public key solves the problem of having to share keys between one another to communicate securely. Instead, each user will generate a public and a corresponding private key.

If a user, Alice, wants to send another user, Bob a secure message, as long as Alice knows Bob's public key, this will allow Alice to send an encrypted message which then Bob will use his private key to decrypt.

The problem with this is that how do you know it's bob's public key, or even bob that you're communicating with?

This problem is solved by Digital Certificates, due to that fact that you will be verified by a Certificate Authority. So if Alice wants to speak to bob encrypted, Alice can get the CA to verify that Bob is who he says he is, and get his public key to allow communication.

On a slight aside:

- Web of trust is a decentralised CA as opposed to a normal CA which is centralised. This works by peer-to-peer authorisation.

X.509 is the standard for Digital Certificates, it lays out the format of what is required in them.

General Structure:

Version - Of X.509 (there are three versions)

Serial number (Unique Positive integer assigned by the CA to each Cert)

Algorithm ID (Will be the same as the Certificate Signature Algorithm)

Issuer

Validity Not before Not after

Subject

Subject public key information

The issuer and subject each have a distinguised name (DN) which is unique for each CA. DN consists of a single line with comma seperated values: CN = Common name L = Locality name ST = State or Provinance name O = Organization name OU = Organizational Unit name C = Country name

Example:

C=MB, ST=Belfast, L=Belfast, O=Matthew Boyd Inc, OU=Computing, CN=testing.com/emailAddress=test@test.org

A Digital Certificate is like an ID card, it identifies someone on the network.

Not all the fields may be required.

When a browsers is connecting to an HTTPS server (Website with SSL) It will check the CN and make sure that it matches up. You can use wildcards in the CN to allow for sub-domains.

Public key information will include the following: alorithm used: rsa key size: 2048 exponent: 0x10001 modulus: 00:ec:82...

In Version 2, the issuer and subject unique identifier allows for the reuse of names, i.e. if a CA goes bankrupt, after some time, you can reuse the same name as it.

Version 3 of X.509 incuded extensions: These can make a certificate critical or not. If a cert is critical it must be compliant and enforced otherwise it is ignored.

Extensions include:

Subject Key identifier

Authority Key Identifier

Subject Alternative Name - May have additional IPs and DNSs that are validate apart from the one in the CN.

Basic Constraints - could have info on whether the subject is a CA. Subject and Authority key identifier: This is used when there are multiple entities used to sign keys. This allows for the identity to be verified. It is a 160-bit SHA-1 hash of the public key



Certificates contain:

public key

identity of the owner

Certificate Authority can give out a certificate and VALIDATE it.

Before any certificates have been issues: A user must:

* generate their private and public keys themselves. * They need to provide user identification information

Then they will make a request to the Certificate Authority (CA):

They will validate you, through phone calls, or visits, etc.

They will provide you the certificate and this will show personal user information, and public keys.

CSR = Certificate Signing request

This is whereby you have the public keys and the user information and you want to get a digital certificate from the CA.

command:

openssl req -newkey rsa :2048 -nodes -keyout domain .key -out domain .csr

This command will give you a private key: domain.key and it will also give you the certificate signing request: domain.csr

OpenSSL commands:

Generally deals with "-in" and "-out" parameters

To inspect, you'll use "-in" and "-noout". "-text" can be used to see all contents

Generating an RSA key for the CA:

openssl genrsa -out matthew .software .key 2048

The .key will be the private key.

Inspect the key:

openssl rsa -in matthew .software .key -noout -text

Getting the public key from the private key:

openssl rsa -in matthew .software .key -pubout -out matthew .software .pubkey

Inspect the public key:

openssl rsa -pubin -in matthew .software .pubkey -noout -text

Generating a CSR (Certificate Signing Request):

openssl req -new -key matthew .software .key -out matthew .software .csr

Inspecting the CSR:

openssl req -in matthew .software .csr -noout -text

You can put a conf file in to create your CSR:

openssl req -new -out matthew .software .csr -config matthew .software .conf

Because there is no key specified, it will create one.

THINK YOU CAN DO THIS:

openssl req -new -in matthew .software .key -out matthew .software .csr -conf matthew .software .conf

They need a public key too:

openssl genrsa -out CA. key 2048

Create a self-signed certificate:

openssl req -new -x509 key CA. key -out CA.crt

Signing certificate:

openssl x509 -req -in matthew .software .csr -CA CA .crt -CAkey CA .key -CAcreateserial -out matthew .software .crt

inspecting the self-signed certificate that was created:

openssl x509 -in matthew .software .crt -noout -text

Browser will complain that this is not trusted, so you will have to:

cat matthew .software .crt CA .crt > matthew .software .bundle .crt

The CRT will also need added to the Authoritises section of the browser

Verify a Cert is okay: