I guess I am not sure what the service does exactly to retrieve the token. Since the challenge is accessible it leads me to think the service first test the root page first to make sure? In that case, it would run into a self-signed cert. Maybe that is the issue?
Because the ingress is not getting a host name? could this be a factor? again on the let’s encypt side I don’t fully understand how it is requesting the token file.
It's a normal file fetched from a website. This isn't mysterious.
But:
Why isn't there a redirect, but my online tool sees such a redirect http -> https?
And: The redirect isn't relevant if http and https use the same DocumentRoot.
But if http and https have different DocumentRoots, this is a critical problem. Then one version sees the file with the challenge token, the other version sees nothing.
I just turned the force redirect off in ingress to see if that helps.
As far as I under stand it cert-manger appends a virtual host and path to the ingress object that will server the token, in my case:
host: peterson-house.family
path: “/.well-known/acme-challenge/SDsVqyqBImtzQ22yuaOL8r_8brznNb9uzevf3CvO5-s”
The main ingress object contains virtual host for peterson-house.family, blog.peterson-house.family, and a default backend which points to the same kubernetes service has peterson-house.family, an simple apache server.
when the ip is used instead of the host name I believe the default backend is being triggered, and there is no token there to be served.
That is why I was asking how does let’s encrypt request the file. If it does in fact not use the host name this ingress will not work.
But I am following the Cert-manger guide to the ‘T’ so I feel like this should not be the problem?
Thanks for all the help so far. I will keep plugging away at the ingress I guess, and try and do some digging on the redirects. After turning the force redirects off I seem to be getting some errors on that tool you used to review my domain regarding redirects.
Hosted DNS -> PFSense Firewall -> HAproxy loadbalancer (on pfsense) -> kubernetes nodeport proxy -> Ingress -> kubernetes service
DNS is ok
Firewall ok: port 80 and 443 open for traffic directed to HAproxy
HAproxy forwards traffic 80->30400/443->304001 on kube proxy (door to the cluster services)
Kubernetes Proxy running all the nodes directs traffic to ingress back on ports 80 and 443 respectively
ingress then connects to the services on defined ports
The following post says initial connection and all redirects must be on ports 80 and 443. Could my load balancing and proxy networks for the cluster be the issue since traffic leaves port 80 and 443?
