Domain other than *.localhost

1. The problem I’m having:

I try to setup my local dev environment to have all services running on local domains, because remembering the ports for each is very cumbersome.
I was only able to set up custom domains that end with .localhost. All other attempt failed.
I would like to have a shorter domain name, something like service.local or service.cm.
I was able to set it up with service1.localhost.

2. Error messages and/or full log output:

ERROR   http.acme_client        challenge failed        {"identifier": "service1.lc", "challenge_type": "http-01", "problem": {"type": "", "title": "", "detail": "", "instance": "", "subproblems": []}}
2023/06/02 13:35:24.599 ERROR   http.acme_client        validating authorization        {"identifier": "service1.lc", "problem": {"type": "", "title": "", "detail": "", "instance": "", "subproblems": []}, "order": "https://acme.zerossl.com/v2/DV90/order/ND5QvcbBAVN8AhV5JFFgOg", "attempt": 1, "max_attempts": 3}
2023/06/02 13:35:24.600 ERROR   tls.obtain      could not get certificate from issuer   {"identifier": "service1.lc", "issuer": "acme.zerossl.com-v2-DV90", "error": "HTTP 0  - "}
2023/06/02 13:35:24.600 DEBUG   events  event   {"name": "cert_failed", "id": "e14f64ff-c30b-4e3f-81d9-ddb2196b3b5a", "origin": "tls", "data": {"error":{},"identifier":"service1.lc","issuers":["acme.zerossl.com-v2-DV90"],"renewal":false}}

3. Caddy version:

v2.6.4 h1:2hwYqiRwk1tf3VruhMpLcYTg+11fCdr8S3jhNAdnPy8=

4. How I installed and ran Caddy:

Windows, I put the caddy location to PATH and run it via caddy run in a folder where Caddyfile exists

a. System environment:

Windows 11

hosts file:

127.0.0.1 service1.lc

b. Command:

caddy run

c. Service/unit/compose file:

I'm running a React app, which opens on https://localhost:4000.

d. My complete Caddy config:

{
	debug
}

service1.lc {
	reverse_proxy :4000
}

5. Links to relevant resources:

Use tls internal, e.g.

service1.lc {
	tls internal
	reverse_proxy localhost:4000
}

See Automatic HTTPS — Caddy Documentation and tls (Caddyfile directive) — Caddy Documentation

1 Like

This didn’t solve the issue.
If I try to access the domain .lc after some tiem I get an error “ERR_CONNECTION_RESET”.
When I open a page with .localhost domain everything works.

That sounds like a network issue.

I would advise using curl -v to make the request, and post the output here if you want help troubleshooting, along with the Caddy server logs (with debug mode enabled).

Curl fails:

curl -v https://service1.lc
VERBOSE: GET with 0-byte payload
curl : The underlying connection was closed: An unexpected error occurred on a send.
At line:1 char:1
+ curl -v https://service1.lc
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

Ping succeds:

ping service1.lc

Pinging service1.lc [127.0.0.1] with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Ping statistics for 127.0.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

It seems that the request does not reach Caddy:

PS C:\src\XYZ\CaddyProxy> caddy run
2023/06/05 11:49:42.775 INFO    using adjacent Caddyfile
2023/06/05 11:49:42.782 INFO    admin   admin endpoint started  {"address": "localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
2023/06/05 11:49:42.783 INFO    tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc0004808c0"}
2023/06/05 11:49:42.784 INFO    http    server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS {"server_name": "srv0", "https_port": 443}
2023/06/05 11:49:42.784 INFO    http    enabling automatic HTTP->HTTPS redirects        {"server_name": "srv0"}
2023/06/05 11:49:42.810 INFO    pki.ca.local    root certificate is already trusted by system   {"path": "storage:pki/authorities/local/root.crt"}
2023/06/05 11:49:42.810 INFO    tls     cleaning storage unit   {"description": "FileStorage:C:\\Users\\MyUser\\AppData\\Roaming\\Caddy"}
2023/06/05 11:49:42.811 INFO    http    enabling HTTP/3 listener        {"addr": ":443"}
2023/06/05 11:49:42.811 DEBUG   http    starting server loop    {"address": "[::]:443", "tls": true, "http3": true}
2023/06/05 11:49:42.811 INFO    http.log        server running  {"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2023/06/05 11:49:42.812 DEBUG   http    starting server loop    {"address": "[::]:80", "tls": false, "http3": false}
2023/06/05 11:49:42.812 INFO    http.log        server running  {"name": "remaining_auto_https_redirects", "protocols": ["h1", "h2", "h3"]}
2023/06/05 11:49:42.812 INFO    http    enabling automatic TLS certificate management   {"domains": ["s1.localhost", "service1.lc", "service1.lh", "service1.localhost", "service1.local"]}
2023/06/05 11:49:42.813 WARN    tls     stapling OCSP   {"error": "no OCSP stapling for [s1.localhost]: no OCSP server specified in certificate", "identifiers": ["s1.localhost"]}
2023/06/05 11:49:42.813 DEBUG   tls.cache       added certificate to cache      {"subjects": ["s1.localhost"], "expiration": "2023/06/05 17:20:05.000", "managed": true, "issuer_key": "local", "hash": "a6018d4cc7084ada2826e978fc8d25e9582b4bb4f4562a562a5eecc4d1379167", "cache_size": 1, "cache_capacity": 10000}
2023/06/05 11:49:42.813 DEBUG   events  event   {"name": "cached_managed_cert", "id": "7a03d25c-1ee0-4156-b81d-79bef4309960", "origin": "tls", "data": {"sans":["s1.localhost"]}}
2023/06/05 11:49:42.814 WARN    tls     stapling OCSP   {"error": "no OCSP stapling for [service1.lc]: no OCSP server specified in certificate", "identifiers": ["service1.lc"]}
2023/06/05 11:49:42.814 DEBUG   tls.cache       added certificate to cache      {"subjects": ["service1.lc"], "expiration": "2023/06/05 23:23:26.000", "managed": true, "issuer_key": "local", "hash": "b6e5ce04214e3dc75133c658ad9edabe8e73a445b893abaf26b617ff531890e1", "cache_size": 2, "cache_capacity": 10000}
2023/06/05 11:49:42.814 DEBUG   events  event   {"name": "cached_managed_cert", "id": "4869ca58-33f1-4bfc-b038-c0c0bba7b4f0", "origin": "tls", "data": {"sans":["service1.lc"]}}
2023/06/05 11:49:42.815 WARN    tls     stapling OCSP   {"error": "no OCSP stapling for [service1.lh]: no OCSP server specified in certificate", "identifiers": ["service1.lh"]}
2023/06/05 11:49:42.815 DEBUG   tls.cache       added certificate to cache      {"subjects": ["service1.lh"], "expiration": "2023/06/05 23:23:26.000", "managed": true, "issuer_key": "local", "hash": "b77b1e7a639a4410ec3f3262881fe4ca09db7e638399e83e56999f87ba95833c", "cache_size": 3, "cache_capacity": 10000}
2023/06/05 11:49:42.815 DEBUG   events  event   {"name": "cached_managed_cert", "id": "85442d8d-c75f-4ce2-b146-3d55f3ea6616", "origin": "tls", "data": {"sans":["service1.lh"]}}
2023/06/05 11:49:42.815 WARN    tls     stapling OCSP   {"error": "no OCSP stapling for [service1.localhost]: no OCSP server specified in certificate", "identifiers": ["service1.localhost"]}
2023/06/05 11:49:42.816 DEBUG   tls.cache       added certificate to cache      {"subjects": ["service1.localhost"], "expiration": "2023/06/05 23:32:46.000", "managed": true, "issuer_key": "local", "hash": "393621722ddceec3b6e0b71709a6be904570a2abb234a2191412d45f04b962b2", "cache_size": 4, "cache_capacity": 10000}
2023/06/05 11:49:42.816 DEBUG   events  event   {"name": "cached_managed_cert", "id": "cc67ff73-535d-4697-bef9-b763af5ddb55", "origin": "tls", "data": {"sans":["service1.localhost"]}}
2023/06/05 11:49:42.816 WARN    tls     stapling OCSP   {"error": "no OCSP stapling for [service1.local]: no OCSP server specified in certificate", "identifiers": ["service1.local"]}
2023/06/05 11:49:42.816 DEBUG   tls.cache       added certificate to cache      {"subjects": ["service1.local"], "expiration": "2023/06/05 23:23:26.000", "managed": true, "issuer_key": "local", "hash": "b5d37b9fb6ee688aa5065c157a869fc0468849b8e73add58aee0e1b4575718d8", "cache_size": 5, "cache_capacity": 10000}
2023/06/05 11:49:42.816 DEBUG   events  event   {"name": "cached_managed_cert", "id": "823e5820-93e0-4c3f-9554-ad918adce9f7", "origin": "tls", "data": {"sans":["service1.local"]}}
2023/06/05 11:49:42.817 INFO    autosaved config (load with --resume flag)      {"file": "C:\\Users\\MyUser\\AppData\\Roaming\\Caddy\\autosave.json"}
2023/06/05 11:49:42.817 INFO    serving initial configuration
2023/06/05 11:49:42.820 INFO    tls     finished cleaning storage units

The ping just shows that you can reach 127.0.0.1 on 127.0.0.1 – expected, and probably tangential.

It looks like something on your machine (selinux? some other network interference) is causing the connection to be blocked. That’s about as far as we can help I think, since we don’t know what software you have on your system or how you have it configured or its history.

But the good news is, Caddy seems to be working properly and is not the problem :blush:

That’s not actually curl you’re running, you ran Invoke-WebRequest which is Windows’ HTTP request tool. I hate that they “cover” curl like this because it’s absolutely not the same thing.

Try using real curl. You can install it with chocolatey or scoop on Windows, or apparently now with winget as well [Zip][Portable] New Package: cURL.cURL 7.85.0 by Trenly · Pull Request #88071 · microsoft/winget-pkgs · GitHub.

Oh, sorry…

I tried it now with “real” cURL :slight_smile:

./curl.exe -v service1.lc
*   Trying 127.0.0.1:80...
* Connected to service1.lc (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
> Host: service1.lc
> User-Agent: curl/8.1.2
> Accept: */*
>
* Recv failure: Connection was reset
* Closing connection 0
curl: (56) Recv failure: Connection was reset

Caddy is running, no logs were printed when request is made, even though debug option is turned on.
The proxied server is up and running and accessible.

1 Like

That means you’re not reaching Caddy at all. It’s a networking issue on your system, not a problem with Caddy itself. Make sure Windows’ firewall isn’t preventing connections. You might need to grant access to the Caddy program in the firewall config (for incoming connections).

1 Like

The question that grinds my gears is why it works for *.localhost?

I’ll try and have a look at it.

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