Score:0

ns-cloud-e2.googledomains.com returns REFUSED

ae flag

I have been trying to implement HTTPS on a kubernetes cluster on Google Cloud Platform. I cannot understand what else I need to check or look for. I am using a Google Managed certificate.

dig output

; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> demo.abhikube.tk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59409
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;demo.abhikube.tk.              IN      A

;; ANSWER SECTION:
demo.abhikube.tk.       300     IN      A       35.190.47.137

;; Query time: 47 msec
;; SERVER: 169.254.169.254#53(169.254.169.254)
;; WHEN: Sun Sep 12 10:00:45 UTC 2021
;; MSG SIZE  rcvd: 61

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

CONNECTED(00000003)
write:errno=0
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 213 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1631440972
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no

I have tried multiple times but Google keeps showing certificate status as FailedNotVisible. What else can I do to fix this? I am not an expert on ssl. Google doc said if the verify return is ok it should work..but it doesn't. The HTTP version works fine.

I ran a check on https://dnssec-analyzer.verisignlabs.com/..it shows

No DS records found for abhikube.tk in the tk zone
    ns-cloud-e2.googledomains.com returns REFUSED for abhikube.tk/DNSKEY
    ns-cloud-e4.googledomains.com returns REFUSED for abhikube.tk/DNSKEY
    ns-cloud-e3.googledomains.com returns REFUSED for abhikube.tk/DNSKEY
    ns-cloud-e1.googledomains.com returns REFUSED for abhikube.tk/DNSKEY
cn flag
I don't know about the Google managed certificate (those problems seem likely to be related), but the domain name referenced in the question does not seem to have any corresponding zone on the nameservers, hence the `REFUSED` response to DNS queries. See eg https://dnsviz.net/d/abhikube.tk/YT3hxw/dnssec/
Abhishek Rai avatar
ae flag
I think this being a free domain set up on freenom.com is the reason why `ssl` certificate fails. I have no other way to verify this on kubernetes. Well, I guess I will have to give this up and buy a domain.
cn flag
The name does not resolve because `abhikube.tk` is delegated to `ns-cloud-e1.googledomains.com` (etc) but those nameservers have no corresponding zone. It seems that "failed not visible" is related to the name not resolving: https://cloud.google.com/load-balancing/docs/ssl-certificates/troubleshooting
Abhishek Rai avatar
ae flag
I have created a zone there. `demo.abhikube.tk` . That is the zone which maps to the static IP in the load balancer. So I don't know what is missing from that end.
Score:1
cn flag
  • Make sure that you’ve completed the DNSSEC setup at your registrar, you can do this by creating a DS record for your domain in the parent zone, so that resolvers know your domain is DNSSEC-enabled and can validate its data.
  • Update your both DNS A and AAAA records to point to the load balancer's IP address, check here for help.
  • Ensure that you didn’t miss any step mentioned here while provisioning Google managed SSL certificates and attached your certificates to correct load balancer.
Abhishek Rai avatar
ae flag
This was it. Unfortunately I cannot do that because Freenom doesn't support DNSSEC as registrar. Your answer is correct..though.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.