Puncte:0

ns-cloud-e2.googledomains.com returnează REFUZAT

drapel ae

Am încercat să implementez HTTPS pe un cluster Kubernetes pe Google Cloud Platform. Nu pot înțelege ce altceva trebuie să verific sau să caut. Folosesc un certificat Google Managed.

ieșire săpată

; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> demo.abhikube.tk
;; opțiuni globale: +cmd
;; Am răspuns:
;; ->>HEADER<<- opcode: QUERY, stare: NOERROR, id: 59409
;; steaguri: qr rd ra; ÎNTREBARE: 1, RĂSPUNS: 1, AUTORITATE: 0, SUPLIMENTARE: 1

;; PSEUDOSECȚIE OPT:
; EDNS: versiunea: 0, steaguri:; udp: 512
;; SECȚIUNEA DE ÎNTREBĂRI:
;demo.abhikube.tk. ÎN A

;; SECȚIUNEA RĂSPUNSURI:
demo.abhikube.tk. 300 IN A 35.190.47.137

;; Timp de interogare: 47 ms
;; SERVER: 169.254.169.254#53(169.254.169.254)
;; CÂND: Duminica, 12 septembrie 10:00:45 UTC 2021
;; MSG SIZE rcvd: 61

Comanda:- openssl s_client -connect demo.abhikube.tk:443 -tls1_2

CONECTAT(00000003)
scrie:errno=0
---
nu este disponibil niciun certificat de egalitate
---
Nu s-au trimis nume de CA de certificat de client
---
Handshake SSL a citit 0 octeți și a scris 213 octeți
Verificare: OK
---
Nou, (NONE), Cifrul este (NIMIC)
Renegocierea sigură NU ESTE acceptată
Compresie: NIMIC
Extindere: NIMIC
Nu s-a negociat ALPN
Sesiune SSL:
    Protocol: TLSv1.2
    Cifrare: 0000
    Sesiune ID:
    ID-ul sesiunii-ctx:
    Cheia principala:
    Identitate PSK: Niciuna
    Sugestie de identitate PSK: Niciuna
    Nume de utilizator SRP: niciunul
    Ora de începere: 1631440972
    Timeout: 7200 (sec)
    Verificați codul de retur: 0 (ok)
    Secret principal extins: nu

Am încercat de mai multe ori, dar Google continuă să afișeze starea certificatului ca FailedNotVisible. Ce altceva pot face pentru a remedia asta? Nu sunt expert în ssl. Documentul Google a spus că dacă returnarea de verificare este ok, ar trebui să funcționeze... dar nu. Versiunea HTTP funcționează bine.

Am făcut o verificare https://dnssec-analyzer.verisignlabs.com/..it spectacole

Nu s-au găsit înregistrări DS pentru abhikube.tk în zona tk
    ns-cloud-e2.googledomains.com returnează REFUS pentru abhikube.tk/DNSKEY
    ns-cloud-e4.googledomains.com returnează REFUS pentru abhikube.tk/DNSKEY
    ns-cloud-e3.googledomains.com returnează REFUS pentru abhikube.tk/DNSKEY
    ns-cloud-e1.googledomains.com returnează REFUS pentru abhikube.tk/DNSKEY
drapel cn
Nu știu despre certificatul gestionat de Google (se pare că acele probleme sunt legate), dar numele de domeniu la care se face referire în întrebare nu pare să aibă nicio zonă corespunzătoare pe serverele de nume, de unde răspunsul `REFUSAT` la interogările DNS. Vezi de exemplu https://dnsviz.net/d/abhikube.tk/YT3hxw/dnssec/
Abhishek Rai avatar
drapel ae
Cred că acesta fiind un domeniu gratuit configurat pe freenom.com este motivul pentru care certificatul `ssl` eșuează. Nu am altă modalitate de a verifica acest lucru pe kubernetes. Ei bine, cred că va trebui să renunț la asta și să cumpăr un domeniu.
drapel cn
Numele nu se rezolvă deoarece `abhikube.tk` este delegat la `ns-cloud-e1.googledomains.com` (etc), dar acele servere de nume nu au nicio zonă corespunzătoare. Se pare că „failed not visible” are legătură cu numele care nu se rezolvă: https://cloud.google.com/load-balancing/docs/ssl-certificates/troubleshooting
Abhishek Rai avatar
drapel ae
Am creat o zonă acolo. `demo.abhikube.tk` . Aceasta este zona care se mapează la IP-ul static în echilibrul de încărcare. Deci nu știu ce lipsește din acel capăt.
Puncte:1
drapel cn
  • Asigurați-vă că ați finalizat Configurarea DNSSEC la registratorul dvs, puteți face acest lucru creând o înregistrare DS pentru domeniul dvs. în zona părinte, astfel încât rezolutorii să știe că domeniul dvs. este activat pentru DNSSEC și să își poată valida datele.
  • Actualizați ambele înregistrări DNS A și AAAA pentru a indica adresa IP a echilibratorului de încărcare, verificați Aici pentru ajutor.
  • Asigurați-vă că nu ați ratat niciun pas menționat Aici în timp ce furnizați certificate SSL gestionate de Google și atașați certificatele dvs. pentru a corecta echilibrul de încărcare.
Abhishek Rai avatar
drapel ae
Asta a fost. Din păcate, nu pot face asta, deoarece Freenom nu acceptă DNSSEC ca registrator. Raspunsul tau este corect...desi.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.