Certificado auto-assinado não confiável

1

Eu criei minha própria CA:

openssl genrsa -out private/rootCA.key 2048
openssl req -batch -new -x509 -nodes -key private/rootCA.key -sha256 -days 1024 -config ./openssl.conf -out certs/rootCA.pem

Eu criei um certificado para o meu site:

openssl genrsa -out private/$domain.key 2048
openssl req -batch -new -key private/$domain.key -config ./openssl.conf -subj "/commonName=$domain" -out csr/$domain.csr
openssl x509 -req -in csr/$domain.csr -CA certs/rootCA.pem -CAkey private/rootCA.key -CAcreateserial -out certs/$domain.crt -days 500 -sha256

Eu participo do certificado do site e do certificado raiz em um pacote:

cat certs/$domain.crt certs/rootCA.pem > bundles/$domain.bundle.crt

Eu copio o certificado / chave para o diretório de configuração do nginx:

cp bundles/$domain.bundle.crt private/$domain.key /etc/nginx/conf/certs

Garanto que o nginx usa esses certificados para o meu site:

    ssl_certificate /etc/nginx/certs/mysite.bundle.crt;
    ssl_certificate_key /etc/nginx/certs/mysite.key;

Eu reinicio o nginx.

Eu instalo o certificado raiz no meu sistema:

sudo cp certs/rootCA.pem /usr/local/share/ca-certificates/myrootCA.crt
sudo update-ca-certificates

Verifico com httpie :

»http link

http: error: SSLError: HTTPSConnectionPool(host='mysite', port=443): Max retries exceeded with url: / (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)",),))

Verifico com openssl (dizendo para usar o diretório ca-certificates, que não é usado por padrão):

openssl s_client -host mysite -port 443 -prexit -showcerts -CApath /usr/local/share/ca-certificates

O que dá:

Verify return code: 19 (self signed certificate in certificate chain)

E a verificação não é concluída.

Abrir o site no Chrome me dá o erro padrão:

This server could not prove that it is mysite; its security certificate is not trusted by your computer's operating system. This may be caused by a misconfiguration or an attacker intercepting your connection.

Eu tenho duas perguntas:

  1. Por que o site não é confiável, em todo o sistema, depois de instalar o certificado raiz? O Chrome está usando certificados de todo o sistema, certo?
  2. Por que o open_ssl s_client não consegue concluir a validação do certificado?

EDITAR

O Curl está funcionando, com o certificado instalado em todo o sistema:

curl https://mysite

Por que o curl está funcionando e o chrome / httpie não?

    
por dangonfast 19.03.2018 / 10:48

2 respostas

1

Para o OpenSSL Ubuntu update-ca-certificates , conforme descrito na página man de /usr/share/ca-certificates AND /usr/local/share/ca-certificates , mas grava links simbólicos com os nomes subjhash.num necessário pelo OpenSSL para /etc/ssl/certs e um arquivo combinado em /etc/ssl/certs/ca-certificates.crt , então os dois últimos devem ser usados com -CApath e / ou -CAfile respectivamente.

curl aparentemente usa o padrão OpenSSL, que nesta compilação é /etc/ssl/certs/ , mas dependendo de qual Ubuntu, o OpenSSL pode ter idade suficiente para ter o bug que a linha de comando s_client NÃO usa o padrão automaticamente. p>

Para o Chrome não posso ajudar; Eu não uso o Chrome no Ubuntu. CW esquerda no caso de outra pessoa poder.

Embora eu saiba que quando a CA é confiável, o Chrome recente também exige que seu certificado servidor (em termos PKI, Entidade final = EE = não CA) tenha uma extensão SAN (SubjectAlternateNames) com nome (s) correto (s), que nenhum dos outros faz (por enquanto), e você não indica se / como você fez isso. (expandido :) rfc 2818 para HTTPS e os padrões CABforum têm, por mais de uma década, certs de servidor necessários para conter SAN válida, e agora todos ou quase todos os clientes usam SAN quando presentes, mas que eu saiba Até agora, o Chrome é o único cliente que requer que SAN esteja presente.

    
por 20.03.2018 / 01:38
0

Parece que minha CA raiz autogerada estava errada. Estava faltando:

basicConstraints               = CA:TRUE

Depois de resolver isso, httpie está se comportando corretamente. É estranho que curl não estivesse reclamando disso.

Isso ainda não está resolvendo o problema no Chrome ... Suponho que o Chrome não use CAs do sistema inteiro.

    
por 19.03.2018 / 16:02