selftest http vs https

[jowy]

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:

time="2017-04-18T17:28:33Z" level=info msg="requesting certificate for foo.example.com" context="ingress_tls" name=<redacted> namespace=<redacted>
time="2017-04-18T17:29:59Z" level=warning msg="authorization failed after 1m0s: reachabily test failed: Get https://foo.example.com/.well-known/acme-challenge/_selftest: x509: certificate is valid for <redacted(this is my cluster's gateway)>, not foo.example.com" context=acme domain=foo.example.com
time="2017-04-18T17:29:59Z" level=error msg="Error while process certificate requests: no domain could be authorized successfully" context=kubelego

https appears to hit the default backend:

$ curl --insecure https://foo.example.com/.well-known/acme-challenge/_selftest
default backend - 404

http appears to work correctly:

$ curl http://foo.example.com/.well-known/acme-challenge/_selftest
SoMeExAmPlEToKeN

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.

[simonswine]

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

[jowy]

@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.

[jowy]

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.