1. Caddy version (caddy version
):
CADDY_VERSION=v2.3.0
2. How I run Caddy:
In a docker container, on a raspberry pi4 running omv5.
a. System environment:
Docker, raspberry pi 4, omv5.
Internet/LAN details:
- I have ATT Uverse, with a Google Nest Wifi set up in dmz+ mode.
- The raspberry pi server is wired to the Nest Wifi. 443 and 80 are forwarded to the raspberry pi over both TCP and UDP
- I am using google domains, a dynamic DNS Synthetic A record exists for the subdomain books..com.
- I have a container running ddclient successfully keeping this dynamic dns record updated.
b. Command:
sudo docker-compose up -d
c. Service/unit/compose file:
version: "3"
services:
caddy:
image: caddy:latest
container_name: caddy
hostname: caddy
restart: unless-stopped
ports:
- "80:80"
- "443:443"
environment:
- MY_DOMAIN
volumes:
- /home/pi/docker/caddy/.Caddyfile:/etc/caddy/Caddyfile
- /home/pi/docker/caddy/.data:/data
- /home/pi/docker/caddy/.config:/config
d. My complete Caddyfile or JSON config:
{
acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
email email@gmail.com
}
books.website.com {
reverse_proxy 192.168.86.249:8083
}
3. The problem I’m having:
When accessing the subdomain in my LAN, the service is returned.
When accessing outside the LAN, I get a ssl self signed certificate in chain error message.
I’m not sure what is wrong with my SSL configuration. I have left the acme at staging for the time being (but don’t know what “working” looks like with this set).
4. Error messages and/or full log output:
{"level":"info","ts":1611176853.4052734,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"}
{"level":"info","ts":1611176853.4110165,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["localhost:2019","[::1]:2019","127.0.0.1:2019"]}
{"level":"info","ts":1611176853.4118595,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0x2cb9ef0"}
{"level":"info","ts":1611176853.41203,"logger":"http","msg":"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}
{"level":"info","ts":1611176853.412362,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
{"level":"info","ts":1611176853.4134648,"logger":"tls","msg":"cleaned up storage units"}
{"level":"info","ts":1611176853.4139993,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["books.website.com"]}
{"level":"info","ts":1611176853.4147255,"msg":"autosaved config","file":"/config/caddy/autosave.json"}
{"level":"info","ts":1611176853.414795,"msg":"serving initial configuration"}
{"level":"info","ts":1611176853.4162135,"logger":"tls.obtain","msg":"acquiring lock","identifier":"books.website.com"}
{"level":"info","ts":1611176853.4175136,"logger":"tls.obtain","msg":"lock acquired","identifier":"books.website.com"}
{"level":"info","ts":1611176854.0254877,"logger":"tls.issuance.acme","msg":"waiting on internal rate limiter","identifiers":["books.website.com"]}
{"level":"info","ts":1611176854.0255497,"logger":"tls.issuance.acme","msg":"done waiting on internal rate limiter","identifiers":["books.website.com"]}
{"level":"info","ts":1611176854.159837,"logger":"tls.issuance.acme.acme_client","msg":"trying to solve challenge","identifier":"books.website.com","challenge_type":"http-01","ca":"https://acme-staging-v02.api.letsencrypt.org/directory"}
{"level":"info","ts":1611176854.5906181,"logger":"tls.issuance.acme","msg":"served key authentication","identifier":"books.website.com","challenge":"http-01","remote":"52.58.118.98:20710"}
{"level":"info","ts":1611176854.825973,"logger":"tls.issuance.acme","msg":"served key authentication","identifier":"books.website.com","challenge":"http-01","remote":"66.133.109.36:27690"}
{"level":"info","ts":1611176855.1265519,"logger":"tls.issuance.acme","msg":"served key authentication","identifier":"books.website.com","challenge":"http-01","remote":"18.224.20.83:31060"}
{"level":"info","ts":1611176855.4601676,"logger":"tls.issuance.acme.acme_client","msg":"validations succeeded; finalizing order","order":"https://acme-staging-v02.api.letsencrypt.org/acme/order/17618337/225569706"}
{"level":"info","ts":1611176855.9150028,"logger":"tls.issuance.acme.acme_client","msg":"successfully downloaded available certificate chains","count":2,"first_url":"https://acme-staging-v02.api.letsencrypt.org/acme/cert/fab03aebfaf426bdf9e14d870ddbbacbf366"}
{"level":"info","ts":1611176855.9174347,"logger":"tls.obtain","msg":"certificate obtained successfully","identifier":"books.dnullify.com"}
{"level":"info","ts":1611176855.917513,"logger":"tls.obtain","msg":"releasing lock","identifier":"books.dnullify.com"}
5. What I already tried:
I have started over several times. Most recently I followed the following guide:
- I ensured that the data directory is bind mounted to the host for persistence.
- I ensured that my port forwarding rules were up before bringing up the service.
- I ensured that my dns a record resolves to my home IP address.
- I am not sure why but nslookup in my lan returns:
❯ nslookup books.website.com
;; reply from unexpected source: 2600:1700:ccf0:5a28:c8e1:88ff:fef3:98a8#53, expected 2600:1700:ccf0:5a28:c8e1:88ff:fef3:98a9#53
Server: 192.168.86.1
Address: 192.168.86.1#53
Non-authoritative answer:
Name: books.website.com
Address: ***.***.***.***
I’m assuming this is my gatway resolving this domain rather than the internet.
- I get the expected nslookup response from LAN.
Main issue so far:
-
I used cURL and openssl s_client -connect to my url from outside my LAN and I am seeing motorola certificates presented as the server certificates:
-
the “server” is insisting on using tls1.0.
❯ curl -vk https://books.website.com
* Rebuilt URL to: https://books.website.com/
* Trying 108.202.***.***...
* TCP_NODELAY set
* Connected to books.website.com (108.202.***.***) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.0 (IN), TLS handshake, Certificate (11):
* TLSv1.0 (IN), TLS handshake, Server finished (14):
* TLSv1.0 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.0 (OUT), TLS change cipher, Client hello (1):
* TLSv1.0 (OUT), TLS handshake, Finished (20):
* TLSv1.0 (IN), TLS change cipher, Client hello (1):
* TLSv1.0 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.0 / AES256-SHA
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; ST=California; L=SanDiego; O=Motorola-Mobility Corp.; OU=VIP; CN=BMS; emailAddress=support@motorola-mobility.com
* start date: Apr 17 18:08:25 2012 GMT
* expire date: Apr 15 18:08:25 2022 GMT
* issuer: C=US; ST=California; L=SanDiego; O=Motorola-Mobility Corp.; OU=VIP; CN=BMS; emailAddress=support@motorola-mobility.com
* SSL certificate verify result: self signed certificate (18), continuing anyway.
> GET / HTTP/1.1
> Host: books.website.com
> User-Agent: curl/7.54.0
> Accept: */*
>
* Empty reply from server
* Connection #0 to host books.website.com left intact
curl: (52) Empty reply from server
~ ❯
❯ openssl s_client -connect books.website.com:443
CONNECTED(00000005)
depth=0 C = US, ST = California, L = SanDiego, O = Motorola-Mobility Corp., OU = VIP, CN = BMS, emailAddress = support@motorola-mobility.com
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = California, L = SanDiego, O = Motorola-Mobility Corp., OU = VIP, CN = BMS, emailAddress = support@motorola-mobility.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=SanDiego/O=Motorola-Mobility Corp./OU=VIP/CN=BMS/emailAddress=support@motorola-mobility.com
i:/C=US/ST=California/L=SanDiego/O=Motorola-Mobility Corp./OU=VIP/CN=BMS/emailAddress=support@motorola-mobility.com
---
I’m not sure why this is occurring, but if I had to guess my gateway is SSL terminating connection requests - and is not up to date with SSL versions. Hence self signed certs and tls 1.0.
I don’t have a high level of confidence in my interpretation of the output.
Thanks in advance!