HTTPS with public URL from Google pointed to local server

Help
1

1. Output of caddy version:

v2.5.1 h1:bAWwslD1jNeCzDa+jDCNwb8M3UJ2tPa8UZFFzPVmGKs=

2. How I run Caddy:

As a Windows service powered by WinSW

a. System environment:

Windows Server 2019 Datacenter

b. Command:

n/a

c. Service/unit/compose file:

n/a

d. My complete Caddy config:

ecgrowapi.com {
	handle_path /api* {
		reverse_proxy localhost:3001
	}

	handle {
		root * C:\Web\Webs\ExternalWeb
		encode gzip
		file_server
	}
}

#:3001 {
#	tls internal
#}

externalweb.local {
	#tls internal
	handle_path /api* {
		reverse_proxy localhost:3001
	}

	handle {
		root * C:\Web\Webs\ExternalWeb
		encode gzip
		file_server
	}
}

localhost {
	#tls internal
	handle_path /api* {
		reverse_proxy localhost:3001
	}

	handle {
		root * C:\Web\Webs\ExternalWeb
		file_server
	}
}

3. The problem I’m having:

I want to make our domain name secure, https. We have a domain name purchased through domains.google. We have the DNS set up with an A record pointed to the external IP of our network. Then we have port 3001 forwarding to our web server. So we can hit ecgrowapi.com:3001 and it correctly shows the status text for that web server. So that all works fine.

The problem happens when we hit https://ecgrowapi.com:3001. We get “Secure Connection Failed; Error code: SSL_ERROR_RX_RECORD_TOO_LONG”

I should mention that web server is locked down hard and in a DMZ, because it is public facing. It is using Google’s DNS for its DNS lookups.

4. Error messages and/or full log output:

Secure Connection Failed
An error occurred during a connection to ecgrowapi.com:3001. SSL received a record that exceeded the maximum permissible length.
Error code: SSL_ERROR_RX_RECORD_TOO_LONG
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the website owners to inform them of this problem.

Paste logs/commands/output here.
USE THE PREVIEW PANE TO MAKE SURE IT LOOKS NICELY FORMATTED.

5. What I already tried:

6. Links to relevant resources:

2

Hi :wave:

Redacting domain usually makes helping way more time intensive and more difficult.
If you absolutely have to redact a domain name, use example.com.
Just keep in mind, that domain names are public information.
Your domain is public, and any certificate issued for your domain (by a trusted CA that is) will be put in the public https://certificate.transparency.dev/

That being said, could you please provide some curl outputs?
E.g.

❯ curl -I https://example.com
HTTP/2 200 
content-encoding: gzip
accept-ranges: bytes
age: 479146
cache-control: max-age=604800
content-type: text/html; charset=UTF-8
date: Tue, 02 Aug 2022 16:12:41 GMT
etag: "3147526947"
expires: Tue, 09 Aug 2022 16:12:41 GMT
last-modified: Thu, 17 Oct 2019 07:18:26 GMT
server: ECS (mic/9AF8)
x-cache: HIT
content-length: 648
2 Likes
3

Thank you. I have modified my OP to add in the real domain name if it will help people figure this issue out. I will run those curl commands and reply back.

UPDATE:
Here are the results from the Curl command:
curl: (60) schannel: SNI or certificate check failed: SEC_E_WRONG_PRINCIPAL (0x80090322) - The target principal name is incorrect.More details here: https://curl.se/docs/sslcerts.htmlcurl failed to verify the legitimacy of the server and therefore could notestablish a secure connection to it. To learn more about this situation andhow to fix it, please visit the web page mentioned above.

2 Likes
4

Thank you :slight_smile:

Okay, so I did some additional against tests against your domain real quick, but some things just don’t add up:

  • The curl fails, because the certificate is for the wrong domain (avaya.ecgrow.com) by GoDaddy.com.
  • Your port :80 doesn’t seem to be open. Consider opening that, so caddy will automatically redirect from http:// to https://
  • Caddy sends a header with server: Caddy by default, which it currently doesn’t for your domain
  • The TLS ciphers offered by your domain aren’t those Caddy would send by default, further corroborate the assertion Caddy isn’t actually serving your domain

Are you sure Caddy is actually running on that IP on that server?

PS: This won’t have anything to with your actual problem, but please update Caddy from v2.5.1 to v2.5.2 (released 21 days ago)

2 Likes
5

Our Avaya phone system is sitting on the main external IP address. We have ecgrowapi.com:3001 coming in and forwarding to our web server. I will have to look into how to open up port 80. Will that cause any security concerns? I know my boss doesn’t like to open up any unnecessary ports.

6

Uhm, okay :sweat_smile:
This smells a bit like a XY problem.

What are you actually trying to do?
Are you trying to have ecgrowapi.com:3001 available over https://, reverse proxied by caddy?

You are currently running that service on :3001, which handles http:// connections but no https://
In order to use https://ecgrowapi.com:3001, you would have to run Caddy on :3001, which reverse proxies to that service currently running on :3001.

You would have to change that port (either have Caddy or your service listen on another port), because you can’t have two processes listing on the same tcp port.

And then there is the actual certificate issuing.
ACME challenges over http require port :80 or :443 open. There is no way to change that.

So to have a valid and publically trusted tls certificate issued by Caddy and automatically renewed, you would have to have those ports open and routed to caddy.
Alternatively, you could either use self-signed certificates (tls internal, see tls (Caddyfile directive) — Caddy Documentation), which won’t be trusted by your browser (by default) or use the DNS challenge, which is generally speaking more effort.

Consider reading (or at least skimming) through Automatic HTTPS — Caddy Documentation

You could also look into reverse proxying your Avaya phone system (?) by Caddy.
If you have Caddy listing on :80 and :443, then you could also very easily use https://ecgrowapi.com instead of https://ecgrowapi.com:3001.

3 Likes
7

Thank you! That is a lot of super helpful info. I was stuck and didn’t even know where to begin.

What are you actually trying to do?
Are you trying to have ecgrowapi.com:3001 available over https://, reverse proxied by caddy?

Yes, that sounds exactly like what I am trying to do.

You would have to change that port (either have Caddy or your service listen on another port), because you can’t have two processes listing on the same tcp port.

I can change either, but I think changing the port for the service might be easier, so I will try to go that route.

So to have a valid and publically trusted tls certificate issued by Caddy and automatically renewed, you would have to have those ports open and routed to caddy.

Are you saying I only need to have one of those ports open? Either 80 or 443, it doesn’t matter which one?

Consider reading (or at least skimming) through Automatic HTTPS — Caddy Documentation

I’ve looked through that, I will read through it again to see if I can gather some more knowledge.

You could also look into reverse proxying your Avaya phone system (?) by Caddy.
If you have Caddy listing on :80 and :443, then you could also very easily use https://ecgrowapi.com instead of https://ecgrowapi.com:3001.

That sounds like a good option too. I will look into if that is feasible or not.

1 Like
8

So reading through the requirements on that site, it sounds to me like both ports need to be open.

image
image806Ă—339 30.2 KB

So my other question is: do I need to open those ports on the outside device where the IP address is. Or do I need to open then on our web server where :3001 is pointing to?

9

They need to be open to the outside. You can route/forward packets from those ports to any other port you want anywhere else. But you have to open 80 and 443 to the public.

1 Like
10

@emilylange Can you give me some details on how you were able to determine that port 80 is not open for our network? I’m trying to figure that stuff out.
Thanks

11

You could for example use curl http://ecgrowapi.com -v (or curl http://ecgrowapi.com) since you already seem to have curl installed judging from one of the earlier posts in that topic :slight_smile:

I currently get a Connection refused for you.
But you could also just have that port correctly opened/forwarded with just nothing listening on your server on port :80.
It really depends on how your firewall looks like.
Just be sure you have that port open and caddy started :innocent:

1 Like
12

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