Ssl_error_internal_error_alert

1. Output of caddy version:

PS C:\Users\Admin\Documents> caddy version
v2.5.2 h1:eCJdLyEyAGzuQTa5Mh3gETnYWDClo1LjtQm2q9RNZrs=

2. How I run Caddy:

Manually invoked in PowerShell, haven’t setup task scheduler for caddy on this system yet.

a. System environment:

Windows 10, amd64, Version 21H2

b. Command:

caddy start

or when trying to debug;

caddy run

c. Service/unit/compose file:

N/A

d. My complete Caddy config:

# Caddyfile for frenchfry

#:80 {
#        file_server
#        root * C:\www
#}

96.230.16.132 {
        file_server
        root * C:\www
        tls "C:\Users\Admin\Documents\96.230.16.132\mycert.pem" "C:\Users\Admin\Documents\96.230.16.132\key.pem"
}

3. The problem I’m having:

Afaik, Caddy is not sending the certificate I used at all. The cert is issued by ZeroSSL and is valid.

I have configured Caddy the same way on other systems before (using the same process to make the cert) and had no issues.

4. Error messages and/or full log output:

PS C:\Users\Admin\Documents> caddy run
2022/08/20 13:24:30.911 ←[34mINFO←[0m   using adjacent Caddyfile
2022/08/20 13:24:30.920 ←[34mINFO←[0m   admin   admin endpoint started  {"address": "tcp/localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
2022/08/20 13:24:30.921 ←[34mINFO←[0m   tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc000233420"}
2022/08/20 13:24:30.921 ←[34mINFO←[0m   http    skipping automatic certificate management because one or more matching certificates are already loaded  {"domain": "96.230.16.132", "server_name": "srv0"}
2022/08/20 13:24:30.921 ←[34mINFO←[0m   http    enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
2022/08/20 13:24:30.923 ←[34mINFO←[0m   tls     cleaning storage unit   {"description": "FileStorage:C:\\Users\\Admin\\AppData\\Roaming\\Caddy"}
2022/08/20 13:24:30.924 ←[34mINFO←[0m   tls     finished cleaning storage units
2022/08/20 13:24:30.925 ←[34mINFO←[0m   autosaved config (load with --resume flag)      {"file": "C:\\Users\\Admin\\AppData\\Roaming\\Caddy\\autosave.json"}
2022/08/20 13:24:30.925 ←[34mINFO←[0m   serving initial configuration

PS C:\Users\Tyler> curl -v https://96.230.16.132/
VERBOSE: GET https://96.230.16.132/ with 0-byte payload
curl : The request was aborted: Could not create SSL/TLS secure channel.
At line:1 char:1
+ curl -v https://96.230.16.132/
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

5. What I already tried:

I have tried rewriting my Caddyfile, commenting the tls directive and using tls internal instead, not really much else I can try as ACME does not support an IP address and this is a relatively simple caddyfile, a “known working” (setup the same way before on other host) config, and I could not really think of much else to try.

6. Links to relevant resources:

N/A

What are the SANs on your certificate?

As far as I understand what this means (my interpretation is that this is all the names the certificate applies to) that would be only 96.230.16.132
image

There should be something else in the logs, what happens if you enable debug mode? Put this at the top of your Caddyfile:

{
    debug
}

If nothing, then you’re definitely not reaching your Caddy at all. It is reaching some other server.

Thanks a lot for your suggestion. It seems based on the debug log that Caddy is trying to serve for the local IP address rather then for my Public IP.

PS C:\Users\Admin\Documents> caddy run
2022/08/21 00:59:45.616 ←[34mINFO←[0m   using adjacent Caddyfile
2022/08/21 00:59:45.618 ←[33mWARN←[0m   Caddyfile input is not formatted; run the 'caddy fmt' command to fix inconsistencies    {"adapter": "caddyfile", "file": "Caddyfile", "line": 2}
2022/08/21 00:59:45.623 ←[34mINFO←[0m   admin   admin endpoint started  {"address": "tcp/localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
2022/08/21 00:59:45.623 ←[34mINFO←[0m   tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc00007dea0"}
2022/08/21 00:59:45.639 ←[35mDEBUG←[0m  tls.cache       added certificate to cache      {"subjects": ["96.230.16.132"], "expiration": "2022/11/18 23:59:59.000", "managed": false, "issuer_key": "", "hash": "76af74e44c419bf21c22e26ea9c7f9c2b64b60e05bbaa42c1da4775b301a664c", "cache_size": 1, "cache_capacity": 10000}
2022/08/21 00:59:45.640 ←[34mINFO←[0m   http    skipping automatic certificate management because one or more matching certificates are already loaded  {"domain": "96.230.16.132", "server_name": "srv0"}
2022/08/21 00:59:45.640 ←[34mINFO←[0m   http    enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
2022/08/21 00:59:45.640 ←[34mINFO←[0m   tls     cleaning storage unit   {"description": "FileStorage:C:\\Users\\Admin\\AppData\\Roaming\\Caddy"}
2022/08/21 00:59:45.641 ←[35mDEBUG←[0m  http    starting server loop    {"address": "[::]:443", "http3": false, "tls": true}
2022/08/21 00:59:45.645 ←[35mDEBUG←[0m  http    starting server loop    {"address": "[::]:80", "http3": false, "tls": false}
2022/08/21 00:59:45.646 ←[34mINFO←[0m   autosaved config (load with --resume flag)      {"file": "C:\\Users\\Admin\\AppData\\Roaming\\Caddy\\autosave.json"}
2022/08/21 00:59:45.646 ←[34mINFO←[0m   serving initial configuration
2022/08/21 00:59:45.651 ←[34mINFO←[0m   tls     finished cleaning storage units
2022/08/21 01:00:04.462 ←[35mDEBUG←[0m  tls.handshake   no matching certificates and no custom selection logic  {"identifier": "192.168.3.2"}
2022/08/21 01:00:04.462 ←[35mDEBUG←[0m  tls.handshake   all external certificate managers yielded no certificates and no errors {"sni": ""}
2022/08/21 01:00:04.465 ←[35mDEBUG←[0m  tls.handshake   no certificate matching TLS ClientHello {"server_name": "", "remote": "192.168.1.1:59139", "identifier": "192.168.3.2", "cipher_suites": [51914, 4865, 4866, 4867, 49195, 49199, 49196, 49200, 52393, 52392, 49171, 49172, 156, 157, 47, 53], "cert_cache_fill": 0.0001, "load_if_necessary": true, "obtain_if_necessary": true, "on_demand": false}
2022/08/21 01:00:04.467 ←[35mDEBUG←[0m  http.stdlib     http: TLS handshake error from 192.168.1.1:59139: no certificate available for '192.168.3.2'
2022/08/21 01:00:04.605 ←[35mDEBUG←[0m  tls.handshake   no matching certificates and no custom selection logic  {"identifier": "192.168.3.2"}
2022/08/21 01:00:04.606 ←[35mDEBUG←[0m  tls.handshake   all external certificate managers yielded no certificates and no errors {"sni": ""}
2022/08/21 01:00:04.608 ←[35mDEBUG←[0m  tls.handshake   no certificate matching TLS ClientHello {"server_name": "", "remote": "192.168.1.1:59141", "identifier": "192.168.3.2", "cipher_suites": [23130, 4865, 4866, 4867, 49195, 49199, 49196, 49200, 52393, 52392, 49171, 49172, 156, 157, 47, 53], "cert_cache_fill": 0.0001, "load_if_necessary": true, "obtain_if_necessary": true, "on_demand": false}
2022/08/21 01:00:04.610 ←[35mDEBUG←[0m  http.stdlib     http: TLS handshake error from 192.168.1.1:59141: no certificate available for '192.168.3.2'

So this at least solves the issue of what the problem is, but I’m not sure how I would go about fixing it. Any suggestions are appreciated.

1 Like

That happens when the client is making a TLS connection without a ServerName (SNI) in the ClientHello, which is the correct behavior when connecting to an IP address (i.e. no name for the server).

Are you running that curl command within the same internal network as your Caddy instance? If so, it’s likely your router is translating the IP from the public IP to the internal one, which Caddy isn’t configured to serve. (I think this is called hairpin NAT.)

Hi, I did run the cURL command within my local network. But I have confirmed the same SSL error occurs on my phone connected via mobile data and on Tor. I have also asked someone else to try accessing the IP. The debug log generates identical output (besides from remote, of course.).

When accessing my IP via a dns name (in this case 96.230.16.132.ip.trolling.solutions) the log shows what I would expect so I don’t understand whatsoever how this problem is being caused.

2022/08/21 03:38:55.320 ←[35mDEBUG←[0m  http.stdlib     http: TLS handshake error from 192.168.1.1:56046: no certificate available for '96.230.16.132.ip.trolling.solutions'
2022/08/21 03:39:43.863 ←[35mDEBUG←[0m  tls.handshake   no matching certificates and no custom selection logic  {"identifier": "96.230.16.132.ip.trolling.solutions"}
2022/08/21 03:39:43.863 ←[35mDEBUG←[0m  tls.handshake   no matching certificates and no custom selection logic  {"identifier": "*.230.16.132.ip.trolling.solutions"}
2022/08/21 03:39:43.865 ←[35mDEBUG←[0m  tls.handshake   no matching certificates and no custom selection logic  {"identifier": "*.*.16.132.ip.trolling.solutions"}
2022/08/21 03:39:43.865 ←[35mDEBUG←[0m  tls.handshake   no matching certificates and no custom selection logic  {"identifier": "*.*.*.132.ip.trolling.solutions"}
2022/08/21 03:39:43.871 ←[35mDEBUG←[0m  tls.handshake   no matching certificates and no custom selection logic  {"identifier": "*.*.*.*.ip.trolling.solutions"}
2022/08/21 03:39:43.871 ←[35mDEBUG←[0m  tls.handshake   no matching certificates and no custom selection logic  {"identifier": "*.*.*.*.*.trolling.solutions"}
2022/08/21 03:39:43.871 ←[35mDEBUG←[0m  tls.handshake   no matching certificates and no custom selection logic  {"identifier": "*.*.*.*.*.*.solutions"}
2022/08/21 03:39:43.871 ←[35mDEBUG←[0m  tls.handshake   no matching certificates and no custom selection logic  {"identifier": "*.*.*.*.*.*.*"}
2022/08/21 03:39:43.872 ←[35mDEBUG←[0m  tls.handshake   all external certificate managers yielded no certificates and no errors {"sni": "96.230.16.132.ip.trolling.solutions"}
2022/08/21 03:39:43.872 ←[35mDEBUG←[0m  tls.handshake   no certificate matching TLS ClientHello {"server_name": "96.230.16.132.ip.trolling.solutions", "remote": "149.154.161.220:44726", "identifier": "96.230.16.132.ip.trolling.solutions", "cipher_suites": [4866, 4867, 4865, 49196, 49200, 159, 52393, 52392, 52394, 49195, 49199, 158, 49188, 49192, 107, 49187, 49191, 103, 49162, 49172, 57, 49161, 49171, 51, 157, 156, 61, 60, 53, 47, 255], "cert_cache_fill": 0.0001, "load_if_necessary": true, "obtain_if_necessary": true, "on_demand": false}
2022/08/21 03:39:43.872 ←[35mDEBUG←[0m  http.stdlib     http: TLS handsh

I’m not sure, but if something on your network is rewriting TCP packets’ From address to an internal IP, that would probably do it; but that also sounds broken. Maybe some weird NAT going on…

Is there a way I can force Caddy to respond to local ips as if they were public?

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