TLS handshake error / no certificate available for

1. Caddy version (caddy version):

v2.2.2 h1:Ha3bvEvkb/GLGEX648/qI5zTt6uJCnfQhZHmZBxhzDY=

2. How I run Caddy:

installed “apt install caddy”
through systemctl command.

a. System environment:

Ubuntu 20.04.1 LTS virtualised on vmware esxi

b. Command:

systemctl run caddy

c. Service/unit/compose file:

[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target

[Service]
User=caddy
Group=caddy
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

d. My complete Caddyfile or JSON config:

{
        debug
        acme_ca https://acme-staging-v02.api.letsencrypt.org/directory

}

www.theg.vg
{
        reverse_proxy 192.168.10.200:80
}

3. The problem I’m having:

i’m debuting completely on Caddy server.

i’m trying to redirect my personnal website running on Synology to caddy server, both running on the same network at home.
simple reverse proxy to allow external access to the url www.theg.vg → to get the webpage from outside my home.

FW and NAT is working. but once i try to connect it time out on 80 and in port 443 it got a TLS handshake error

4. Error messages and/or full log output:

Dec 13 18:01:16 celestine systemd[1]: caddy.service: Succeeded.
Dec 13 18:01:16 celestine systemd[1]: Stopped Caddy.
Dec 13 18:01:16 celestine systemd[1]: Started Caddy.
Dec 13 18:01:16 celestine caddy[13759]: caddy.HomeDir=/var/lib/caddy
Dec 13 18:01:16 celestine caddy[13759]: caddy.AppDataDir=/var/lib/caddy/.local/share/caddy
Dec 13 18:01:16 celestine caddy[13759]: caddy.AppConfigDir=/var/lib/caddy/.config/caddy
Dec 13 18:01:16 celestine caddy[13759]: caddy.ConfigAutosavePath=/var/lib/caddy/.config/caddy/autosave.json
Dec 13 18:01:16 celestine caddy[13759]: caddy.Version=v2.2.2
Dec 13 18:01:16 celestine caddy[13759]: runtime.GOOS=linux
Dec 13 18:01:16 celestine caddy[13759]: runtime.GOARCH=amd64
Dec 13 18:01:16 celestine caddy[13759]: runtime.Compiler=gc
Dec 13 18:01:16 celestine caddy[13759]: runtime.NumCPU=1
Dec 13 18:01:16 celestine caddy[13759]: runtime.GOMAXPROCS=1
Dec 13 18:01:16 celestine caddy[13759]: runtime.Version=go1.15.5
Dec 13 18:01:16 celestine caddy[13759]: os.Getwd=/
Dec 13 18:01:16 celestine caddy[13759]: LANG=en_US.UTF-8
Dec 13 18:01:16 celestine caddy[13759]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
Dec 13 18:01:16 celestine caddy[13759]: HOME=/var/lib/caddy
Dec 13 18:01:16 celestine caddy[13759]: LOGNAME=caddy
Dec 13 18:01:16 celestine caddy[13759]: USER=caddy
Dec 13 18:01:16 celestine caddy[13759]: INVOCATION_ID=3083c7103b9c484abc6c55504cb2e6cb
Dec 13 18:01:16 celestine caddy[13759]: JOURNAL_STREAM=9:63884
Dec 13 18:01:16 celestine caddy[13759]: {"level":"info","ts":1607882476.294547,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":""}
Dec 13 18:01:16 celestine caddy[13759]: {"level":"info","ts":1607882476.2963278,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["localhost:2019","[::1]:2019","127.0.0.1:2019"]}
Dec 13 18:01:16 celestine caddy[13759]: {"level":"debug","ts":1607882476.297375,"logger":"http","msg":"starting server loop","address":"[::]:443","http3":false,"tls":true}
Dec 13 18:01:16 celestine caddy[13759]: {"level":"info","ts":1607882476.2981422,"msg":"autosaved config","file":"/var/lib/caddy/.config/caddy/autosave.json"}
Dec 13 18:01:16 celestine caddy[13759]: {"level":"info","ts":1607882476.2982664,"msg":"serving initial configuration"}
Dec 13 18:01:16 celestine caddy[13759]: {"level":"info","ts":1607882476.298512,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc0004783f0"}
Dec 13 18:01:16 celestine caddy[13759]: {"level":"info","ts":1607882476.2991412,"logger":"tls","msg":"cleaned up storage units"}
Dec 13 18:02:19 celestine caddy[13759]: {"level":"debug","ts":1607882539.9893303,"logger":"http.stdlib","msg":"http: TLS handshake error from 192.168.10.100:35878: no certificate available for 'www.theg.vg'"}

and the test

PS C:\> Invoke-WebRequest -Uri http://www.theg.vg
Invoke-WebRequest : Impossible de se connecter au serveur distant
Au caractère Ligne:1 : 1
+ Invoke-WebRequest -Uri http://www.theg.vg
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation : (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

PS C:\> Invoke-WebRequest -Uri https://www.theg.vg
Invoke-WebRequest : La demande a été abandonnée : Impossible de créer un canal sécurisé SSL/TLS.
Au caractère Ligne:1 : 1
+ Invoke-WebRequest -Uri https://www.theg.vg
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation : (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

5. What I already tried:

i checked if the certificate is present,and it is:

root@celestine:/var/lib/caddy/.local/share/caddy/certificates/acme-staging-v02.api.letsencrypt.org-directory/www.theg.vg# ls -la
total 20
drwx------ 2 caddy caddy 4096 Dec 12 23:11 .
drwx------ 3 caddy caddy 4096 Dec 13 17:01 ..
-rw------- 1 caddy caddy 3262 Dec 12 23:11 www.theg.vg.crt
-rw------- 1 caddy caddy  158 Dec 12 23:11 www.theg.vg.json
-rw------- 1 caddy caddy  227 Dec 12 23:11 www.theg.vg.key

i tested the Caddyfile to use only http/80 to test the chain and it work, but once i move to https it failed

{
        debug
        acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
		auto_https off
}

http://www.theg.vg
{
        reverse_proxy 192.168.10.200:80
}

thanks for your help.

6. Links to relevant resources:

Did you build Caddy from source? What commit/branch did you use exactly? v2.2.2 is not a real version.

1 Like

@francislavoie

i followed the instructions from https://caddyserver.com/docs/download , section ubuntu

echo "deb [trusted=yes] https://apt.fury.io/caddy/ /"  | sudo tee -a /etc/apt/sources.list.d/caddy-fury.list
sudo apt update
sudo apt install caddy

once installed i did caddy version

here is the result of apt info caddy

root@compute:/home# apt info caddy
Package: caddy
Version: 2.2.2
Priority:
Section:
Maintainer: Matthew Holt <mholt@users.noreply.github.com>
Installed-Size: 33.1 MB
Homepage: https://caddyserver.com
Vendor: Light Code Labs
Download-Size: 11.5 MB
APT-Manual-Installed: yes
APT-Sources: https://apt.fury.io/caddy  Packages
Description: Powerful, enterprise-ready, open source web server with automatic
 HTTPS written in Go

one parallele question when run as service like that i tried to get log file but was not able to get log generated, is there a specific/best location/pre-requisites for the log ?

here the Caddyfile i tried (i also tried to create a /var/caddy where to write the file i pushed to have RW right to everyone in the folder. same result.
so i moved the debug command in the global section, for now.

{
        acme_ca https://acme-staging-v02.api.letsencrypt.org/directory

}

www.theg.vg
{
        reverse_proxy 192.168.10.200:80
        
        log {
               output stderr
               output file /tmp/caddy_www_access.log
               level DEBUG
        }
}

thanks :slight_smile:

I have similar issues as Tonic8 has. I’m using the same repository as them, i.e. the one that is hosted at apt.fury.io.

My issues occurred today after I ran apt upgrade.

If I run caddy version it responds v2.2.2 h1:Ha3bvEvkb/GLGEX648/qI5zTt6uJCnfQhZHmZBxhzDY=.

After I performed the upgrade it seems like Caddy has stopped responding at port 443.

Running telnet 127.0.0.1 443 yields this:

telnet 127.0.0.1 443
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused

Does anyone know what’s up with this?

If I look over at Releases · caddyserver/caddy · GitHub it says the latest release is v2.2.1. So how come fury.io has a package for 2.2.2…?

Additional info:

As a workaround, I downgraded Caddy by running this command:

apt-get install caddy=2.2.1

The bad package is at this URL: https://apt.fury.io/caddy/files/ver_4MwWy/caddy_2.2.2_linux_amd64.deb

MD5Sum: c8a62e75a3f40572b9299d91b18ff252

If anyknow know what has happened here then feel free to enlighten us :slight_smile:

Argh.

We had an issue with tags yesterday when launching the v2.3.0-rc.1 release, as Matt noted on twitter:

Github has strange behaviour when it comes to forks and tags (a contributor made a fork and tagged their own v2.2.2 for themselves. See the twitter thread from @theJeztah that explains exactly why that happens.

Apparently our CI still ran on the bad 2.2.2 tag and pushed it to gemfury. It shouldn’t have.

I deleted that version from Gemfury now.

@giffengrabber, thanks for that command, please run apt install caddy=2.2.1 to downgrade to the latest stable version for now.

We’ll release v2.3.0 quite soon, you can download the .deb directly from Github for now if you want to try the release candidate early (any early testing is much appreciated, it helps make sure our stable releases go without a hitch!)

1 Like

i downgraded to the 2.2.1. like that i’m on the stable canal.

but :frowning: same result.

Dec 13 21:22:22 compute caddy[18990]: {"level":"debug","ts":1607894542.6437356,"logger":"http.stdlib","msg":"http: TLS handshake error from 192.168.10.100:44653: no certificate available for 'www.theg.vg'"}

@francislavoie Aha, I see. I’m afraid I don’t have the possibility to do testing at this point but will consider it in the future. Thank you for the explanation!

1 Like

quick question is there a command to cleanup the certificates requested?

or force Caddy to request a new certificate one time?

regards.

There’s no command, but if you delete the files in Caddy’s storage directory and restart, it will fetch new ones.

Sorry, I’m not sure what’s going wrong honestly, your config it looks fine to me.

The only reaction I had at seeing your original post is that the { should probably be on the same line as your domain, but the Caddyfile parser seems not to care about that specifically for site blocks. You can run caddy fmt to clean that up, I think. I used the caddy adapt command to compare how your config looks before and after moving the { and it made no difference.

I tried your Caddyfile (but replaced the acme_ca line with local_certs since your domain doesn’t point to my test server) and it worked just fine. How can we reproduce this?

What happens if you rename the folder the certificate assets are in?

Hello

reading again your response, and i think i cumulate 2 issues mixing each other:

  • one with the 2.2.2 “dummy” version downloaded
  • one with the fact i’m using Nat with PFsense

for the first one, once i fallback to the 2.2.1 i had to reverse/cleanup all the different things done try to find the issue (changing my local host file, updating the dns cache, setting right back the parameter, etc)

i then was able to access from outside the website, but still not from inside.

digging a few minutes in the forum i found a thread corresponding to my issue “pfsense nat reverse proxy” where Whitestrake explain it very well the issue and the corrections.

i didn’t changed the certificate (or renewed it yet i’m still on the acme staging), i’m still a little bit confuse why i had this message last night even with the 2.2.1. the certificate was present and it’s now working nothing done on the certificate itself.

TLS handshake error from 192.168.10.100:44653: no certificate available for 'www.theg.vg'"

but this morning reading again the log it seems to disapear after a while, so maybe a cache or something like that expired.

thanks all!, will try to add more stuff on the caddyfile and lastely switch to a docker version

Stay safe

Can we uninstall 2020 and install it again?
This version has a virus.

1 Like

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