Ubuntu 22.04 Reverse_poxy error:0A00010B:SSL routines::wrong version number

1. The problem I’m having:

Hi people
I need your help with caddy server reverse proxy

For example

Caddy installed on server Ubuntu 22.04 IP- 10.0.0.5

between this ip 100.100.50.50 installed vpn tunnel

and in this server hosts file inputted

100.100.50.50 someservice.com
100.100.50.50 someservice2.com

In my windows machine
hosts file inputted this IP Ubuntu server

10.0.0.5 someservice.com
10.0.0.5 someservice2.com

I try post via insomnia and get this error

2. Error messages and/or full log output:

 * Preparing request to https://someservice.com:9444/oauth2/token
* Current time is 2023-07-06T11:25:18.425Z
* Enable automatic URL encoding
* Using default HTTP version
* Enable SSL validation
* Too old connection (1128 seconds), disconnect it
* Connection 28 seems to be dead!
* Closing connection 28
* Hostname in DNS cache was stale, zapped
* Trying 10.0.0.5:9444...
* Connected to someservice.com (10.0.0.5) port 9444 (#30)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* (5454) (IN), , Unknown (72):
*error:0A00010B:SSL routines::wrong version number
* Closing connection 30 

3. Caddy version:

2.6.4 version

d. My complete Caddy config:

:8243 {
          reverse_proxy 100.100.50.50:8243
         }

:9444 {
        reverse_proxy 100.100.50.50:9444
}

You haven’t given Caddy a domain name, so it doesn’t know how to issue a certificate. It needs a domain to do that. So it’s just listening for HTTP requests, not HTTPS.

Please explain little more…
Where I should set domain name?

like this

someservice2.com:8243 {
          reverse_proxy 100.100.50.50:8243
         }

someservice.com:9444 {
        reverse_proxy 100.100.50.50:9444
}

or
like this

:8243 {
          reverse_proxy https://someservice2.com:8243
         }

:9444 {
        reverse_proxy https://someservice.com:9444
}

I try both but doesn’t work

Thanks advance

Like this:

someservice2.com {
	reverse_proxy 100.100.50.50:8243
}

someservice.com {
	reverse_proxy 100.100.50.50:9444
}

Make sure your server is publicly accessible on ports 80 and 443. Caddy will attempt to issue certificates for your domains.

If you don’t need publicly trusted certs, you can use the tls internal directive to have Caddy issue certs using its local CA instead (similar to self-signed certs).

Not worked…

I turn off Ubuntu and install Windows server on Virtual machine
Windows Server IP
same

  10.0.0.5

Also added Firewall inbound Rules port 80,443,9444
and added Caddy also in Firewall inbound rules

This IP external provided some company and connected with VPN tunnel
with this IP

100.100.50.50

From manual this company I should add to hostsfile
In Windows server in hosts file I add this

 100.100.50.50 someservice.com

Now in windows server I install insomnia and following manual I set credentials try post like this

https://someservice.com:9444/oauth2/token

In Windows Server I get result success I mean I get token etc…

In Caddyfile I set like this

 someservice.com {
	reverse_proxy 100.100.50.50:9444
        tls internal
}

Now I want to try this post from another local windows machine

In my local machine

I set hosts IP windows server

     10.0.0.5 someservice.com

I post in my localmachine via Insomnia like this

https://someservice.com:9444/oauth2/token
  

I get error

 Preparing request to https://someservice.com:9444/oauth2/token
* Current time is 2023-07-07T06:02:29.940Z
* Enable automatic URL encoding
* Using default HTTP version
* Enable SSL validation
* Hostname in DNS cache was stale, zapped
*   Trying 10.0.0.5:9444...
* connect to 10.0.0.5 port 9444 failed: Connection refused
* Failed to connect to someservice.com port 9444 after 2051 ms: Connection refused
* Closing connection 143

Bro can you help me?
I can’t configure caddy for work from other machine

Don’t use port 9444 when making the request. Remove the port, use the default of 443.

Why do you want to use a different port at all? Use the default HTTPS port.

Ok I will try

Because who provided service for us IP server in their manual written use
for one domain :9444 for another :8243

 100.100.50.50 someservice.com
 100.100.50.50 someservice2.com

From windows server successfully work their service when I request post :9444 or :8243

but from my machine I can’t configure

My CaddyFile

someservice.com {
    reverse_proxy 100.100.50.50:9444
    tls internal
    #respond "hello test"
  }

I try without
tls internal

Error Get

* Preparing request to https://someservice.com/oauth2/token
* Current time is 2023-07-08T19:32:31.434Z
* Enable automatic URL encoding
* Using default HTTP version
* Enable SSL validation
* Hostname someservice.com was found in DNS cache
*   Trying 10.0.0.5:443...
* Connected to someservice.com (10.0.0.5) port 443 (#273)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Unknown (21):
* TLSv1.3 (IN), TLS alert, internal error (592):
* error:0A000438:SSL routines::tlsv1 alert internal error
* Closing connection 273

with tls internal

Get error

* Preparing request to https://someservice.com:443/oauth2/token
* Current time is 2023-07-08T19:36:39.205Z
* Enable automatic URL encoding
* Using default HTTP version
* Enable SSL validation
* Hostname someservice.com was found in DNS cache
*   Trying 10.0.0.5:443...
* Connected to someservice.com (10.0.0.5) port 443 (#275)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS header, Unknown (21):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 275

When I request from Windows Server via Insomnia
request successfully work

here log

* Preparing request to https://someservice.com:9444/oauth2/token
* Current time is 2023-07-08T23:40:44.383Z
* Enable automatic URL encoding
* Using default HTTP version
* Enable SSL validation
* Too old connection (3333 seconds), disconnect it
* Connection 6 seems to be dead!
* Closing connection 6
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS alert, close notify (256):
* Hostname in DNS cache was stale, zapped
*   Trying 100.100.50.50:9444...
* Connected to someservice.com (100.100.50.50) port 9444 (#7)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*.any.any
*  start date: Mar 28 00:00:00 2023 GMT
*  expire date: Apr 27 23:59:59 2024 GMT
*  subjectAltName: host "someservice.com" matched cert's "*.any.any"
*  issuer: C=LV; L=Riga; O=GoGetSSL; CN=GoGetSSL RSA DV CA
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* Using Stream ID: 1 (easy handle 0x1e761426a10)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):

> POST /oauth2/token HTTP/2
> Host: someservice.com:9444
> user-agent: insomnia/2022.4.2
> content-type: application/x-www-form-urlencoded
> authorization: Basic superpuper
> accept: */*
> content-length: 67

* TLSv1.2 (OUT), TLS header, Supplemental data (23):

| grant_type=password&username=user&password=superfhg

* We are completely uploaded and fine
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):

< HTTP/2 200 
< server: nginx/1.18.0 (Ubuntu)
< date: Sat, 08 Jul 2023 16:40:47 GMT
< content-type: application/json
< content-length: 1137
< x-frame-options: DENY
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< cache-control: no-store
< pragma: no-cache


* Received 1137 B chunk
* Connection #7 to host someservice.com left intact

Your request here is not going through Caddy. You are making the request directly to whatever application service running on 100.100.50.50:8243 and 100.100.50.50:9444.

Take a step back, do you want the website/service served by Caddy to be accessible publicly?

Case 1: If yes, then your Caddyfile should look something like this:

Earlier you said this did not work without much details. If your Caddy server is publicly accessible (not limited to private and closed network), then add change the Caddyfile to something like the following, try to make a request through your Insomnia, and share the logs printed from Caddy

{
    debug
}
someservice2.com {
	reverse_proxy 100.100.50.50:8243
}

someservice.com {
	reverse_proxy 100.100.50.50:9444
}

Case 2: If not, your Caddy is not supposed to be publicly accessible

If you want to use HTTPS (TLS) in this case, you need to get the certificate chain generated and used by Caddy. First, your Caddyfile should look something like this:

someservice2.com {
	tls internal
	reverse_proxy 100.100.50.50:8243
}

someservice.com {
	tls internal
	reverse_proxy 100.100.50.50:9444
}

Then, on the server where Caddy is, you need to run this command:

curl http://localhost:2019/pki/ca/local/certificates > cert.pem

Take the .pem file and you have to add it to your own Windows certificate store. I believe you will need to use the certutil.exe command, but I don’t have access to a Windows computer to double-check, so you have to research this step. This step is more of Windows administration, while I can only help you with understanding Caddy.

Once you add/install the certificate into your Windows computer, requests from Insomnia should be successful. If not, report/share the logs from both Insomnia and Caddy, not just Insomnia.

2 Likes

Hi bro,
I found solution 2 days spent for this

I add to hosts file in Windows Server

 127.0.0.1 local.someservice.com
 127.0.0.1 local.someservice2.com
 100.100.50.50 someservice.com
 100.100.50.50 someservice2.com

And add my local machine

 10.0.0.5 local.someservice.com
 10.0.0.5 local.someservice2.com

Now I can post from my from local machine but little issue I can’t find solution yet

my requests now work disabled certificate validation mode in Insomnia

My CaddyFile now

local.someservice2.com {
    tls internal    
    reverse_proxy 100.100.50.50:8243 {
        header_up Host someservice2.com
        header_up X-Forwarded-Host {host}
        header_up X-Forwarded-Port {port}
        header_up X-Forwarded-Proto {proto}
        header_up X-Forwarded-Proto-Custom {proto}
        header_up CloudFront-Forwarded-Proto {proto}

        transport http {
            tls_server_name someservice2.com
        }
    }
    #respond "Yep work!!!"
    log {
		output file C:\caddy\logs\someservice2.com\someservice2.log {
		roll true                       # Rotate logs, enabled by default
                roll_size_mb 10         # Set max size 5 MB
                roll_gzip true              # Whether to compress rolled files        
                roll_keep 2                 # Keep at most 2 log files
                roll_keep_days 7        # Keep log files for 7 days
		}		
     }
  }

local.someservice.com {
    tls internal    
    reverse_proxy 100.100.50.50:9444 {
        header_up Host someservice.com
        header_up X-Forwarded-Host {host}
        header_up X-Forwarded-Port {port}
        header_up X-Forwarded-Proto {proto}
        header_up X-Forwarded-Proto-Custom {proto}
        header_up CloudFront-Forwarded-Proto {proto}

        transport http {
            tls_server_name someservice.com
        }
    }
    #respond "Yep work!!!"
    log {
		output file C:\caddy\logs\someservice.com\someservice.log {
		roll true                       # Rotate logs, enabled by default
                roll_size_mb 10         # Set max size 5 MB
                roll_gzip true              # Whether to compress rolled files        
                roll_keep 2                  # Keep at most 2 log files
                roll_keep_days 7        # Keep log files for 7 days
		}		
     }
  }

 

These are not needed

They’re set implicitly. Read more here:

1 Like

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