Riscos de certificado autoassinados

2

Atualmente, estou usando um certificado auto-assinado para fins de desenvolvimento interno e quero ter certeza de que estou ciente de quaisquer riscos reais à segurança.

Veja como eu configuro as coisas.

Certificado raiz

  1. Criado uma CA raiz .pvk e .cert
  2. Instalou a raiz raiz da autoridade de certificação .cert em minha máquina local em "Autoridades de certificação raiz confiáveis"
  3. Instalou a raiz raiz da autoridade de certificação .cert em meu servidor de hospedagem de desenvolvimento em "Autoridades de certificação raiz confiáveis"

Certificado para o meu site

  1. Gerado outro certificado a partir da raiz .cert e .pvk
  2. Importou o novo certificado como um arquivo .pfx no servidor de hospedagem
  3. Configure o servidor de hospedagem para usar o novo certificado do meu site no IIS

Além da chave privada do certificado raiz, existem outros dados que representam um risco de segurança se alguém os encontrar?

    
por bingles 12.01.2012 / 18:43

2 respostas

2

Seu certificado de site (+ chave privada) deve ser tratado como qualquer certificado de site. Se alguém conseguisse obter a chave privada, seria capaz de se passar por seu site. Há pouca diferença no modo como você deve confiar no serviço de hospedagem para um certificado emitido por uma autoridade de certificação comercial.

Os riscos aqui são mitigados pelo fato de que, desde que você criou sua própria autoridade de certificação, poucas pessoas confiarão nessa autoridade por padrão. É um risco efetivamente limitado àqueles que optaram por confiar em sua CA.

O mesmo se aplica à chave privada da CA. Alguém que consiga sua chave privada pode emitir qualquer certificado.

Os maiores problemas vêm do fato de que as interfaces de usuário tendem a tratar todas as CAs confiáveis igualmente (a menos que EV certs), ou de forma muito semelhante, se o usuário não prestar atenção. Como resultado, se um invasor (a) possuísse a chave privada de sua CA e (b) conhecesse um usuário que confia nesse certificado da CA, ele poderia criar um certificado válido para qualquer site que desejasse.

Sua avaliação de risco deve levar em consideração quem optará por confiar nessa CA interna. As CAs comerciais tendem a ter políticas rígidas em relação à proteção de suas chaves privadas (geralmente, armazenamento não-extraível em cartões inteligentes ou similares): isso geralmente é um requisito para ser aprovado para inclusão na maioria dos navegadores.

Mais especificamente sobre "outras informações". Pode ser importante, ao projetar uma CA, ter uma política sobre quais atributos e como os DNs de assunto estão estruturados, por exemplo. Conheço algumas CAs que nunca explicaram a identidade do usuário no certificado (que geralmente é público e geralmente visível durante o handshake para um interceptador), portanto, o Subject DN era apenas uma ID interna, conhecida da CA ( e possivelmente vinculado a um nome real entre o serviço e a CA por um canal de retorno criptografado ou mecanismo similar).

    
por 12.01.2012 / 19:16
7

Um certificado auto-assinado interno não é um risco, desde que as pessoas saibam que ele é um certificado autoassinado. O maior risco que eles representam é para os clientes.

Por exemplo, quando você distribui para um cliente e faz a conexão inicial, você deve verificar se ele é válido, mas além disso, o único benefício em usar um provedor de terceiros é que você não precisa se preocupe com um invasor fingindo ser seu servidor, mas isso significa que você teria sido hackeado para começar e ter muitos outros problemas também.

Portanto, o maior risco de segurança não é informar às pessoas que é um certificado auto-assinado e verificar sua localização. Pelo menos na minha opinião. Além disso, eles não são gerenciados por uma CA, então você não pode emitir revogações de certificado e teria que realmente refazer a chave se as coisas estivessem comprometidas - mas para um sistema interno, eu realmente não estaria preocupado com isso. / p>     

por 12.01.2012 / 19:15