O problema foi que, quando carreguei o arquivo de configuração personalizado com a opção cfg= , ele não carregou mais o arquivo de configuração padrão em /etc/lynx/lynx.cfg .
Estou tentando visitar o que estou assumindo como uma página válida com certificação SSL, link , mas o lynx sempre diz SSL error:The certificate is NOT trusted. The certificate is...-Continue? (n)
Eu não fiz nenhuma configuração do lynx além do seguinte arquivo de configuração:
SET_COOKIES:TRUE
ACCEPT_ALL_COOKIES:TRUE
PERSISTENT_COOKIES:TRUE
COOKIE_FILE:$home/.lynx_cookies
Por que estou recebendo este aviso e solicitado a pressionar "y" para continuar? Eu não vejo o ponto se, literalmente, todo site que estou visitando não é confiável.
Para reproduzi-lo, apenas lynx -cfg=lynx.cfg https://google.com com lynx.cfg como acima.
editar
para responder a algumas perguntas nos comentários.
a pasta / etc / ssl / certs / tem muitas coisas, não vou listar tudo a menos que seja importante.
executando ldd $(which lynx) |grep -i ssl não tem saída.
o arquivo /etc/lynx/lynx.cfg tem essa linha SSL_CERT_FILE:/etc/ssl/certs/ca-certificates.crt ... as outras correspondências para SSL_CERT grep parecem ser apenas comentários
A execução de openssl s_client -quiet -connect google.com:443 mostra isso:
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com
verify return:1
A mensagem é (consulte WWW / Library / Implementation / HTTP.c ):
the certificate is not trusted
(não há NOT na origem do lince, apesar de seu uso em Debian # 795958 ). Essa mensagem vem da configuração do lynx, tornando provável que o OP esteja usando o Debian ou uma distribuição derivada como o Ubuntu. Todos os outros pacotes usando o OpenSSL.
Ele pode vir do próprio gnutls, como mencionado em [gnutls-devel] ] Não é possível confiar no certificado do servidor em vez de emitir a CA , mas sem as informações da versão, não é possível identificar o problema exato.
Com exceção de um novo relatório de bug (e o StackExchange não é um mecanismo de relatório de bugs), essas mudanças foram relacionadas a essa área do código desde que foi introduzido em 2006 (veja CASAS ). Existem mudanças mais recentes, mas nada aparente no resumo de alterações relevantes para esta questão:
2013-11-28 (2.8.8dev.17)
* ignore non-fatal return codes from gnutls_handshake introduced by SNI change
in 2.8.8dev.15 (Debian #724812, patch by Hans Wurst).
2012-11-18 (2.8.8dev.15)
* improve checking of certificates in the gnutls_certificate_verify_peers2()
by handling special case where self-signed certificates should be reported
(patch by Jamie Strandboge).
2012-08-15 (2.8.8dev.13)
* improve checking of certificates in the gnutls_certificate_verify_peers2()
(report by Martin Georgiev) -TD
2010-06-21 (2.8.8dev.4)
* check for SSL error when reading response from "GET". This incidentally
exposes a longstanding bug in GNUTLS:
https://savannah.gnu.org/support/index.php?106987
(google the message "A TLS packet with unexpected length was received")
which prevents connection to
https://www.mynortonaccount.com/amsweb/default.do
(report by Ignac Vucko) -TD
2009-08-28 (2.8.8dev.1)
* correct check for return-value from gnutls_certificate_verify_peers2(), which
in conjunction with unclean internals of gnutls caused caused some sites to
be treated as if they were version-1 X.509 CAs (Debian #231609,
Ubuntu 293708) -TD
Tanto o Debian quanto o Ubuntu possuem sistemas de relatório de bugs; O Debian fornece o melhor feedback para o lynx. Followups para relatórios de erros existentes (assim como novos relatórios) devem ser direcionados para os sistemas de relatórios de erros.
Certifique-se de que o relógio do sistema esteja correto. Os navegadores podem mostrar um aviso SSL devido a data e hora impróprias.