Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow self-hosting to listen to another port than 80 #742

Closed
varzaman opened this issue Feb 10, 2018 · 11 comments
Closed

Allow self-hosting to listen to another port than 80 #742

varzaman opened this issue Feb 10, 2018 · 11 comments
Labels
enhancement

Comments

@varzaman
Copy link

varzaman commented Feb 10, 2018 •
edited

Issue description

Validation fails with a 403 error when using the selfhost method.

 1: [tls-sni-01] Use IIS as endpoint
 2: [dns-01] Azure DNS
 3: [dns-01] Run external program/script to create and update records
 4: [http-01] Create temporary application in IIS
 5: [http-01] Save file on local (network) path
 6: [http-01] Self-host verification files (recommended)
 C: Cancel

Using option 5 in the above does work however.

Steps to reproduce

Client version: 1.9.8.4
Windows version: Windows Server 2016
Relevant part of log file:

  1. M: Create new certificate with advanced options
  2. 1: Single binding of an IIS site
  3. 1: fundraising4dollars.com (SiteId 12) [@C:\Sites\DSG]
  4. 6: [http-01] Self-host verification files (recommended)
  5. 1: Create or update IIS bindings
  6. Would you like to add another installer step? (y/n): - no
  7. Use different site for installation? (y/n): - no

The above fails.

This is the response I get back when using the selfhost validation method.

{
  "identifier": {
    "type": "dns",
    "value": "fundraisingfordollars.com"
  },
  "status": "invalid",
  "expires": "2018-02-17T19:13:16Z",
  "challenges": [
    {
      "type": "http-01",
      "status": "invalid",
      "error": {
        "type": "urn:acme:error:unauthorized",
        "detail": "Invalid response from http://fundraisingfordollars.com/.well-known/acme-challenge/6CBqJoUNBn39AvkyEeOJmMcGq95Aw1e0LKb-yMh6KoI: \"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\"\u003e\r\n\u003chtml xmlns=\"http\"",
        "status": 403
      },
      "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/7sab7fvjoH4UNzXaj5MNOaBp5jLvkkDgjUXDGliVes4/100180737",
      "token": "6CBqJoUNBn39AvkyEeOJmMcGq95Aw1e0LKb-yMh6KoI",
      "keyAuthorization": "6CBqJoUNBn39AvkyEeOJmMcGq95Aw1e0LKb-yMh6KoI.xzfMfcLhWAf5VpUvuxE3y4OhLp1qdVQHPU0ka_LWenA",
      "validationRecord": [
        {
          "url": "http://fundraisingfordollars.com/.well-known/acme-challenge/6CBqJoUNBn39AvkyEeOJmMcGq95Aw1e0LKb-yMh6KoI",
          "hostname": "fundraisingfordollars.com",
          "port": "80",
          "addressesResolved": [
            "206.210.72.5"
          ],
          "addressUsed": "206.210.72.5"
        }
      ]
    },
    {
      "type": "dns-01",
      "status": "pending",
      "uri": "https://acme-staging.api.letsencrypt.org/acme/challenge/7sab7fvjoH4UNzXaj5MNOaBp5jLvkkDgjUXDGliVes4/100180738",
      "token": "JGB8aIsDMPeE1MfoV-NAaKfyNGY8AC74Bom-0RkyRIQ"
    }
  ],
  "combinations": [
    [
      0
    ],
    [
      1
    ]
  ]
}

 [EROR] Authorization result: invalid
 [DBUG] Deleting web.config
 [DBUG] Deleting answer
 [EROR] ACME server reported:
 [EROR] [type] urn:acme:error:unauthorized
 [EROR] [detail] Invalid response from http://fundraisingfordollars.com/.well-known/acme-challenge/oW_DPSvqzz243O3a0NwVLpPqFg_MQkI5iRUfcosOyzE: "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http"
 [EROR] [status] 403
 [EROR] Create certificate failed

However, if I change step 4 to use 5: [http-01] Save file on local (network) path the process works.

I would rather use self host validation however. What would cause this discrepancy?

Other information: The host allows for all incoming traffic on port 80. We have an internal NAT routing table that takes in requests from specific ips and routes them to internal ports, but that's it.

The site is hosted in IIS 10.
@WouterTinus
Copy link
Member

Self-hosting validation is hard-coded to port 80, which works in the vast majority of cases because Let's Encrypt is hard-coded to port 80 as well. But if http traffic is internally redirected to another port then it falls apart.

Honestly it's not the first time that I've heard from someone with this kind of setup, so I think it's time to add some way to configure it to listen to another port.

@WouterTinus WouterTinus changed the title Can't get validation working with Self-host verification, but works with save file on local network path Allow self-hosting to listen to another port than 80 Feb 11, 2018
WouterTinus added a commit that referenced this issue Feb 12, 2018
@WouterTinus
#742
6f665a2
@varzaman
Copy link
Author

Ah, thank you for the explanation. That makes sense.

@WouterTinus
Copy link
Member

The latest release contains a new parameter --validationport to support listening to other ports besides 80.

@b-rewired
Copy link

By a strange coincidence, I was having the same issue this morning and I came back to this thread to see that you, @WouterTinus , had added the new parameter.

I'm having an issue with it though, I'm launching the executable with --validationport 88 parameter but my attempts to get a cert fail. I've verified that my site is reachable through it's host and port externally so it's not a firewall/routing issue.

I haven't dug into the source code but when the output says: "Answer should now be browsable at [followed with url]" - the port number (88) is not in the URL. Should it be?

Do you want me to open a new issue for this?

@LBegnaud
Copy link
Collaborator

let's encrypt will only ever hit port 80 for http-01 validation.

changing the local port is only useful if you are doing NAT on external port 80 to whatever internal port you specify (port 88 in this case).

@b-rewired
Copy link

Thanks, @LBegnaud , for the quick response. I think, then, I'm stuck. My residential ISP blocks port 80 so I was trying to work around this by hosting on a different port (and routing the firewall traffic all through the same port).

Based on your knowledge of LetsEncrypt and win-acme, is this something that can be overcome? Does LetsEncrypt only look at port 80 or is it win-acme that is hardcoded to do the validation on port 80?

@LBegnaud
Copy link
Collaborator

If you need too much more information, i would suggest creating a fresh issue so we can discuss. But the wiki has information about your options with this tool. Specifically, the validation methods. If you can't get port 80 inbound, then your only option I believe is DNS script validation. Honestly I would recommend working with your isp to unblock port 80. That restriction seems arbitrary.

@WouterTinus
Copy link
Member

Can confirm what @LBegnaud said, the ACME protocol specifies port 80 as a MUST for http validation, this new switch will only work for NAT setups.

Since tls validation is disabled, your only other alternative right now is dns validation.

@b-rewired
Copy link

Thank you for pointing me in the right direction. As for the ISP, I agree with you - they've had it this way for 20 years now, I don't see them changing and they'll likely want to upsell me some business package.

@LBegnaud
Copy link
Collaborator

not to draw this out, but I think you may be able to use https://www.cloudflare.com/plans/ for anything simple you're trying to do.

@b-rewired
Copy link

b-rewired commented Feb 23, 2018 •
edited

Honestly, this was just an exercise in learning LetsEncrypt with IIS on a Windows 2012 R2 virtual machine. I wanted to be able have a nicer looking TLS encryption, rather than a self-signed certificate, for a custom application I'm exposing externally.

Thanks for the info on Cloudflare hosting - good to know they have a free tier for blogs and personal sites. I'm not using Azure for this so if I figure out how to use the DNS-01 validation technique for IIS I can post back here.

Edit: Well it appears that I won't be able to do this, unless I use Azure or switch my DNS provider to someone who supports script-creation of the TXT records.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@varzaman @b-rewired @WouterTinus @LBegnaud