Erro estranho de TLS ao usar curl no servidor de origem x.509

Erro estranho de TLS ao usar curl no servidor de origem x.509

Espero que alguém possa ajudar a explicar o que está acontecendo nesta situação.

A partir de agora, tenho um domínio do Google Domains e estou usando o cloudflare para meu gerenciamento de DNS. Não estou usando nenhum recurso TLS/SSL do cloudflare, o SSL universal está desativado e também não estou fazendo proxy de minhas solicitações de DNS. Eu uso caddy como meu proxy reverso em meu servidor e estou usando o cliente acme integrado que obtém certificados do letsencrypt. Estou recebendo certificados corretamente e todos os meus sites externos mostram o certificado que está sendo usado, que é o certificado localizado no meu servidor. No entanto, quando executo um curlcomando em meu servidor por HTTPS, recebo este comportamento estranho:

Para explicar mais, estou tentando enviar uma solicitação curl para meu servidor/instância gotify. Aqui está a saída quando eu uso o comando gotify cli, gotify initentão digito meu domínio com https:// e recebo esta saída (isso acontece com todos os meus domínios (quando executo os comandos curl básicos abaixo após o comando gotify), mas apenas usando gotify cli como exemplo de onde o erro se origina):

x509: certificate is not valid for any names, but wanted to match gotify.mydomain.com

Então, executo esses comandos curl para descobrir o que está acontecendo.

Comando: curl -v https://gotify.mydomain.com Saída:

* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self signed certificate
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Meu CApath contém literalmente todos os certificados do pacote ca-certificates. E meus sites externos estão usando meu certificado, mas meu servidor está com problemas e não sei por quê.

Quando executo este comando, curl -v --insecure https://gotify.mydomain.comobtenho resultados ainda mais estranhos: Saída:

* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=CN; ST=TW; L=TB; O=ASKEY; OU=ROUTER; CN=askey.com; [email protected]
*  start date: Jan  8 18:43:23 2022 GMT
*  expire date: Jan  7 18:43:23 2025 GMT
*  issuer: C=CN; ST=TW; L=TB; O=ASKEY; OU=ROUTER; CN=askey.com; [email protected]
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
> GET / HTTP/1.1
> Host: gotify.mydomain.com
> User-Agent: curl/7.74.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Location: /1.2.4/login.html
< Content-Length: 0
< Date: Sun, 24 Apr 2022 13:51:04 GMT
< Server: lighttpd/1.4.38
<
* Connection #0 to host gotify.mydomain.com left intact

Não tenho absolutamente nenhuma ideia de onde veio esse certificado "askey". Não está localizado em nenhum lugar do meu servidor AFAIK. Estou além de confuso. Estou localizado em Taiwan, então o código TW pode fazer um pouco de sentido. Eu nem tive acesso remoto ao meu servidor no dia 8 de janeiro, então não sei o que aconteceu.

Quando vejo isso Location: /1.2.4/login.html, fico pensando que algo está acontecendo com meu roteador. Porque esse é o caminho para a página de login do administrador do meu roteador.

informação relacionada