TLS Handshake error when reverse proxy requesting certificate

allenb · May 14, 2023, 6:02pm

1. The problem I’m having:

I’m trying to use a frontend instance of Caddy as an acme server and issue certificates to services on other machines in my LAN. The frontend Caddy successfully received a certificate and can serve HTTPS connections correctly to the WAN, but when the backend Caddy requests to the front end (acme server), it received an X509 certificate signed by unknown authority. A similar error pops up when curl -vL ing

2. Error messages and/or full log output:

Backend log:
gloin@gloin:~$ sudo caddy run
2023/05/14 17:46:39.114	INFO	using adjacent Caddyfile
2023/05/14 17:46:39.116	INFO	admin	admin endpoint started	{"address": "localhost:2019", "enforce_origin": false, "origins": ["//[::1]:2019", "//127.0.0.1:2019", "//localhost:2019"]}
2023/05/14 17:46:39.117	INFO	tls.cache.maintenance	started background certificate maintenance	{"cache": "0xc00049c230"}
2023/05/14 17:46:39.117	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/05/14 17:46:39.117	INFO	http	enabling automatic HTTP->HTTPS redirects	{"server_name": "srv0"}
2023/05/14 17:46:39.117	INFO	http	enabling HTTP/3 listener	{"addr": ":443"}
2023/05/14 17:46:39.118	INFO	tls	cleaning storage unit	{"description": "FileStorage:/root/.local/share/caddy"}
2023/05/14 17:46:39.118	INFO	tls	finished cleaning storage units
2023/05/14 17:46:39.118	INFO	failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Receive-Buffer-Size for details.
2023/05/14 17:46:39.118	DEBUG	http	starting server loop	{"address": "[::]:443", "tls": true, "http3": true}
2023/05/14 17:46:39.118	INFO	http.log	server running	{"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2023/05/14 17:46:39.118	DEBUG	http	starting server loop	{"address": "[::]:80", "tls": false, "http3": false}
2023/05/14 17:46:39.118	INFO	http.log	server running	{"name": "remaining_auto_https_redirects", "protocols": ["h1", "h2", "h3"]}
2023/05/14 17:46:39.118	INFO	http	enabling automatic TLS certificate management	{"domains": ["gloin.dwarf"]}
2023/05/14 17:46:39.119	INFO	autosaved config (load with --resume flag)	{"file": "/root/.config/caddy/autosave.json"}
2023/05/14 17:46:39.119	INFO	serving initial configuration
2023/05/14 17:46:39.119	INFO	tls.obtain	acquiring lock	{"identifier": "gloin.dwarf"}
2023/05/14 17:46:39.121	INFO	tls.obtain	lock acquired	{"identifier": "gloin.dwarf"}
2023/05/14 17:46:39.121	INFO	tls.obtain	obtaining certificate	{"identifier": "gloin.dwarf"}
2023/05/14 17:46:39.122	DEBUG	events	event	{"name": "cert_obtaining", "id": "9e54e296-bd86-4e99-a247-c14e81df60a7", "origin": "tls", "data": {"identifier":"gloin.dwarf"}}
2023/05/14 17:46:39.122	DEBUG	tls.obtain	trying issuer 1/1	{"issuer": "oin.dwarf-home-oin-.local"}
2023/05/14 17:46:39.126	WARN	http.acme_client	HTTP request failed; retrying	{"url": "https://oin.dwarf/home/oin/.local", "error": "performing request: Get \"https://oin.dwarf/home/oin/.local\": tls: failed to verify certificate: x509: certificate signed by unknown authority (possibly because of \"x509: ECDSA verification failure\" while trying to verify candidate authority certificate \"Caddy Local Authority - 2023 ECC Root\")"}
2023/05/14 17:46:39.380	WARN	http.acme_client	HTTP request failed; retrying	{"url": "https://oin.dwarf/home/oin/.local", "error": "performing request: Get \"https://oin.dwarf/home/oin/.local\": tls: failed to verify certificate: x509: certificate signed by unknown authority (possibly because of \"x509: ECDSA verification failure\" while trying to verify candidate authority certificate \"Caddy Local Authority - 2023 ECC Root\")"}
2023/05/14 17:46:39.635	WARN	http.acme_client	HTTP request failed; retrying	{"url": "https://oin.dwarf/home/oin/.local", "error": "performing request: Get \"https://oin.dwarf/home/oin/.local\": tls: failed to verify certificate: x509: certificate signed by unknown authority (possibly because of \"x509: ECDSA verification failure\" while trying to verify candidate authority certificate \"Caddy Local Authority - 2023 ECC Root\")"}
2023/05/14 17:46:39.635	ERROR	tls.obtain	could not get certificate from issuer	{"identifier": "gloin.dwarf", "issuer": "oin.dwarf-home-oin-.local", "error": "registering account [] with server: provisioning client: performing request: Get \"https://oin.dwarf/home/oin/.local\": tls: failed to verify certificate: x509: certificate signed by unknown authority (possibly because of \"x509: ECDSA verification failure\" while trying to verify candidate authority certificate \"Caddy Local Authority - 2023 ECC Root\")"}
2023/05/14 17:46:39.635	DEBUG	events	event	{"name": "cert_failed", "id": "92c6b05b-868e-42dd-8ee7-4fad48ad9b50", "origin": "tls", "data": {"error":{},"identifier":"gloin.dwarf","issuers":["oin.dwarf-home-oin-.local"],"renewal":false}}
2023/05/14 17:46:39.635	ERROR	tls.obtain	will retry	{"error": "[gloin.dwarf] Obtain: registering account [] with server: provisioning client: performing request: Get \"https://oin.dwarf/home/oin/.local\": tls: failed to verify certificate: x509: certificate signed by unknown authority (possibly because of \"x509: ECDSA verification failure\" while trying to verify candidate authority certificate \"Caddy Local Authority - 2023 ECC Root\")", "attempt": 1, "retrying_in": 60, "elapsed": 0.513861091, "max_duration": 2592000}

Frontend log
oin@oin:~$ sudo caddy run
2023/05/14 17:47:32.757	INFO	using adjacent Caddyfile
2023/05/14 17:47:32.759	INFO	admin	admin endpoint started	{"address": "localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
2023/05/14 17:47:32.760	INFO	tls.cache.maintenance	started background certificate maintenance	{"cache": "0xc000338230"}
2023/05/14 17:47:32.760	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/05/14 17:47:32.760	INFO	http	enabling automatic HTTP->HTTPS redirects	{"server_name": "srv0"}
2023/05/14 17:47:32.875	INFO	tls	cleaning storage unit	{"description": "FileStorage:/root/.local/share/caddy"}
2023/05/14 17:47:32.875	DEBUG	http	starting server loop	{"address": "[::]:80", "tls": false, "http3": false}
2023/05/14 17:47:32.875	INFO	http.log	server running	{"name": "remaining_auto_https_redirects", "protocols": ["h1", "h2", "h3"]}
2023/05/14 17:47:32.875	INFO	http	enabling HTTP/3 listener	{"addr": ":443"}
2023/05/14 17:47:32.875	INFO	failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Receive-Buffer-Size for details.
2023/05/14 17:47:32.875	DEBUG	http	starting server loop	{"address": "[::]:443", "tls": true, "http3": true}
2023/05/14 17:47:32.875	INFO	http.log	server running	{"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2023/05/14 17:47:32.875	INFO	http	enabling automatic TLS certificate management	{"domains": ["sage.bluepine.xyz", "oin.dwarf"]}
2023/05/14 17:47:32.876	DEBUG	tls	loading managed certificate	{"domain": "sage.bluepine.xyz", "expiration": "2023/08/12 12:19:14.000", "issuer_key": "acme-v02.api.letsencrypt.org-directory", "storage": "FileStorage:/root/.local/share/caddy"}
2023/05/14 17:47:32.876	DEBUG	tls.cache	added certificate to cache	{"subjects": ["sage.bluepine.xyz"], "expiration": "2023/08/12 12:19:14.000", "managed": true, "issuer_key": "acme-v02.api.letsencrypt.org-directory", "hash": "71ce31498cd8c90716020c086cc7abcdd37e7fef1052aa820b0e467b25fb0204", "cache_size": 1, "cache_capacity": 10000}
2023/05/14 17:47:32.876	DEBUG	events	event	{"name": "cached_managed_cert", "id": "647d2b9b-f76f-46b0-918a-7a62937a84d0", "origin": "tls", "data": {"sans":["sage.bluepine.xyz"]}}
2023/05/14 17:47:32.876	INFO	tls	finished cleaning storage units
2023/05/14 17:47:32.876	WARN	tls	stapling OCSP	{"error": "no OCSP stapling for [oin.dwarf]: no OCSP server specified in certificate", "identifiers": ["oin.dwarf"]}
2023/05/14 17:47:32.876	DEBUG	tls.cache	added certificate to cache	{"subjects": ["oin.dwarf"], "expiration": "2023/05/15 04:39:41.000", "managed": true, "issuer_key": "local", "hash": "46c290aad75dea3008a6ea0156574f224d70aa9f9500569b16e7ad423923bcd8", "cache_size": 2, "cache_capacity": 10000}
2023/05/14 17:47:32.876	DEBUG	events	event	{"name": "cached_managed_cert", "id": "5ee72041-4d99-498f-af30-50b96bc8dbd4", "origin": "tls", "data": {"sans":["oin.dwarf"]}}
2023/05/14 17:47:32.888	INFO	pki.ca.local	root certificate is already trusted by system	{"path": "storage:pki/authorities/local/root.crt"}
2023/05/14 17:47:32.888	INFO	autosaved config (load with --resume flag)	{"file": "/root/.config/caddy/autosave.json"}
2023/05/14 17:47:32.888	INFO	serving initial configuration
2023/05/14 17:47:38.301	DEBUG	events	event	{"name": "tls_get_certificate", "id": "4fb9c3e1-c975-4ce8-a8e1-2f1566c277cf", "origin": "tls", "data": {"client_hello":{"CipherSuites":[52393,52392,49195,49199,49196,49200,49161,49171,49162,49172,156,157,47,53,49170,10,4867,4865,4866],"ServerName":"oin.dwarf","SupportedCurves":[29,23,24,25],"SupportedPoints":"AA==","SignatureSchemes":[2052,1027,2055,2053,2054,1025,1281,1537,1283,1539,513,515],"SupportedProtos":["h2","http/1.1"],"SupportedVersions":[772,771],"Conn":{}}}}
2023/05/14 17:47:38.301	DEBUG	tls.handshake	choosing certificate	{"identifier": "oin.dwarf", "num_choices": 1}
2023/05/14 17:47:38.301	DEBUG	tls.handshake	default certificate selection results	{"identifier": "oin.dwarf", "subjects": ["oin.dwarf"], "managed": true, "issuer_key": "local", "hash": "46c290aad75dea3008a6ea0156574f224d70aa9f9500569b16e7ad423923bcd8"}
2023/05/14 17:47:38.301	DEBUG	tls.handshake	matched certificate in cache	{"remote_ip": "192.168.1.119", "remote_port": "39268", "subjects": ["oin.dwarf"], "managed": true, "expiration": "2023/05/15 04:39:41.000", "hash": "46c290aad75dea3008a6ea0156574f224d70aa9f9500569b16e7ad423923bcd8"}
2023/05/14 17:47:38.303	DEBUG	http.stdlib	http: TLS handshake error from 192.168.1.119:39268: remote error: tls: bad certificate
2023/05/14 17:47:38.556	DEBUG	events	event	{"name": "tls_get_certificate", "id": "31b8a1c7-8b39-4590-9455-91a2c4971412", "origin": "tls", "data": {"client_hello":{"CipherSuites":[52393,52392,49195,49199,49196,49200,49161,49171,49162,49172,156,157,47,53,49170,10,4867,4865,4866],"ServerName":"oin.dwarf","SupportedCurves":[29,23,24,25],"SupportedPoints":"AA==","SignatureSchemes":[2052,1027,2055,2053,2054,1025,1281,1537,1283,1539,513,515],"SupportedProtos":["h2","http/1.1"],"SupportedVersions":[772,771],"Conn":{}}}}
2023/05/14 17:47:38.556	DEBUG	tls.handshake	choosing certificate	{"identifier": "oin.dwarf", "num_choices": 1}
2023/05/14 17:47:38.556	DEBUG	tls.handshake	default certificate selection results	{"identifier": "oin.dwarf", "subjects": ["oin.dwarf"], "managed": true, "issuer_key": "local", "hash": "46c290aad75dea3008a6ea0156574f224d70aa9f9500569b16e7ad423923bcd8"}
2023/05/14 17:47:38.556	DEBUG	tls.handshake	matched certificate in cache	{"remote_ip": "192.168.1.119", "remote_port": "39284", "subjects": ["oin.dwarf"], "managed": true, "expiration": "2023/05/15 04:39:41.000", "hash": "46c290aad75dea3008a6ea0156574f224d70aa9f9500569b16e7ad423923bcd8"}
2023/05/14 17:47:38.558	DEBUG	http.stdlib	http: TLS handshake error from 192.168.1.119:39284: remote error: tls: bad certificate
2023/05/14 17:47:38.811	DEBUG	events	event	{"name": "tls_get_certificate", "id": "ff815b11-1670-4988-b265-b644cd4ad360", "origin": "tls", "data": {"client_hello":{"CipherSuites":[52393,52392,49195,49199,49196,49200,49161,49171,49162,49172,156,157,47,53,49170,10,4867,4865,4866],"ServerName":"oin.dwarf","SupportedCurves":[29,23,24,25],"SupportedPoints":"AA==","SignatureSchemes":[2052,1027,2055,2053,2054,1025,1281,1537,1283,1539,513,515],"SupportedProtos":["h2","http/1.1"],"SupportedVersions":[772,771],"Conn":{}}}}
2023/05/14 17:47:38.811	DEBUG	tls.handshake	choosing certificate	{"identifier": "oin.dwarf", "num_choices": 1}
2023/05/14 17:47:38.811	DEBUG	tls.handshake	default certificate selection results	{"identifier": "oin.dwarf", "subjects": ["oin.dwarf"], "managed": true, "issuer_key": "local", "hash": "46c290aad75dea3008a6ea0156574f224d70aa9f9500569b16e7ad423923bcd8"}
2023/05/14 17:47:38.811	DEBUG	tls.handshake	matched certificate in cache	{"remote_ip": "192.168.1.119", "remote_port": "39298", "subjects": ["oin.dwarf"], "managed": true, "expiration": "2023/05/15 04:39:41.000", "hash": "46c290aad75dea3008a6ea0156574f224d70aa9f9500569b16e7ad423923bcd8"}
2023/05/14 17:47:38.812	DEBUG	http.stdlib	http: TLS handshake error from 192.168.1.119:39298: remote error: tls: bad certificate

3. Caddy version:

Front and backend running v2.6.4 h1:2hwYqiRwk1tf3VruhMpLcYTg+11fCdr8S3jhNAdnPy8=

4. How I installed and ran Caddy:

Install — Caddy Documentation

a. System environment:

Front- and back-end both installed on (separate) Ubuntu 21.04 VMs

b. Command:

sudo caddy run

c. Service/unit/compose file:

NAT and rules set up so WAN port 443 directs to 192.168.1.118
DNS resolving provided by PfSense:

oin.dwarf directs to 192.168.1.118
gloin.dwarf directs to 192.168.1.119

d. My complete Caddy config:

Frontend Caddyfile:
{
        debug
}
oin.dwarf {
        acme_server
        tls internal
}

sage.bluepine.xyz {
        reverse_proxy /test
        respond "this page is served correctly over HTTPS"

        reverse_proxy /media https://gloin.dwarf {
                header_up Host {upstream_hostport}
        }
}

Backend Caddyfile
{
        debug
        acme_ca https://oin.dwarf/home/oin/.local
        acme_ca_root /etc/ssl/certs/root.crt
}
gloin.dwarf {
        encode gzip
        uri replace /media /web/
        reverse_proxy /web/* :32400
}

5. Links to relevant resources:

Followed this guide as close as I could: Use Caddy for local HTTPS (TLS) between front-end reverse proxy and LAN hosts
I’ve been searching duckduckgo and these forums for most of two days trying to figure this out but still can’t figure it out.

Is my problem related to the acme_ca_root directory being incorrect? Or that the certificate was generated for sage.bluepine.xyz, but now oin.dwarf is trying to serve as the acme server?
It seems like gloin is trying to grab the new certificate but can’t because it has to be transferred with TLS, but TLS fails because there’s no certificate…I know I’m not understanding some part. Thank in advance

Whitestrake · May 14, 2023, 11:35pm

These errors from the backend:

Agrees with these errors from the frontend:

In that, during the attempt to requisition an ACME certificate from https://oin.dwarf/home/oin/.local, the backend could not verify the frontend certificate for oin.dwarf, and thus aborted the ACME attempt.

Have you followed this part of the guide you linked, specifically?

Use Caddy for local HTTPS (TLS) between front-end reverse proxy and LAN hosts

To request a certificate, a root certificate from the server is required. (Read this blog from Mike Malone to understand why). Once you have started the Caddy service on the frontend for the first time and there are no errors, a file named root.crt is generated in .local/share/caddy/pki/authorities/local

NOTE: The absolute path for the certificate depends on how you run Caddy. Typically when you use systemd the absolute path will be /var/lib/caddy/.local/share/caddy/pki/authorities/local but if you run caddy with caddy start the path .local/share/caddy/pki/authorities/local

You will have to copy this file to the backend and point to it in the Caddyfile. In the above example the file root.crt has been copied to /etc/ssl/certs/root.crt will be created in the in the directory you initiated the command (and where the Caddyfile is located).

If you have, I suspect there may be some issue with the backend recognising the root certificate you copied. If done correctly, the backend Caddy will explicitly trust the Caddy Local Authority - 2023 ECC Root issued certificate.

allenb · May 15, 2023, 1:28am

Thanks for the weekend reply @Whitestrake

Reading the root cert on oin.dwarf gives me this:

oin@oin:~$ cat /home/oin/.local/share/caddy/pki/authorities/local/root.crt
-----BEGIN CERTIFICATE-----
MIIBpTCCAU...redacted...HSnnU75vo=
-----END CERTIFICATE-----

Reading the root cert on gloin.dwarf gives me the same certificate.

gloin@gloin:~$ sudo cat /etc/ssl/certs/root.crt 
[sudo] password for gloin: 
-----BEGIN CERTIFICATE-----
MIIBpTCCAU....redacted...A3HSnnU75vo=
-----END CERTIFICATE-----

Should gloin be requesting the entire oin .local folder? Or should it specifically request the root.crt certificate that’s in the folder?
Should root.cert be in /etc/ssl as well as .local… folders on gloin and oin?

https://oin.dwarf/home/oin/.local/
vs
https://oin.dwarf/home/oin/.local/share/caddy/pki/authorities/local/root.crt

Maybe a permissions issue on oin’s side?

Whitestrake · May 15, 2023, 1:40am

No worries - it’s actually Monday here.

Gloin shouldn’t be requesting anything relating to the root certificate authority from Oin.

Oin should be sending a certificate signed by Caddy Local Authority - 2023 ECC Root, and Gloin should have the root CA certificate installed in its local trust store, so that it explicitly trusts any certificate signed by that CA.

When the root CA certificate is properly installed on the backend VM, all system functionality - including curl etc - should automatically trust oin.dwarf in your case. If curl doesn’t work, the root certificate isn’t installed properly.

I haven’t gone down this road myself and don’t use Ubuntu - I’m not sure if it’s Ubuntu specific, but I did find this link:

https://ubuntu.com/server/docs/security-trust-store

Essentially it suggests you should install a utility, copy the root CA (and name it specifically) into a folder, and then run the utility to update the trust store. Per the link,

After this point you can use Ubuntu’s tools like curl and wget to connect to local sites.

That’s specifically the result we want.

francislavoie · May 15, 2023, 1:54am

If you installed Caddy using the apt repo and are running it as a systemd service, then the root cert you want would be in /var/lib/caddy, not in /home/oin. Caddy runs as the caddy user when run as a service, and that user’s HOME is /var/lib/caddy.

allenb · May 15, 2023, 2:53am

Yeah I check the /var/lib/caddy folder and couldn’t find anything resembling a local folder or a certificate

oin@oin:~$ sudo ls -al /var/lib/caddy
total 28
drwxr-x---  4 caddy caddy 4096 May 14 13:13 .
drwxr-xr-x 41 root  root  4096 May 14 13:13 ..
-rw-r--r--  1 caddy caddy  220 Jan  6  2022 .bash_logout
-rw-r--r--  1 caddy caddy 3771 Jan  6  2022 .bashrc
drwx------  3 caddy caddy 4096 May 14 13:13 .config
-rw-r--r--  1 caddy caddy  807 Jan  6  2022 .profile
drwx------  2 caddy caddy 4096 May 14 13:13 .step

I appreciate the check though!

francislavoie · May 15, 2023, 3:06am

Are you actually running Caddy as a systemd service then?

Make sure you follow these instructions:

If you ran Caddy with sudo caddy run then Caddy is running as root. So its storage would be in /root.

That’s the wrong way to run Caddy. It shouldn’t be run as root manually, it should be run as a service, as the caddy user.

allenb · May 15, 2023, 8:11pm

Ahhh @francislavoie You are totally right. I was mixing up certificates generated by caddy run and sudo systemctl start caddy. I recreated the entire oin VM and reinstalled caddy and started via systemctl, installed oin’s certificated on gloin via the above linked method. Gloin can curl to oin.dwarf no problem:

gloin@gloin:~$ curl "https://oin.dwarf" -v
*   Trying 192.168.1.118:443...
* Connected to oin.dwarf (192.168.1.118) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* 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_CHACHA20_POLY1305_SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: [NONE]
*  start date: May 15 14:38:30 2023 GMT
*  expire date: May 16 02:38:30 2023 GMT
*  subjectAltName: host "oin.dwarf" matched cert's "oin.dwarf"
*  issuer: CN=Caddy Local Authority - ECC Intermediate
*  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 0x55a6b69da970)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/2
> Host: oin.dwarf
> user-agent: curl/7.81.0
> accept: */*
> 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
* 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 
< alt-svc: h3=":443"; ma=2592000
< server: Caddy
< content-length: 0
< date: Mon, 15 May 2023 19:59:44 GMT
< 
* Connection #0 to host oin.dwarf left intact

However, gloin is still having trouble with registering an account with the server:
{"level":"error","ts":1684180914.202562,"logger":"tls.obtain","msg":"will retry","error":"[gloin.dwarf] Obtain: registering account [] with server: provisioning client: performing request: Get \"https://oin.dwarf/var/lib/caddy/.local/share/caddy/acme/\": tls: failed to verify certificate: x509: certificate signed by unknown authority (possibly because of \"x509: ECDSA verification failure\" while trying to verify candidate authority certificate \"Caddy Local Authority - 2023 ECC Root\")","attempt":2,"retrying_in":120,"elapsed":61.03250751,"max_duration":2592000}

How does gloin’s curl match certificates no problem but caddy’s GET doesn’t work?
Could it be that gloin is requesting the wrong file or wrong directory from oin? I didn’t quite understand that part of the original guide:
acme_ca https://acme.roadrunner/acme/local/directory # point to ACME server

francislavoie · May 15, 2023, 8:40pm

Wait what, why is there a request for a path like that? I’m confused.

The ACME server URL should just be /acme/, the storage path is not included. See acme_server (Caddyfile directive) — Caddy Documentation

allenb · May 16, 2023, 1:23am

Ahhh finally got it! You were right on all counts Francis.

The acme server request path is the acme server host name then, literally /acme/local/directory. I got confused from the guide I linked that “acme” was the name of the host (since the other hosts were roadrunner and coyote cartoon related) and that I needed to adapt the path to my host.

After I fixed that, I was still running into “certificate not matching” errors. Which I realized was because I installed oin’s root.crt according to this guide, which puts it in /usr/local/share/ca-certificates, but Caddyfile was still pointing to /etc/ssl/certs/root.crt… duh! I fixed that and finally reached gloin.dwarf from sage.bluepine.xzy/media

Thank you both for your help and pointing me towards the specific documentation. I would never have put it all together without you.

system · June 15, 2023, 1:24am

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