Trabalho elaborado por: Ricardo Nuno Mendão da Silva Jorge Miguel Morgado Henriques

Transcrição

1 Trabalho elaborado por: Ricardo Nuno Mendão da Silva Jorge Miguel Morgado Henriques

2 Contents Contents Introdução Objectivos Activação da CA privada Criação da chave de encriptação Criação do Certificate Signing Request (CSR) Criação do Certificado self signed Obtenção de certificados x Criação da chave de encriptação Criação do Certificate Signing Request (CSR) Criação do Certificado Ficheiros de configuração openssl.conf httpd.conf ssl.conf Testes Área ssc05.dei.uc.pt Acesso válido Acesso de cliente sem autorização ou fora de tempo Acesso sem certificado Área sec05.dei.uc.pt Acesso com certificado emitido pela CA privada Área intra05.dei.uc.pt Acesso a partir da rede / Acesso com login e password Acesso com certificado revogado Funcionalidades não implementadas Conclusão Bibliografia... 32

3

4 1. Introdução Com o desenvolvimento dos meios de comunicação, observa se uma convergência do uso destes, por parte de vários sectores sócio económicos, exigindo cada vez mais a garantia de um bom serviço, ou seja, fiável, eficaz e sobretudo seguro, permitindo que o utilizador final possa efectuar operações delicadas, por exemplo transacções financeiras, sem que corra o risco dessas transacções serem interceptadas por terceiros, tendo ainda a garantia de que está a efectuar a transacção com a entidade pretendida. Assim, foi desenvolvido o protocolo criptográfico SSL (Secure Sockets Layer) que permite garantir a privacidade e integridade dos dados, trocados entre duas entidades. Normalmente o ssl penas utiliza certificação do lado do servidor, garantindo assim ao utilizador que está ligado à entidade correcta, contudo pode também utilizar autenticação do lado do utilizador, fazendo com que este necessite de um certificado de autenticação, que pode ser fornecido por uma Autoridade de certificação conhecida, ou por uma Autoridade privada. Para a criação de uma Autoridade de certificados privada, pode ser usado o OpenSSL que é basicamente uma ferramenta de implementação do protocolo SSL. Com o OpenSSL é possível criar um certificado x509 self signed, criando então a Autoridade de Certificação privada, que pode funcionar como as Autoridades de Certificação oficiais, permitindo criar certificados para os utilizadores. O x509 é um standard que especifica vários padrões dos vários componentes intervenientes na comunicação segura, como por exemplo o formato das chaves e algoritmos. A Autoridade de Certificação para além de criar os certificados, pode também suspende los, ou seja, torna los inválidos antes do seu prazo de validade terminar. Todo o processo de acesso seguro, corre obviamente sobre um servidor web comum, como por exemplo o apache. Para implementar as funcionalidades de segurança requeridas, o apache possuí um módulo chamado, mod_ssl, que permite efectuar as mais variadas configurações de restrição e requerimento de certificados para com os utilizadores, implementando assim o sistema de acesso remoto via ssl, neste caso através do protocolo https. Para além deste sistema de segurança através do mod_ssl o apache permite um outro modo de segurança, nomeadamente através da autenticação dos utilizadores através de um sistema de username e password, implementado pelo mod_auth, sendo claramente bastante inferior em segurança e flexibilidade quando comparado com o SSL. Neste relatório irá constar um longo processo de descrição e testes das operações efectuadas para a criação de Autoridades de Certificação privadas, para a criação de certificados a utilizadores comuns e para a configuração de servidores de acesso seguro, com as mais variadas restrições.

5 2. Objectivos Pretende se neste trabalho utilizar o OpenSSL para activação de uma Autoridade de Certificação privada, para posteriormente criar certificados e listas de revogação de certificados. Pretende se ainda que seja efectuada a configuração do apache para autenticação e autorização de acessos a zonas de documentos, segundo vários critérios de segurança. 3. Activação da CA privada Neste ponto irão ser descritos os passos necessários para a criação de uma Autoridade de Certificação privada, sendo especificado cada parâmetro utilizado por comando. Cada um dos pontos seguintes, corresponde a um passo para a criação do certificado da Autoridade de Certificação Criação da chave de encriptação Figura 1 Criação de CA privada Neste ponto irá ser descrito o comando utilizado para gerar a chave encriptada. Ver Comando Openssl genrsa out private/ca.key 1024

6 Parâmetros genrsa out private/ca.key Define o tipo de algoritmo de encriptação para o algoritmo RSA, desenvolvido por professores do MIT, nomeadamente Ron Rivest, Adi Shamir e Len Adleman. Define o ficheiro resultante e guarda o na directoria referida, neste caso na pasta private Número de bits de encriptação que compõem a chave Criação do Certificate Signing Request (CSR) O CSR é um ficheiro que contém informação da entidade que solicita o certificado. Neste caso a própria futura Autoridade privada. Contém ainda a chave pública e informação do servidor onde está instalado. Não é mais que um certificado desencriptado. Comando Openssl req new key private/ca.key out ca.csr Parâmetros req Utilizado para processos de gestão do CSR. new Flag que identifica o comando como criação de um novo item. key Indica a chave da entidade que solicita o certificado. private/ca.key out ca.csr Indica onde ficará o ficheiro resultante deste comando Criação do Certificado self signed Por fim, já com o CSR criado, basta encriptar este com a chave da própria entidade que o pediu, sendo a origem do termo self signed. Comando openssl x509 -req -days 365 -in ca.csr -out certs/ssc\ CA.crt - signkey private/ca.key Parâmetros X509 É um comando que permite mostrar, converter, editar ou assinar certificados, sendo este último, o propósito da sua utilização neste caso.

7 -req -days 365 -in ca.csr -out certs/ssc\ CA.crt -signkey private/ca.key Opção que indica a entrada de um CSR, em vez da opção por defeito do x509 que é um certificado. Indica a validade do certificado. Indica o CSR a encriptar. Indica qual o destino e o nome do ficheiro resultante da execução deste comando. Indica a chave que irá encriptar o CSR inserido na opção in. 4. Obtenção de certificados x509 Neste ponto irá ser especificado como se processa a obtenção de certificados com o padrão x509 emitidos pela Autoridade de Certificação criada no ponto 3. Este processo pode ser comprovado imagem seguinte.

8 Figura 2 Emissão de certificado para cliente Neste trabalho gerou se uma chave rsa de 1024 bits para cada certificado emitido. O processo efectuado foi o mesmo que o descrito no ponto Emitiram se 4 certificados x509 baseados na referida CA, sendo que 3 foram atribuídos às três áreas de documentos pedidas, nomeadamente e O quarto certificado foi atribuído a um utilizador de teste. Os sub pontos que se seguem foram idênticos para os 4 certificados emitidos, variando apenas os nomes dos ficheiros resultantes, entre sec05, ssc05 e intra05 respectivamente Criação da chave de encriptação Comando Openssl genrsa out private/sec05.key 1024 Parâmetros genrsa Define o tipo de algoritmo de encriptação para o algoritmo RSA, desenvolvido por professores do MIT, nomeadamente Ron Rivest, Adi Shamir e Len Adleman.

9 out private/sec05.key Define o ficheiro resultante e guarda o na directoria referida, neste caso na pasta private Número de bits de encriptação que compõem a chave Criação do Certificate Signing Request (CSR) Neste caso o CSR contém a informação da entidade sec05, sendo que no campo Common Name terá de ser introduzido o nome completo da área (FQDN), ou seja, sec05.dei.uc.pt. no caso do CN ser diferente do nome da área, um qualquer utilizador quando aceder a essa área irá receber uma mensagem de notificação, indicando possível tentativa de passagem por falsa identidade. Comando Openssl req new key private/sec05.key out sec05.csr Parâmetros req Comando que cria e processa certificados no formato PKCS#10. new Flag que identifica o comando como criação de um novo item. key Indica a chave da entidade que solicita o certificado. private/sec05.key out sec05.csr Indica onde ficará o ficheiro resultante deste comando Criação do Certificado Por fim, com o CSR criado, este terá de ser encriptado por uma Autoridade de Certificação, que neste caso é a SSC CA criada no ponto 3. Comando openssl ca -in sec05.csr -cert certs/ssc\ CA.crt -keyfile private/ca.key -out newcerts/sec05.crt Parâmetros ca -in sec05.csr -certs certs/ssc\ CA.crt -keyfile private/ca.key Comando para assinar p, gerar CRL (Listas de Certificados revogados ) e para manter uma base de dados sobre os certificados gerados. Indica o CSR a encriptar. Indica a Autoridade de Certificação que vai assinar o CSR. Indica a chave da CA privada.

10 -out newcerts/sec05.crt Indica o ficheiro resultante de todo este processo, nomeadamente o requerido certificado. 5. Ficheiros de configuração 5.1. openssl.conf No ficheiro openssl.conf, situado na directoria /etc/pki/tls, foi criada uma área à qual se chamou CA_modded. Esta nova área é igual à área por defeito, no que respeita a opções, contudo difere da mesma no aspecto dos directórios, apontando para os directórios utilizados nos testes, como se pode observar na figura 3. Figura 3 Excerto do openssl.conf Ao modificar o parâmetro dir para /root/ssc, todos os ficheiros seguintes tomam este caminho como raíz. Na tabela seguinte irão ser explicados as entradas presentes na figura 3, que podem causar mais dúvidas. certs Crl_dir database Directório onde se encontra a CA Directório onde se encontram os ficheiros correspondentes às listas de certificados revogados pela CA. Index.txt é o ficheiro que vai sendo actualizado contendo informação de todos os certificados criados e revogados pela CA.

11 Dentro da secção [req], procedeu se à alteração da sub secção [req_distinguished_name], onde se alteraram os valores por defeito, para os valores apresentados na figura 4, por forma a tornar mais fácil o preenchimento dos requisitos requeridos na criação de um novo CSR. Figura 4 Excerto [req] do ficheiro openssl.conf Para além das duas secções referidas, este ficheiro não sofreu mais alterações, quando comparado com o original.

12 5.2. httpd.conf No ficheiro de configuração do apache. httpd.conf, apenas foram adicionados VirtualHosts na secção 3, como se pode ver na figura 5. Figura 5 Secção 3 do ficheiro httpd.conf

13 Todos os VirtualHost são ipbased e todos escutam no mesmo porto, obrigando a existência de um NameVirtualHosts para evitar que o acesso a qualquer destino alojado neste servidor, seja redireccionado sempre para o primeiro VirtualHosts. Os três VirtualHosts definidos têm a estrutura idêntica e o objectivo das suas presenças neste ficheiro de configuração é apenas para que no caso do cliente aceder a qualquer uma destas áreas via http, seja redireccionado dentro da mesma área, para https. Assim, para cada área definiu se um VirtualHost com: Raíz da área. Nome completo da área. Ficheiro de registo de erros, definição de nível de alarme e tipo de registo. Zona de configuração referente à raíz da área com: Comando de ligação do modo Rewrite Opção para permitir seguir links. Regra que permite efectuar o redireccionamento para a zona segura, acompanhada pela flag R, que força o redireccionamento e pela flag L, que aplicada a seguir à R funciona como um travão parando qualquer comando de reescrita. Como se pode observar na figura 5, no endereço https é indicado o porto, sendo que para aplicar o mod_ssl no apache, os VirtualHosts correspondentes têm de ser ipbased, logo esses VirtualHosts utilizados para ligações https, precisam de ser configurados em portos diferentes, pois caso contrário irão todos carregar o certificado do primeiro VirtualHost, sendo que esta solução é completamente transparente ao cliente. No ficheiro ssl.conf irá ser apresentado o resultado deste redireccionamento ssl.conf O ficheiro ssl.conf, ou seja, o ficheiro de configuração correspondente ao módulo que permite implementar o protocolo SSL no apache, não sofreu nenhuma alteração de base, sendo que apenas lhe foram adicionados VirtualHosts, para tratar os redireccionamentos efectuados pela configuração do ficheiro httpd.conf, ou os pedidos directos em https. Para cada VirtualHost foi configurado as restrições de acesso à respectiva área e adicionados os Listener aos novos portos, nomeadamente o porto 444 e 445. O porto 443 já estava adicionado, visto ser o porto utilizado por defeito nas ligações https. Na figura em baixo pode se observar a primeira alteração, correspondente aos virtualhosts.

14 Figura 6 VirualHosts do ficheiro ssl.conf

15 Em cada virtualhost apresentado, pode se começar por verificar as primeiras entradas que são semelhantes às apresentadas no ficheiro httpd.conf, mudando, respectivamente, apenas a directoria e os nome dos ficheiros de log. Mais abaixo, entram as novidades, ou seja, a indicação de que aquele virtualhost utiliza uma ligação SSL, o tipo de cifras que suporta, o caminho do certificado emitido para aquele virtualhosts, a sua chave e o caminho para o ficheiro que contém a lista actualizada de certificados revogados. De notar que neste ponto confirma se a existência de um certificado para cada área, devidamente acessível com base na utilização de portos diferentes, tal como se irá comprovar nos testes efectuados no ponto 6 deste relatório. Na figura que se segue, pode se observar a segunda adicção de comandos ao ficheiro ssl.conf, de forma a garantir a restrições requeridas para a área definida por cada virtualhost.

16 Figura 7 Configuração para as restrições dos directórios, ficheiro ssl.conf Como se pode observar, as condições de acesso são aplicadas directamente á directoria. Na directoria da área sec05.dei.uc.pt utiliza se o comando SSLVerifyClient require para indicar que o cliente é obrigado a possuir um certificado para aceder à área, sendo este comando completado pelo seguinte, SSLVerifyDepth 1, que ao ter o nível 1, indica que esse certificado ou é o certificado self signed da CA, ou é um certificado directamente emitido por esta. No comando SSLOptions, a entrada +StrictRequire reforça a impossibilidade de acesso em caso de falha de validação. Para a área ssc05.dei.uc.pt, utilizou se a mesma restrição que na área anterior, adicionandolhe ainda um filtro maior, através do comando SSLRequire. Neste comando, são adicionadas opções de restrição, utilizando um linguagem complexa resultante da mistura de Perl com C, garantindo o acesso apenas a clientes, cujo Common Name tivesse sido inserido manualmente pelo administrador do servidor, sendo que no caso demonstrado, apenas existe um utilizador com permissão, o utilizador rnsilva. O acesso é ainda restringido no tempo, através das variáveis TIME_WDAY e TIME_HOUR, que ainda dentro do comando SSLRequire, limitam o acesso aos dias úteis, das 8 às 17horas. Por fim a última área, correspondente à área intra05.dei.uc.pt, que apenas permite o acesso sem qualquer tipo de autenticação a clientes residentes na rede /24, através do uso de comando específicos do mod_access, o order, o deny e o allow. Assim, obriga que os clientes de outras redes forneçam, pelo menos dados de autenticação válidos, login e password. Esta validação de login e password é o sistema de autenticação básico do apache,

17 implantado pelo mod_auth que fornece neste caso, os comandos AuthType (define o tipo de autenticação [basic digest]), AuthName (Define a mensagem da janela de login), AuthUserFile (Define o ficheiro que contém os logins válidos) e Require (Define o tipo de validação, se por utilizador especifico, se por grupo ou se por qualquer individuo autenticado com êxito). O comando Satisfy any é o responsável por esta flexibilidade entre o mod_access e o mod_auth, permitindo o acesso à área apenas com o sucesso de uma das condições. No caso do cliente possuir um certificado, também o pode utilizar opcionalmente para autenticação, sendo que neste caso deveria prescindir da autenticação via login o que não acontece, sendo este caso fundamentado nos pontos 6 e 7 deste relatório. 6. Testes 6.1. Área ssc05.dei.uc.pt Acesso válido. Neste ponto, vai se demonstrar o processamento de um acesso válido à área ssc05.dei.uc.pt. O utilizador rnsilva possuí um certificado gerado pela CA e adicionou o ao seu browser, como se pode ver na figura 8. Figura 8 Certificado do cliente

18 Ao inserir o endereço no browser e clicar no ENTER, Figura 9 Inserção do endereço. o cliente recebe uma janela de notificação, a questionar sobre a aceitação de ligação a uma área segura, cujo certificado foi emitido por uma CA desconhecida, como se pode observar na figura 10. Figura 10 Notificação de certificado emitido por autoridade desconhecida. Ao clicar em OK o servidor vai efectuar o pedido do certificado do cliente rnsilva, resultante do comando SSLVerifyClient require. Caso o utilizador tenha o browser configurado para emitir o

19 seu certificado automaticamente, este processo ser lhe á transparente, caso contrário aparecerá a seguinte janela: Nesta janela o cliente poderá escolher o certificado a enviar. Figura 11 Janela de solicitação de certificado. Como o acesso foi efectuado pelo cliente rnsilva, que foi adicionado pelo administrador á lista dos utilizadores com acesso, com demonstrado na figura x e ainda, ocorreu a uma sexta feira às 16:22 da tarde, o cliente tem pleno acesso à área ssc05.dei.uc.pt. Figura 12 Excerto do ficheiro ssl.conf Acesso de cliente sem autorização ou fora de tempo

20 Neste ponto vai se mostrar a tentativa de acesso de um cliente, que mesmo com certificado válido, não acede à área, pois o seu nome não consta da lista gerida pelo administrador. Para efectuar este teste, alterou se a lista de utilizadores autorizados e efectuou se o acesso à área. Na figura em baixo pode se observar a alteração efectuada. Figura 13 Excerto do ficheiro ssl.conf modificado para teste Como o utilizador rnsilva não consta da lista, logo não terá acesso à área, resultando no log de erros do servidor, a seguinte mensagem. Esta mensagem refere que falhou uma condição requerida pelo comando SSLRequire, acontecendo o mesmo quando o utilizador, mesmo que autorizado pelo administrador e com certificado, tente aceder fora de horas ou fora dos dias úteis. Uma parte dessa condição é também demonstrada na figura de cima, visto que para conseguir efectuar um teste no dia corrente, foi necessário alterar o valor de TIME_WDAY de 5 para 6, englobando para além dos dias úteis, o sábado. Mantendo o sábado como dia válido, alterou se a hora final, em TIME_HOUR de 17 para 12, e voltou se a adicionar o utilizador rnsilva à lista de permissões, como demonstra na figura em baixo.

21 Figura 14 Excerto do ficheiro ssl.conf modificado para teste Ora, deste modo e visto que o teste decorre precisamente às 13:52, o acesso foi bloqueado e nova mensagem adicionada no ficheiro de log, demonstrado na figura seguinte. Figura 15 Ficheiro de log de erros da área ssc05 Por fim repuseram se os valores correctos,definidos pelo enunciado, e tentou se efectuar o acesso ao sábado, que falhando, levou novamente à análise do ficheiro de log de erros, onde mais uma vez foi adicionada uma linha de erro relativamente à falta de um requerimento do SSL.

22 Figura 16 Ficheiro de log de erros da área ssc05 De notar, que estes testes foram efectuados todos no mesmo dia e pela mesma altura, o que levou a realizar uma situação inversa de teste, ou seja, a alteração dos ficheiros de configuração, para garantir o funcionamento das restrições, nele inseridas. Com a ajuda dos ficheiros de log, é possível observar as datas precisas do teste Acesso sem certificado O cliente introduz o endereço da área no seu browser e ao tentar aceder à área sem o certificado, o acesso é negado, ficando registado no log de erros a seguinte entrada.

23 Figura 18 Ficheiro de log de erros da área ssc05 O erro apresentado na imagem em cima, é igual para a tentativa de acesso a qualquer das áreas apresentadas neste relatório, que obrigam a que o cliente apresente um certificado emitido pela CA privada e este não o possuí Área sec05.dei.uc.pt Acesso com certificado emitido pela CA privada O utilizador rnsilva possuí um certificado gerado pela CA e adicionou o ao seu browser, como se pode ver na figura 19.

24 Figura 19 Certificado do cliente. Ao inserir o endereço no browser e clicar no ENTER, o cliente recebe uma janela de notificação, a questionar sobre a aceitação de ligação a uma área segura, cujo certificado foi emitido por uma CA desconhecida, como se pode observar na figura 20. Figura 20 Notificação de certificado desconhecido.

25 Ao clicar em OK o servidor vai efectuar o pedido do certificado do cliente rnsilva, resultante do comando SSLVerifyClient require. Caso o utilizador tenha o browser configurado para emitir o seu certificado automaticamente, este processo ser lhe á transparente, caso contrário aparecerá a seguinte janela: Nesta janela o cliente poderá escolher o certificado a enviar. Figura 21 Janela de selecção de certificado do lado do cliente. Ao clicar em OK terá acesso à área, pois o seu certificado foi directamente emitido pela CA privada. Figura 17 Página segura da área sec05

26 6.3. Área intra05.dei.uc.pt Acesso a partir da rede /24 Com a tentativa de acesso a partir da rede /24, o cliente não necessita de qualquer tipo de autenticação, nem de certificado, sendo directamente redireccionado para a área segura. O código apresentado na figura em baixo é o responsável por essa acção Acesso com login e password Figura 22 Página da zona segura de intra05. Quando o utilizador não se encontra na /24 e não apresenta certifcado, é lhe apresentada uma janela, para que este insira os seus dados de login, dados esses previamente adicionados pelo administrador, a um ficheiro especifico com o comando htpasswd c /var/www/passwd/passwords rnsilva ou htpasswd /var/www/passwd/passwords rnsilva, caso o ficheiro já tenha sido criado.

27 Figura 23 Ip fora da rede e pedido de autenticação. Ao introduzir as suas credenciais válidas, o utilizador tem então acesso à área. Figura 24 Entrada na zona segura de intra05 com sucesso.

28 Caso o utilizador insira as credenciais erradas, a janela de pedido dessas credenciais, teima sempre em voltar a aparecer, sendo a única opção do cliente que não tem credenciais, cancelar essa janela, aparecendo lhe a seguinte mensagem. Figura 25 Autorização negada a utilizador inválido. Acompanhado com essa mensagem, fica registado no log de erro, o erro 401 que significa que existiu uma tentativa de acesso não autorizada, a uma zona que o exigia Acesso com certificado revogado Para além de todas as restrições especificas por cada área, o servidor configurado, também verifica se os certificados que os clientes estão a tentar utilizar para aceder a cada área, não se encontram revogados. Para revogar um certificado o administrador utiliza os comandos demonstrados na figura seguinte:

29 Figura 26 exemplo e comprovação da acção de revogação de um certificado. Na figura, está demonstrado a verde o comando de revogação do certificado rnsilva.crt, a amarelo está o comando que gera o ficheiro com a lista dos certificados revogados e a vermelho o contéudo desse ficheiro. Como na configuração do ficheiro ssl.conf, foi adicionada a linha : SSLCARevocationFile /root/ssc/crl/upd1.crl, que faz com que o servidor quando recebe um certificado, verifica se este está na lista dos certificados revogados. Como cenário de teste revogou se o certificado do utilizador rnsilva, sendo que quando este tentou aceder, posteriormente, à área sec05.dei.uc.pt (que apenas requer em certificado válido), esse acesso é negado e fica registado no log uma mensagem, como demonstra a seguinte figura.

30 Figura 27 ficheiro log da área sec05.dei.uc.pt 7. Funcionalidades não implementadas No desenvolvimento de trabalho ficaram três pontos por afinar, nomeadamente: Revogações detectadas por directório e não por ficheiro. Lista de clientes com acesso à ssc05.dei.uc.pt contida num ficheiro específico, em vez de ser inserido manualmente no ficheiro de configuração. No acesso à área intra05.dei.uc.pt mesmo que o utilizador apresente certificado, terá sempre que inserir as credenciais de acesso. Ora, em relação ao primeiro ponto, todo o processo estudado para implementar o sistema de analise das revogações através da directoria foi implementado, quando algum detalhe deverá estar a faltar, pois o sistema não funciona. Os passos seguidos foram: Criar o directório e colocar lá os ficheiros *.crl criados. Efectuar o link simbólico para cada um através do comando: ln s upd1.crl `openssl crl hash noout in upd1.crl`.r0 ou com o makefile fornecido juntamente com o mod_ssl. Inserir o comando SSLCARevocationPath /root/ssc/crl/ no ficheiro de configuração. No segundo ponto, tentou se efectuar a inserção dos utilizadores válidos num ficheiro, através de dois modos. Um utilizando a função file( path ), definido na documentação do mod_ssl para o comando SSLRequire e o outro utilizando uma interacção com o mod_auth

31 tentando criar um sistema de autenticação apenas com o username. Contudo nenhuma destas tentativas se tornou solução, sendo que optou se por utilizar a solução implementada, que para o contexto de teste é viável, ao contrário de casos reais em que a lista de acessos permitidos seja de larga escala. Com certeza que existirá uma solução bem viável, mas que no contexto da realização deste trabalho, não foi encontrada. No terceiro ponto, em que definido pelo enunciado, o acesso à zona intra05.dei.uc.pt, para utilizadores fora da rede /24, seria permitido consoante uma de duas hipóteses, a apresentação de um certificado válido ou a introdução de credenciais, username e password, caso não existi se um certificado válido. É entre estas duas hipóteses que o sistema implementado falha, pois nos testes realizados, mesmo que o utilizador apresente um certificado válido, o sistema pede lhe sempre as credenciais de login. Uma solução teoricamente possível seria a utilização do comando Satify any que tão bem funciona entre o mod_access e o mod_auth, mas que com o mod_ssl não mantém o mesmo nível. Deverá contudo existir uma condição que permita evitar que o cliente seja obrigado a inserir as credenciais, quando já emitiu um certificado válido. 8. Conclusão Este trabalho consistia na emissão de certificados e configuração de servidores apache para acesso seguro, utilizando o mod_ssl. É uma área importante que actualmente permite restringir o acesso e possibilitar acções de grande importância, sobre uma rede aberta, como a internet. Ao realizar este trabalho, o grupo, adquiriu variados conceitos dentro desta área e tomou noção e contacto com a configuração completamente manual que estes sistemas exigem. Deparou se também como uma vasta documentação, do apache e dos vários módulos, contudo existem pontos específicos pouco fundamentados e com poucos How to s, como no caso do comando SSLRequire, que segundo a documentação parece ter enorme potencial, mas que com a sua difícil linguagem de configuração requer um conhecimento algo profundo e alguma prática, para dele retirar todo o proveito. Assim, dá se por concluído este trabalho e fica se com o conhecimento destas ferramentas, ficando a base para uma futura evolução neste campo.

32 9. Bibliografia [http06] [mod_ssl06] [mod_auth06] [mod_rewrite06] [mod_access06] [ssl06] [crl01] [apache00] SSL.html