# Trabalho realizado na Semana #12

> # Ficha da semana #12 - Public-Key Infrastructure (PKI)

## 3.1 Task 1: Becoming a Certificate Authority (CA)

Depois de feito o *setup* do container na virtual machine, criamos o ficheiro myCA_openssl.cnf com o conteúdo do openssl.cnf, mas com ligeiras alterações.
Criamos também os diretórios e ficheiros necessários.
Executamos o código:

openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 \
-keyout ca.key -out ca.crt \
-subj "/CN=www.modelCA.com/O=Model CA LTD./C=US" \
-passout pass:dees

gerando um certificado de uma CA.


<br>

**Questões**

**Que parte do certificado indica que se trata de um certificado de uma CA?**

A parte do certificado que nos indica que estamos perante um certificado de uma CA, é precisamente a seguinte linha:


<br>

**Que parte do certificado indica que se trata de um certificado assinado pelo próprio?**

Garantimos que este certificado se trata de um autoassinado, pois o emisssor e o sujeito são os mesmos.


<br>

**No algoritmo da RSA, temos um expoente público e, um expoente privado d, um módulo n, e dois números secretos p e q, tais que n = pq. Identifique os valores para estes elementos no seu certificado e ficheiros-chave.**

expoente público **e**: 

expoente privado **d**:

modulos **n**: 

número **p**:

número **q**:

ficheiros-chave: **ca.key** e **ca.crt**


## 3.2 Task 2: Generating a Certificate Request for Your Web Server

Usando o comando abaixo foi possível gerar um *Certificate Signing Request (CSR)* para o nosso servidor `www.sequeiracarvalhocardoso2022.com` com dois nomes alternativos.


## 3.3 Task 3: Generating a Certificate for your server

Primeiro retiramos o "#" do ficheiro myCA_openssl.cnf de modo a permitir que o comando **openssl ca** copie o campo de extensões do pedido para o certificado.

Depois, executamos o comando:


que transforma o pedido de certificado num **certificado X509**.

O diretório **newcerts**, previamente vazio, ficou com um novo ficheiro lá dentro.


Como vemos na imagem abaixo, os nomes alternativos do servidor estão presentes no conteúdo do certificado.


## 3.4 Task 4: Deploying Certificate in an Apache-Based HTTPS Website

Através da shell criada no container, criamos um novo ficheiro **sequeiracarvalhocardoso2022_apache_ssl.cnf**, no diretório **/etc/apache2/sites-available**, com o mesmo conteúdo do ficheiro **bank32_apache_ssl.conf**, mas substituindo "bank32" por "sequeiracarvalhocardoso". É importante referir que os ficheiros **.crt** e **.key** foram copiados para o diretorio `/volumes/certs`, de modo a serem partilhados entre a VM e o container.


Como já tinhamos feito **build** ao container apenas foi necessário correr o comando **service apache2 start** para dar início ao servidor.


Escrevendo o URL **`https://www.sequeiracarvalhocardoso2022.com`** na barra de endereço, aparece-nos um aviso de site inseguro, não sendo possível aceder ao site. Apenas quando se carrega nas opções avançadas e assumindo o risco é que é possível ver:


De modo a corrigir, acedemos às preferências do Firefox à secção de "View certificates" e adicionamos o nosso certificado **ca.crt**.


Agora que a autoridade que assinou o certificado foi reconhecida, o browser já assume o nosso site como sendo seguro.


## 3.5 Task 5: Launching a Man-In-The-Middle Attack

Adicionamos `10.9.0.80 www.ex.com` ao ficheiro /etc/hosts e mudamos o nome do servidor no ficheiro sequeiracarvalhocardoso2022_apache_ssl.cnf para **`www.ex.com`**.


Reiniciando a Apache server e acedendo ao site, aparece-nos:


Apesar de termos feito o reconhecimento da autoridade que assinou o certificado na task anterior, o browser assume o site como sendo inseguro. Isto porque, como apenas mudamos o nome do servidor e não alteramos os endereços que o browser estaria à espera de reconhecer (`www.sequeiracarvalhocardoso2022.com`, `www.sequeiracarvalhocardoso2022A.com`, `www.sequeiracarvalhocardoso2022B.com`), `www.ex.com` não se encontra entre os possíveis, ocorrendo então num aviso de segurança.

## 3.6 Task 6: Launching a Man-In-The-Middle Attack with a Compromised CA

Assumindo que o CA criado na Task 1 está comprometido, partimos dele para gerar outro *Certificate Signing Request* (CSR) como na Task 2, mas agora acrescentando o DNS: **`www.ex.com`**


Depois, como na Task 3, geramos um certificado X509 a partir do pedido.
Verificamos que o novo DNS aparece em baixo na figura.


Na shell do container, alteramos novamente o SSLCertificateFile e SSLCertificateKeyFile, do ficheiro sequeiracarvalhocardoso2022_apache_ssl_conf, para os nomes com que o certificado e a key foram criados: **server.crt** e **server.key**.


Depois de reiniciar o Apache server, vemos que o browser assume o site como sendo seguro, uma vez que o certificado foi assinado em nome da CA. Isto apenas foi possível porque tinhamos acesso à sua chave privada, gerando assim certificados cuja autoridade é reconhecida.