Caddy - cloudflare - wildcard cert

fergalom · November 30, 2018, 10:44am

Trying to use a LE wildcard cert for a domain xyz.com

internet → cloudflare → caddy(docker container) → docker container (eg ha.xyz.com)

From the log file seems like the wilcard cert is generate but when I use ha.xyz.com, browser will show error page with

# This site can’t be reached

**ha.xyz.com** ’s server IP address could not be found.

* [Try running Windows Network Diagnostics](javascript:diagnoseErrors()).

DNS_PROBE_FINISHED_NXDOMAIN

Using the ip and a port foward does work.

Can anyone spot issues with what I have done?

Caddyfile

(wildcard_cert) {
  tls {
    dns cloudflare
    wildcard
  }
}

ha.xyz.com {
        import wildcard_cert
        proxy / 192.168.1.4:8123 {
                websocket
				transparent
        }
}

Caddy log

Activating privacy features... 2018/11/29 22:23:09 [INFO][*.xyz.com] acme: Obtaining bundled SAN certificate
2018/11/29 22:23:10 [INFO][*.xyz.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz/asdjfhksdhkdshkjsdh
2018/11/29 22:23:10 [INFO][xyz.com] acme: Trying to solve DNS-01
2018/11/29 22:23:11 [INFO][xyz.com] Checking DNS record propagation using [127.0.0.11:53]
2018/11/29 22:23:18 [INFO][xyz.com] The server validated our request
2018/11/29 22:23:20 [INFO][*.xyz.com] acme: Validations succeeded; requesting certificates
2018/11/29 22:23:21 [INFO][*.xyz.com] Server responded with a certificate.
2018/11/29 22:23:21 [INFO][*.xyz.com] Certificate written to disk: /root/.caddy/acme/acme-v02.api.letsencrypt.org/sites/wildcard_.xyz.com/wildcard_.xyz.com.crt
done.
https://ha.xyz.com
2018/11/29 22:23:21 https://ha.xyz.com
http://ha.xyz.com
2018/11/29 22:23:21 http://ha.xyz.com
2018/11/29 22:23:22 [INFO] Sending telemetry: success
2018/11/29 23:39:23 [INFO] Scanning for stale OCSP staples
2018/11/29 23:39:23 [INFO] Done checking OCSP staples
2018/11/29 23:40:13 [INFO] Sending telemetry: success
2018/11/30 00:35:03 [INFO] 5.6.7.8 - No such site at :80 (Remote: 1.2.3.4, Referer: )
2018/11/30 00:39:23 [INFO] Scanning for stale OCSP staples
2018/11/30 00:39:23 [INFO] Done checking OCSP staples
2018/11/30 01:49:25 [NOTICE] Sending telemetry: we were too early; waiting 1h2m49.028574896s before trying again
2018/11/30 02:39:23 [INFO] Scanning for stale OCSP staples
2018/11/30 02:39:23 [INFO] Done checking OCSP staples
2018/11/30 02:52:14 [INFO] Sending telemetry: success
2018/11/30 02:52:21 http: TLS handshake error from 107.170.210.162:37992: tls: no certificates configured
2018/11/30 03:33:44 http: TLS handshake error from 122.228.19.80:22375: tls: no certificates configured

Have a dynamic ip and using dns-o-matic to keep the ip synced to cloudflare
Cloudflare ssl set to full(strict)

Whitestrake · November 30, 2018, 11:13am

DNS_PROBE_FINISHED_NXDOMAIN

This issue is client-side, assuming your domain exists and is registered and pointed to your server. Your browser tried to locate the domain name you wanted to browse to and couldn’t resolve it. Check DNS caching, try with another browser or in incognito mode, and check your DNS servers are set correctly.

fergalom · November 30, 2018, 12:56pm

Thanks, checked the docker host and dns set ok here and on the dd-wrt router.
Tried incognito mode and other browsers - same error

resolv.conf looks ok

[admin@dockerhost ~]$ cat /etc/resolv.conf
# Generated by NetworkManager
search localdomain
nameserver 1.1.1.1
nameserver 1.0.0.1
nameserver 192.168.1.1
[admin@dockerhost ~]$

nslookup of domain

[admin@dockerhost ~]$ nslookup xyz.com
Server:         1.1.1.1
Address:        1.1.1.1#53

Non-authoritative answer:
Name:   xyz.com
Address: 104.31.81.115
Name:   xyz.com
Address: 104.31.80.115

[admin@dockerhost ~]$ nslookup ha.xyz.com
Server:         1.1.1.1
Address:        1.1.1.1#53

** server can't find ha.xyz.com: NXDOMAIN

[admin@dockerhost ~]$

If I alter the caddy file to just point xyz.com directly to a single docker container, it works.
Appreciate this is not a caddy issue but if you have any other ideas, would be greatly appreciated.

Whitestrake · November 30, 2018, 1:22pm

I can only really think of three possibilities to explain this:

You’ve misspelled the domain name
There is no A / CNAME record for ha.xyz.com
Cloudflare’s resolver (1.1.1.1) is incorrectly reporting NXDOMAIN for this DNS request

What do you get from dig @8.8.8.8 ha.xyz.com?

What about if you find out your Cloudflare nameserver for the domain (it will be somename.ns.cloudflare.com) and query it directly, i.e. dig @jean.ns.cloudflare.com ha.xyz.com?

fergalom · November 30, 2018, 1:53pm

ok, thanks, just found my noob error. (I think)
Did not understand that I also need to put a cname for each subdomain in cloudflare as well as my caddy file.

Once added cname ha to cloudflare, everything worked.
Thanks!

Final question, the ssl cert being shown in the browser is cloudflare rather than the LetsEncrypt - would that be normal?

[admin@dockerhost ~]$ dig @8.8.8.8 ha.xyz.com

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 <<>> @8.8.8.8 ha.xyz.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13358
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ha.xyz.com.                     IN      A

;; ANSWER SECTION:
ha.xyz.com.              299     IN      A       104.31.81.115
ha.xyz.com.              299     IN      A       104.31.80.115

;; Query time: 40 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Nov 30 13:47:49 GMT 2018
;; MSG SIZE  rcvd: 70

[admin@dockerhost ~]$ dig @john.ns.cloudflare.com ha.xyz.com

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7_5.1 <<>> @john.ns.cloudflare.com ha.xyz.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48285
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ha.xyz.com.                     IN      A

;; ANSWER SECTION:
ha.xyz.com.              300     IN      A       104.31.80.115
ha.xyz.com.              300     IN      A       104.31.81.115

;; Query time: 18 msec
;; SERVER: 173.245.59.185#53(173.245.59.185)
;; WHEN: Fri Nov 30 13:48:44 GMT 2018
;; MSG SIZE  rcvd: 70

[admin@dockerhost ~]$

Whitestrake · December 1, 2018, 1:16pm

Yeah, this is expected behaviour.

You’ll note that the response from dig - that is, 104.31.80.115 and 104.31.81.115 - doesn’t match the IP address you put in the Cloudflare dashboard.

This is because you’ve configured your DNS records as “orange-cloud” - that is, enabling a bunch of Cloudflare functionality. They provide this functionality by responding to DNS requests with their own IP instead of yours, and then when the client connects to them, they reverse proxy to your origin server. They can provide caching, DDOS protection, etc this way. They also provide SSL certificates, as you’ve noticed.

They won’t handle non-HTTP traffic, though.

system · March 1, 2019, 1:16pm

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