Sper că cineva poate ajuta să explice ce se întâmplă în această situație..
De acum, am un domeniu din domeniile Google și folosesc cloudflare pentru gestionarea mea DNS. Nu folosesc nicio caracteristică TLS/SSL de la cloudflare, SSL universal este dezactivat și nici nu îmi fac proxy solicitările DNS. Folosesc caddy ca proxy invers pe serverul meu și folosesc clientul acme încorporat care primește certificate de la letsencrypt. Primesc certificate bine și site-urile mele externe arată toate certificatul utilizat, care este certificatul situat pe serverul meu. Totuși, când conduc un răsuci comandă pe serverul meu prin HTTPS, primesc acest comportament ciudat:
Pentru a explica mai multe, încerc să trimit o cerere curl către serverul/instanța mea gotify. Iată rezultatul când folosesc comanda gotify cli gotify init apoi introduc domeniul meu cu https:// și primesc această ieșire (acest lucru se întâmplă pentru toate domeniile mele (când rulez comenzile curl de bază de mai jos după comanda gotify), dar folosind doar gotify cli ca exemplu de eroare Provin din):
x509: certificatul nu este valabil pentru niciun nume, dar a vrut să se potrivească cu gotify.mydomain.com
Deci, rulez aceste comenzi curl pentru a-mi da seama ce se întâmplă.
Comanda: curl -v https://gotify.mydomain.com
Ieșire:
* ALPN, oferind h2
* ALPN, oferind http/1.1
* setați cu succes locațiile de verificare a certificatelor:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (OUT), strângere de mână TLS, salut client (1):
* TLSv1.3 (IN), strângere de mână TLS, salut server (2):
* TLSv1.2 (IN), strângere de mână TLS, Certificat (11):
* TLSv1.2 (OUT), alertă TLS, CA necunoscută (560):
* Problemă cu certificatul SSL: certificat autosemnat
* Închiderea conexiunii 0
curl: (60) Problemă cu certificatul SSL: certificat autosemnat
Mai multe detalii aici: https://curl.se/docs/sslcerts.html
curl nu a reușit să verifice legitimitatea serverului și, prin urmare, nu a putut
stabiliți o conexiune sigură cu acesta. Pentru a afla mai multe despre această situație și
cum să o remediați, vă rugăm să vizitați pagina web menționată mai sus.
My CApath literalmente are toate certificatele din pachetul ca-certificates. Și site-urile mele externe folosesc certificatul meu, dar serverul meu are probleme și nu știu de ce.
Când rulez această comandă curl -v --insecure https://gotify.mydomain.com Obțin rezultate și mai ciudate:
Ieșire:
* ALPN, oferind h2
* ALPN, oferind http/1.1
* setați cu succes locațiile de verificare a certificatelor:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (OUT), strângere de mână TLS, salut client (1):
* TLSv1.3 (IN), strângere de mână TLS, salut server (2):
* TLSv1.2 (IN), strângere de mână TLS, Certificat (11):
* TLSv1.2 (IN), strângere de mână TLS, schimb de chei de server (12):
* TLSv1.2 (IN), TLS handshake, Server terminat (14):
* TLSv1.2 (OUT), TLS handshake, Schimb cheie client (16):
* TLSv1.2 (OUT), TLS schimbă cifra, Schimbă specificația cifrului (1):
* TLSv1.2 (OUT), TLS handshake, Terminat (20):
* TLSv1.2 (IN), strângere de mână TLS, Terminat (20):
* Conexiune SSL folosind TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, serverul nu a fost de acord cu un protocol
* Certificat de server:
* subiect: C=CN; ST=TW; L=TB; O=ASKEY; OU=ROUTER; CN=askey.com; [email protected]
* data începerii: 8 ianuarie 18:43:23 2022 GMT
* data expirării: 7 ianuarie 18:43:23 2025 GMT
* emitent: C=CN; ST=TW; L=TB; O=ASKEY; OU=ROUTER; CN=askey.com; [email protected]
* Rezultatul verificării certificatului SSL: certificat autosemnat (18), continuând oricum.
> GET / HTTP/1.1
> Gazdă: gotify.mydomain.com
> User-Agent: curl/7.74.0
> Accept: */*
>
* Marcați pachetul ca nu acceptă mai multe utilizări
< HTTP/1.1 302 Găsit
< Locație: /1.2.4/login.html
< Lungimea conținutului: 0
< Data: duminică, 24 apr 2022 13:51:04 GMT
< Server: lighttpd/1.4.38
<
* Conexiunea #0 la găzduirea gotify.mydomain.com a rămas intactă
Habar n-ai de unde a venit acest certificat „askey”. Nu se află nicăieri pe serverul meu AFAIK. Sunt dincolo de confuz. Sunt situat în Taiwan, așa că codul TW ar putea avea puțin sens. Nici măcar nu am avut acces la serverul meu de la distanță pe 8 ianuarie, așa că nu știu ce s-a întâmplat.
Când văd asta Locație: /1.2.4/login.html asta mă face să cred că se întâmplă ceva cu routerul meu. Pentru că aceasta este calea pentru pagina mea de conectare a administratorului routerului.
