O certificado autoassinado dá erro “x509: certificado assinado por autoridade desconhecida”

0

Eu quero estabelecer uma conexão segura com certificados autoassinados. Eu usei o seguinte arquivo conf para openssl

[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no

[req_distinguished_name]
countryName = EN
stateOrProvinceName = NY
localityName = New York
organizationName = MyOrg
organizationalUnitName = MyDept

[v3_req]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
basicConstraints = CA:TRUE
subjectAltName = @alt_names

[alt_names]
IP.1 = 10.0.4.70

E gerou os certificados em execução

openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout key.pem -out cert.pem -config openssl.cnf

No entanto, quando meu servidor pega esses certificados eu recebo

[WARNING] 2018/04/14 14:19:09 push_to_system.go:419: sending sample request failed:Post https://10.0.4.70:8090/content/: x509: certificate signed by unknown authority

Como corrijo minha geração de certificados para evitar esse problema?

    
por Mnemosyne 14.04.2018 / 14:29

2 respostas

1

A resposta de Sam pode fazer você trabalhar, mas NÃO é uma boa ideia para a produção. Para maior clareza, vou tentar explicar por que você está recebendo isso.

NÃO é suficiente criar um conjunto de chaves de criptografia usadas para assinar certificados. Qualquer um, e você acabou de fazer, pode fazer isso. É por isso que existem "Autoridades de certificado confiáveis". Essas são entidades conhecidas e confiáveis. Uma implementação ssl vem com uma lista de autoridades e suas chaves públicas para verificar se os certificados declarados como assinados por eles são de fato deles e não de outra pessoa que afirma ser eles ..

Assim, quando você cria sua própria, qualquer implementação ssl verá que um certificado é assinado por você, mas eles não sabem que você pode ser confiável, a menos que você adicione CA (autoridade de certificação) à lista de confiáveis vai recusar. SSL não é apenas criptografar mensagens, mas também verificar se a pessoa com quem você está conversando ou a pessoa que assinou cyptograficamente alguma coisa é quem eles dizem ser.

NÃO É uma boa idéia atacar "ignorar", "ignorar" ou o que não é a verificação na produção, pois ela aceitará certificados de qualquer pessoa, tornando-o vulnerável a falsificação de identidade ou homem nos ataques do meio.

Seu problema NÃO é com a criação do seu certificado, mas com a configuração do seu cliente SSL. É muito claro que se recusou a conectar porque não sabe com quem está falando. (isso é bom)

Você deve configurar sua autoridade de certificação como confiável nos clientes. Isso depende da sua configuração, portanto, mais detalhes são necessários para ajudá-lo. Estas são outra questão que tenta resolver esse problema:

Adicionando um certificado auto-assinado à lista confiável

Adicionar certificado autoassinado ao Ubuntu para uso com enrolar

Observe que isso funcionará APENAS para você, se você tiver clientes de terceiros que falarão, todos recusarão seu certificado pela mesma razão e terão que fazer os mesmos ajustes. É por isso que as CAs confiáveis vendem o serviço de assinatura de certificados para aplicativos / servidores, etc., porque elas já estão na lista e são confiáveis para verificar quem você é. Então, se você pagá-los para fazer isso, o certificado resultante será de confiança de todos. :)

referência " link

    
por 14.04.2018 / 15:32
0

Você pode tentar uma solução alternativa usando -tls-skip-verify , que deve ignorar o erro. No entanto, isso é apenas temporário. correção: você deve tentar resolver o problema reiniciando a instância do openSSL - configurando um novo certificado e / ou reinicializando seu servidor.

    
por 14.04.2018 / 14:31