Closed jowy closed 7 years ago
Not too sure why the authorization call (which is calling from Let's Encrypt's backend) is hitting the https endpoint.
Maybe they are respecting some TLS related http headers? Can you give me this output:
$ curl -v http://foo.example.com/.well-known/acme-challenge/_selftest
@simonswine I thought the same thing, HSTS or something... doesn't appear to be the case 😢 👍
$ curl -v http://foo.example.com/.well-known/acme-challenge/_selftest
* Trying x.x.x.x...
* TCP_NODELAY set
* Connected to foo.example.com (x.x.x.x) port 80 (#0)
> GET /.well-known/acme-challenge/_selftest HTTP/1.1
> Host: foo.example.com
> User-Agent: curl/7.50.3
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.11.10
< Date: Tue, 18 Apr 2017 19:27:50 GMT
< Content-Type: text/plain
< Content-Length: 16
< Connection: keep-alive
<
* Curl_http_done: called premature == 0
* Connection #0 to host foo.example.com left intact
SoMeExAmPlEToKeN
Edit:
Not too sure why the authorization call (which is calling from Let's Encrypt's backend) is hitting the https endpoint.
The call to _selftest is being made internally from the mentioned function here: 0.1.3/pkg/acme/cert_request.go#L48, which is done prior to any call made to Let's Encrypt in order to validate the endpoint. This is what is failing.
Actually, it seems to be an issue with NAT reflection... When I make the curl request on VPN to the cluster, the response contains HSTS headers and is from my gateway... Can consider closed. Thanks @simonswine for bouncing ideas.
Looking at 0.1.3/pkg/acme/cert_request.go#L48, it appears the selftest url scheme is forced to
http
, however my logs show otherwise:https
appears to hit the default backend:http
appears to work correctly:Aside from adding this new ingress resource, nothing has changed about the cluster following the configuration of the last ingress resource. All other
tls-acme
ingress resources are properly being handled by kube-lego.