Letsencrypt webroot verification follows http to https redirect for self-signed cert?

Issuance Tech
1

With my acmetool.sh integration I auto generate the nginx vhost and then use @Neilpang’s acme.sh to issue letsencrypt ssl cert via webroot authentication.

But one of the options i have is to generate nginx vhost with https default so i redirect http to https. But i generate a https vhost with self-signed ssl cert first as a placeholder and then when acme.sh gets letsencrypt ssl certificate, i swap out the self-signed ssl cert for letsencrypt ssl cert. If letsencrypt verification fails, it automatically falls back to the self-signed ssl placeholder certs.

This works fine for non-https default issuances. But seems i ran into problem for http to https default redirects. The acme.sh and letsencrypt are reporting failure to connect to domain and i suspect it’s because letsencrypt doesn’t see my placeholder https default self-signed cert as valid ?

== Info: Connection #0 to host domain.com left intact
== Info: Issue another request to this URL: 'https://domain.com/.well-known/acme-challenge/MP7ezQ6O3BO9CJjpeyQh_j_gTDeyXhOP7c3xBT9S5_o'
== Info: About to connect() to domain.com port 443 (#1)
== Info:   Trying IPADDRESS... == Info: connected
== Info: Connected to domain.com (IPADDRESS) port 443 (#1)
== Info: Initializing NSS with certpath: sql:/etc/pki/nssdb
== Info:   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
== Info: Certificate is signed by an untrusted issuer: 'CN=domain.com,OU=domain.com,O=domain.com,L=Los Angeles,ST=California,C=US'
== Info: NSS error -8172
== Info: Closing connection #1
== Info: Peer certificate cannot be authenticated with known CA certificates
== Info: Closing connection #0
[Sat Sep 17 00:16:22 UTC 2016] ret='60'
[Sat Sep 17 00:16:22 UTC 2016] Debugging, skip removing: /home/nginx/domains/domain.com/public/.well-known
[Sat Sep 17 00:16:22 UTC 2016] pid
LECHECK = 1
2

Hi.
I suggest you add a rewrite rule that the .well-known folder is not redirected.

1 Like
3

Thanks @Neilpang but that would work for initial issuance but renewals would fail then for https defaults ? i am going to try just disabling https redirect until after verification

4

I think you should add a permanent rule to nginx conf, that .well-known folder never get redirected.

On other hand, if you want some preparation before renewing, you should try --pre–hook .

1 Like
5

This looks like it’s caused by the client rather than the CA server. Let’s Encrypt will happily accept self-signed, expired or otherwise invalid certificates for HTTPS redirects when using http-01 as long as they’re not weird enough to cause Go’s X509 library to choke (and the cipher suite is compatible).

1 Like
6

@pfg that’s good news that letsencrypt will accept self-signed ssl certs…

the problem for my end user seems to only occur if site domain is behind cloudflare though - actual user post at https://community.centminmod.com/posts/36339/ ? I thought webroot authentication wouldn’t have issues with cloudflare

@Neilpang thanks, here’s the actual full debug log of the end users run https://gist.github.com/dyrer/187f7ab5e7e9b5fea9cae5e165fecd42 for further clues

7

I read the log. Please ignore the last a few ssl connection error. It’s just for debugging. I may hide the them later. It’s useless to you.

1 Like
8

ok good to know…

just noticed in the log curl error 60 reported, could it be due to system CA-bundle being out of date ? curl 60 error which is from https://curl.haxx.se/libcurl/c/libcurl-errors.html

[QUOTE]CURLE_SSL_CACERT (60)

Peer certificate cannot be authenticated with known CA certificates.[/QUOTE]

might need to add a check in my acmetool.sh for system ca-certificates updates available

or that is related to self-signed ssl cert curl’d

9

From the log, the ca server reported : could not connect to your server.

It might be a connection problem.

10

No. just ignore the ssl error.
It nothing to do with this issue.

11

yeah that’s what i suspect though there’s not much more details on why

user says issue only happens behind cloudflare

12

I’m not at home now, I could have a try in a few hours when I get home.

1 Like
13

I did some testing and I’m pretty sure that - based on the error details - this is unrelated to the redirect and rather a general connectivity error on port 80. The log contains this:

[Sat Sep 17 00:16:22 UTC 2016] original='{
  "type": "http-01",
  "status": "invalid",
  "error": {
    "type": "urn:acme:error:connection",
    "detail": "Could not connect to armysafety.info",
    "status": 400
  },
  "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/5qI-SyoNDNvO5e4H6M-nN7ogN1IBDNYmQujekSSkrnU/266452464",
  "token": "MP7ezQ6O3BO9CJjpeyQh_j_gTDeyXhOP7c3xBT9S5_o",
  "keyAuthorization": "MP7ezQ6O3BO9CJjpeyQh_j_gTDeyXhOP7c3xBT9S5_o.2ynN5DtCYMsYQVKhquXhdTOF928k2D4m80WFqUN1J7U",
  "validationRecord": [
    {
      "url": "http://armysafety.info/.well-known/acme-challenge/MP7ezQ6O3BO9CJjpeyQh_j_gTDeyXhOP7c3xBT9S5_o",
      "hostname": "armysafety.info",
      "port": "80",
      "addressesResolved": [
        "104.27.133.137",
        "104.27.132.137"
      ],
      "addressUsed": "104.27.133.137"
    }
  ]
}'

Note the port being 80.

This is the log output when Let’s Encrypt fails to follow a HTTPS redirect to a non-functioning HTTPS server (I’m simply not listening on port 443):

    "validationRecord": [
        {
          "url": "http://debug.le.pf.vc/.well-known/acme-challenge/oR7jNUh2xk5E4nXKM_8VAtj374_MakE8M-M-1ivZV2c",
          "hostname": "debug.le.pf.vc",
          "port": "80",
          "addressesResolved": [
            "146.185.148.60"
          ],
          "addressUsed": "146.185.148.60"
        },
        {
          "url": "https://debug.le.pf.vc/.well-known/acme-challenge/oR7jNUh2xk5E4nXKM_8VAtj374_MakE8M-M-1ivZV2c",
          "hostname": "debug.le.pf.vc",
          "port": "443",
          "addressesResolved": [
            "146.185.148.60"
          ],
          "addressUsed": "146.185.148.60"
        }
      ]
```
Note the second validation record mentioning port 443.

Not entirely sure why the connection to CloudFlare is failing. Maybe some weird page rule (or something similar)?

FWIW, I can report that I've been using webroot (including a HTTPS redirect) on a CloudFlare-enabled domain successfully for quite some time.
1 Like
14

cheers @pfg thanks for the confirmation and insight - could be something in my nginx vhost setups that are generated too :slight_smile:

15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.