CNS - 25 - Asymmetric Cryptography IV

The high level structure of this format is shown below

As we can see, there are \(5\) main sections, which are discussed below:

• Version and other data

• CA identity

• User identity

• User public key

• CA digital signature

Here is reported a real certificate taken from wikipedia

A wildcard certificate is a public key certificate which can be used with multiple (all possible) sub-domains of a particular domain.

Such certificate has a * simbol in the CN field.

When a CA emits a X.509 certificate following a valid CSR, it can add to the certificate various extensions.

Certificate extensions provide a way of adding information such as alternative subject names and usage restrictions to certificates. Some well known extensions are the following.

• Authority Key Identifier: provides a means of identifying the public key corresponding to the private key used to sign a certificate.

• Subject Key Identifier: provides a means of identfying certificates that contain a particular public key.

• Key Usage: defines the purpose (encipherment, signature, certificate signing) of the key contained in the certificate.

• Subject Alternative Name:

• Extended Key Usage:

• Basic Contraint Extension: describes whether the certificate is a CA certificate or an end entity certification.

For the complete list check the standard.

How do we verify a certification authority? This is done by creating a hierarchy of certification authorities, where each CA is certified by another CA at a layer above. The CAs which stand on the top of this hierarhcy are called root CAs and they are certified by the so-called root certificates.

The main different bewteen a root CAs and a non-root CAs is that, by definition, a root CA is a certification authority that necessarily certifies its own identity.

Root certificates are thus self-signed certificates. These certificates have the following properties:

• The subject is the same as the issuer

• The private key with which the certificate is signed is the one associated with the public key inserted in the certificate. That is, the authority key identifier is the same as the subject key identifier.

Once again the problem shifts: how can we now trust a root certificate? Root certificates have to be securely distributed and stored. They are built-in in the OS and cannot be added/removed by unprivileged users.

In many real world application scenarios the end user certificate is not issued by a root certificate. There are many reasons for this, but we can just say that it is done for the sake of scalability.

The idea is that we can have one (or more) intermediate certification authorities which are involved in the end user certification process.

Root CAs and intermediate CAs are not necesarily administrated by the same entity.

To allow this behavior certificate chains are used. A certificate chain is a list of certificates followed by one or emroe CA certificates with the following properties:

• The issuer of the each certificate (expect the last one) matches the subject of the next certificate in the list.

• Each certificate is supposed to be signed by the secret key corresponding to the next certificate in the chain.

• The last certificate in the list is a root certificate.

The usage of certificate chain simplifies the key management and certificate monitoring by "grouping" CAs into a tree-like structure. When your browser connect to a site and sets up a TLS connection you thus not only check the server's certificate, but rather the entire chain of certificates.

A pki must include mechanisms for handling compromised certificates, such as when the private key associated to the public key has been disclosed, or lost, or simply not used anymore.

The two major approaches used for this are:

• Validity period for a certificate

• Explicit revocation

Prepare our CA folder and the serial number file

mkdir CA
cd /CA
echo -e "01\n" > serial

Create the CA key pair

openssl genrsa -out root.key

When we run this command openssl generates a public/private key pair and encodes them in base64. To actually read them you can do the following

openssl rsa -in root.key -text

Observation 1: When using RSA typically the public key is the number \(65537\). Using this and some other numbers does not weaken the security at all of the system.

Observation 2: Openssl uses the CRT-RSA variant, as defined in the standard PKCS1. This variant uses the Chinese Remainder Theorem to speed up the computation.

To generate the root certificate, which will be self-signed with the key we have just created, we can do the following.

openssl req -new -x509 -days 1460 -key root.key -out root.crt

Note that in this case we need both the public key as well as the private one, since we are self-signing the certificate. Both of these keys are contained in root.key.

When we execute this code the program will asks us for:

• The Country name

• The State (or province name)

• The Locality name

• The Organization name

• The Organizational Unit name

• The Common Name

• The Email address

When it ends it will have generated the root certificate in the file root.crt. Once again if we want to read the decoded version of the certificate we can execute

openssl x509 -in root.crt -text

Openssl automatically applies the root CA profile to all self-signed certificates.

For the intermediate and user certificates we need to explicitly specify a certificate profile. Profiles are (usually) specified in the openssl configuration file. In ubuntu distros this is in /etc/ssl/openssl.cnf.

We are now acting as the intermediate authority.

To generate a public/private key pair we do as we did before

openssl genrsa -out intermediate.key

Then instead of creating a self-signed certificate we will create a CSR, which will later be signed be signed by the CA private key

openssl req -new -key intermediate.key -out intermediate.csr

When we execute this commands a series of information will be asked like before. We might also get asked for a challenge password. This password is asked to you by the CA when you want to revoke a certificate. In pratice however this is never used.

To read our CSR we can do

openssl req -in intermediate.csr -text

The intermediate then sends this to the CA to transform the CSR into an actual X.509 certificate. To do this in pratice however we first have to add the following profile extension in the config file /etc/ssl/openssl.cnf.

[ v3_intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

The signing then is done as follows

openssl x509 -req -in intermediate.csr -out intermediate.crt -CA root.crt -CAkey root.key -Caserial serial -days 365 -extfile /etc/ssl/openssl.cnf -extensions v3_intermediate_ca

To check the newley generated certificate

openssl x509 -in intermediate.crt -text

Finally, let us now impersonate the web server owner.

We generate our keys as usual

openssl genrsa -out server.key

We then issue a new CSR. In this case only the public key is inserted in the certificate, while the private key is used to sign it.

openssl req -new -key server.key -out server.csr

Note that during the issuing of a new CSR, the Common Name has to be the URL of the website we want to protect with SSL/TLS.

Finally, we use the intermediate CA to sign the CSR generated by the web server.

openssl x509 -req -in server.csr -out server.crt -CA intermediate.crt -CAkey intermediate.key -CAserial serial -days 365 -extfile /etc/ssl/openssl.cnf -extensions usr_cert

To check the newly created certificate we can do the following

openssl x509 -in server.crt -text

Some applications such as apache2 may require a sinngle file containing the CA certificate bundle, which is the chain root->intermediate.

To create the chain we simply need to concatenate the certificates one after the other

cat root.crt intermediate.crt > chain.crt