Hi, I’ve set my Cloudflare DNS to point mydomain.com to my reverse proxy’s WAN IP, which is configured to use my Cloudflare SSL certificate. This works fine.
However, when I’m in my LAN my local DNS server will resolve mydomain.com directly to my reverse proxy. When visiting the domain in my browser in LAN I receive NET::ERR_CERT_AUTHORITY_INVALID
Is there any setting that will let me use my Cloudflare certificate without going through Cloudflare DNS?
So that I understand you correctly, you have split horizon DNS, with an internal authorative DNS server for your domain (example.net) and also the same zone set up on Cloudflare. You have an entry in Cloudflare for (say) www.example.net pointing to the WAN IP of your origin server, 192.0.2.1. You have enabled the Orange Cloud, and Cloudflare have valid certs for the hostname.
Internally, you have www.example.net pointing to either the WAN IP of your reverse proxy, or some other private address. You have no valid TLS cert for the hostname.
You could create a CNAME on your internal DNS which points www.example.net to www.example.net.cdn.Cloudflare.com, which will resolve to the correct Orange or Grey cloud address. If you are using the naked domain (example.net), then you will need to resolve example.net.cdn.Cloudflare.com, and use the resulting addresses in A records for the zone root in the internal DNS.
Thanks Michael!
To make this simpler, maybe we remove the reverse proxy from the equation.
My domain example.net is resolved by CF DNS to my server’s WAN IP. In my LAN, example.net will be resolved to my server’s LAN IP—I do this to take advantage of the faster connection when I’m in my LAN.
Obviously I can set up my local DNS to not resolve example.net and the request would go to my upstream DNS, which actually is Cloudflare. However, I would end up on my server’s WAN IP again instead of keeping traffic inside my LAN.
My assumption was SSL certificates would be bound to host names, not IP addresses. So my CF certificate would work for both LAN and WAN access.
TLS Certificates have nothing to do with IP addresses [1] but must be bound to the IP address that corresponds to the IP address returned by DNS.
Can you run the following commands, and share the output. Replace www.example.net with your domain name. (You should remove any private data before pasting the response the Community)
export DOMAIN=www.example.net
echo | openssl s_client -connectdig +short $DOMAIN | head -1:443 -servername $DOMAIN -tls1_2 2> /dev/null | sed -n ‘/Certificate chain/,/—/p’
echo | openssl s_client -connectdig +short $DOMAIN @1.1.1.1 | head -1:443 -servername $DOMAIN -tls1_2 2> /dev/null | sed -n ‘/Certificate chain/,/—/p’
The first openssl command will give the certificate chain for the LAN IP, the second from the “public” IP. I expect the first command to fail in some way.
Hi Michael, pasting the command like that failed but when I replace the dig part with the respective IPs I get the following for the LAN IP
depth=0 O = “Cloudflare, Inc.”, OU = Cloudflare Origin CA, CN = Cloudflare Origin Certificate
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 O = “Cloudflare, Inc.”, OU = Cloudflare Origin CA, CN = Cloudflare Origin Certificate
verify error:num=21:unable to verify the first certificate
verify return:1
DONE
For the WAN IP I receive an error
SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.230.1/libressl-2.6/ssl/ssl_pkt.c:1205:SSL alert number 40
SSL routines:CONNECT_CR_SRVR_HELLO:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.230.1/libressl-2.6/ssl/ssl_pkt.c:585:Cloudflare’s Origin Certificates are only trusted by Cloudflare.
If you want your users to access your server without going through Cloudflare, and you send them that way using DNS, and you want no certificate issues, well, just like any other site on the Internet - you need to get standard trusted SSL certificate. Cloudflare Origin certs are meant for people who can’t get (or won’t bother/care) a standard trusted cert. In the past, certs has been something that costs money, so it made sense to use this - after all no regular users should bypass Cloudflare, so it’s OK for the cert to not validate for the peace of mind of not having to update your cert all the time (because Cloudflare Origin Certs are for many years).
But today we have Let’s Encrypt that gives us FREE SSL certificates and even automation in issuance so the certificates can, and are, being replaced automatically by code running on the server; So there’s not much reason NOT to use them. You can even do so from an unprivileged account by using acme.sh in stateless mode and then just reloading the server config after a successful certificate change via a password-less sudo command that is limited to only allow this specific unprivileged user just one command: reload your webserver config.
Thanks Shimi, I’ll give ACME a try in my setup. I think I should be able to serve a different cert depending on whether or not the client comes through CF DNS.
The nice thing about a Let’s Encrypt cert with acme.sh, is that the same cert will work for both your users and Cloudflare connections to your server… so you don’t need to complicate anything.
This topic was automatically closed after 30 days. New replies are no longer allowed.