PKI

PKI stands for Private Key Infrastructure and it’s an infrastructure which enables secure communication. PKI is a set of rules, algorithms and protocols that enables one to build trust relationships between different entities (CA, intermediate CAs and end-users).

Certificate

The main goal of a certificate is to store the public key. The following information is included in the certificate:

information about the owner
information about the issuer
signature
public key

CA (Certification Authority) role is to sign certificates or delegate it’s role to intermediate CAs. Both CA and intermediate CAs have their own private/public key. CA and intermediate CAs create the so called chain of trust.

The list below shows different certificate domain scopes:

single domain
multi domain
wildcard domain

Encryption

Encryption Algorithms:

AES (Advanced Encryption Standard) - symetric key algorithm

There are two types:
- AES-128 - with 128 bit key length
- AES-256 - with 256 bit key length
RSA (Rivest-Shamir-Adleman) - asymmetric key algorithm, requires private and public keys

RSA is public key kryptosystem
DES, 3DES - obsolete

Key formats:

PEM - base64 encoded ASCII
DER - binary files
PKCS #7 - used by Windows and Apache Tomcat
PKCS #12

Conventions:

private key certificates have the *-key.pem, *.key extension
public key (certificate) certificates have the *.pem, *.cert extension

Tasks which can be performed with asymetric keys:

signing: requires private key

Signing works by generating the hash and then encrypting it.

To make the procedure more efficient one generates a checksum file and signs this file. This way signing is done on a file which has much smaller size.
verify signature: requires public key
encryption - requires public key
descryption - requires private key

NOTE

Public key can also encrypt data, so it’s just a matter of agreeing which one is private and which one is public. The keys are technically the same.

/etc/ssl/certs/ - directory containing root certificates

Hashing

Hashes are used to guarantee integrity of the data. Hashes generated by the same algorithm are the same length. Hashing is a one way algorithm - original data can’t be restored from the hash.

Hashing algorithms:

MD5 - generates a hash of 128 bit length (32 hexadecimal characters, each hexadecimal character is 4 bits long)
```
md5 file-name
```
SHA
- SHA-1 - uses a 160 bit hash length
- SHA-256 - uses a 256 bit hash length
  
  get the files checksum:
```
shasum -a 256 file-name
```
  or
```
sha256sum file-name
```
  check if hash is matching file:
```
echo '846b6fa1a9c23fd32e3d9f98b982f47d8aa326abd55b60f3dca5e636b03a9ff8  file-name' | sha256sum -c
```
- SHA-512 - uses a 512 bit hash length
HMAC - is usually used together with SHA or MD5. HMAC takes data and secret key and generates a hash. With this type of algorithms one can guarantee the senders identity.

Basic Commands

Generate a 256-bit symmetric key (AES key material):

dd if=/dev/urandom of=PlaintextKeyMaterial.bin bs=32 count=1

openssl rand -out PlaintextKeyMaterial.bin 32

view certificate in human readable form:

openssl x509 -text -noout -in /etc/kubernetes/pki/apiserver.crt

generate private RSA key with passphrase:
```
openssl genrsa -aes256 -out my-key.pem 4096
```
Use -passout flag to provide passphrase:
- -passout stdin (default)
- -passout pass:some_passphrase
- -passout file:passphrase.txt
or
```
openssl genpkey -aes-256-cbc -algorithm RSA -out my-key.pem -pkeyopt rsa_keygen_bits:4096 -pass pass:some_passphrase
```
Use -pass flag to provide passphrase.
generate private RSA key without passphrase:
```
openssl genrsa -out my-key.pem 4096
```
extract public key from private key:
```
openssl rsa -in my-key.pem -pubout -out my.pub
```
Use -passin flag to provide passphrase via command line:
- -passin stdin (default)
- -passin pass:some_passphrase
- -passin file:passphrase.txt
NOTE

Public key is encoded in the private key
generate key and (self signed) certificate at once:
```
openssl req -x509 -newkey rsa:4096 -keyout my-key.pem -out my-cert.pem -days 30 -sha256
```
Use -nodes to skip passphrase.

Use -subj to specify subject parameters:

-subj "/C=DE/ST=Berlin-Brandenburg/L=Berlin/O=czerasz.com Scalable Web-Systems/OU=IT/CN=czerasz.com"

One can also use a configuration file as described here.

generate a CSR:

openssl req -new -key my-key.pem -sha256 -days 365 -out my-csr.pem

view CSR:

openssl req -in my-csr.pem -text -noout

generate certificate for CSR:

openssl x509 -req -in my-csr.pem -CA my-ca.pem -CAkey my-key.pem -CAcreateserial -out my-cert.pem -days 500 -sha256

my-ca.pem is a self signed certificate used by the CA.

sign a file:

openssl dgst -sha256 -sign my-key.pem -out signature.sha256.bin file.txt

-passin pass:foobar

create a base64 encoded version:

openssl base64 -in signature.sha256.bin -out signature.sha256

To verify the signature:

openssl base64 -d -in signature.sha256 -out signature.sha256.bin
openssl dgst -sha256 -verify public.pem -signature signature.sha256.bin file.txt

CSR - Certificate Signing Request

Contains the following sections:

public key
Subject Name (SN)
- Country
- State
- Organisation
- Organisational Unit - example: BI, IT, Finance
- Common Name - is mandatory, is defined as the main domain where the certificate will be used

The certificate chain is send to the client because operating systems have only root certificates.The root certificate is not send in the chain to the client.

Firefox will report an issue if the full certificate chain is not provided. Simply concatenate, in the same order, certificates of multiple intermediate CAs together.

SSL and TLS Protocols

SSL and TLS are both cryptographical protocols. The certificate does NOT depend on the protocol.

SSL (2.0, 3.0) and TLS < 1.2 are deprecated. Do NOT use SSL 2.0, 3.0 and TLS 1.0, 1.1. SSL is venerable to various attacks.

Why not use RSA for data encryption:

slow
both sides would need private and public keys

Establishing TLS session:

negotiate cipher suite
server sends to the client the TLS certificate
client validated the TLS certificate
generate symetric key for data encryption
send/receive encrypted data

Diffie-Hellman algorithm is used to generate keys over insecure public connection.

Let’s Encrypt

Find here statisctics on Let’s Encrypt usage.

Find here instructions on how to use certbot with specific software.

Renew certificate with certbot:

certbot renew [--dry-run]

SNI

SNI stands for Server Name Indication and is a TLS extension which enables the client to specify which host it wants to connect to

Example - self-signed certificates with own CA

generate CA (Certification Authority) private key (czerasz.local-ca.key)

openssl genrsa \
  -out czerasz.local-ca.key \
  -des3 -passout pass:super-secure `# skip line at own risk` \
  2048

generate a root certificate

openssl req -x509 -new -nodes \
  -key czerasz.local-ca.key \
  -passin pass:super-secure \
  -sha256 \
  -subj "/C=DE/ST=Berlin-Brandenburg/L=Berlin/O=czerasz.local Local GmbH/OU=IT/CN=czerasz.local" \
  -days 1825 \
  -out czerasz.local-ca.pem

distribute czerasz.local-ca.pem to all needed devices and trust

generate private key for specific domain

openssl genrsa -out test.czerasz.local.key 2048

create certificate signing request (test.czerasz.local.csr)

openssl req -new \
  -key test.czerasz.local.key \
  -subj "/C=DE/ST=Berlin-Brandenburg/L=Berlin/O=czerasz.local Local GmbH/OU=IT/CN=can-be-extended-with-alt-names.czerasz.local" \
  -out test.czerasz.local.csr

create config file

cat <<EOS > test.czerasz.local.ext
authorityKeyIdentifier = keyid,issuer
basicConstraints = CA:FALSE

keyUsage = digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment

subjectAltName = @alt_names

[alt_names]
DNS.1 = test.czerasz.local
EOS

generate certificate for test.czerasz.local signed by own CA

openssl x509 -req \
  -CA czerasz.local-ca.pem -CAkey czerasz.local-ca.key \
  -passin pass:super-secure \
  -CAcreateserial \
  -in test.czerasz.local.csr \
  -out test.czerasz.local.crt \
  -days 825 -sha256 \
  -extfile test.czerasz.local.ext

PKI